maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte (JIRA)" <>
Subject [jira] [Commented] (MNG-6142) Support for additional <variant> coordinate to identify branches, editions, private builds, etc.
Date Sat, 31 Dec 2016 14:44:58 GMT


Robert Scholte commented on MNG-6142:

Since this is about extending the Maven coordinate, is seems related to the platform proposal
from [~stephenc] ( see )

> Support for additional <variant> coordinate to identify branches, editions, private
builds, etc.
> ------------------------------------------------------------------------------------------------
>                 Key: MNG-6142
>                 URL:
>             Project: Maven
>          Issue Type: Wish
>          Components: core
>            Reporter: Markus Karg
> Often development teams work on parallel variants (a.k.a branches) ontop of the same
base version. Maven currently has no support for such scenarios, which is problematic, as
the following example describes:
> A team of three developers just released version "1.0.0" of a library, which is used
by a larger application. The version was now set to 1.1.0-SNAPSHOT for the master branch,
and 1.0.1-SNAPSHOT for the Long-Term-Support branch. Now in that team, programmer A started
to work on feature A. In the same team, programmer B started to work on feature B, which is
concurrent (!) to feature A. The team lead, programmer C, will later decide which (!) of both
features (A _or_ B) he wants to get in the final release 1.0.0. To try out each of the features,
he sets 1.1.0-SNAPSHOT as the dependency version in his test application, to pull in the latest
version of the library. The problem is: How (by means of POM coordinates) to decide which
proposed feature to pull, A or B?
> Similar scenarios often happen whilst the development of large systems. There is no real
solution here, as group, artifact, and version are the same for all variants of the next development
iteration, but only the _variant_ (a.k.a "branch") of the artifact is different.
> Why not simply reusing the existing coordinatest?
> - groupdId: A variant is a different timeline within an artifact, so changing the group
is irrational.
> - artifactId: Variants are, just like versions, changes _of_ artifacts, not _different_
artifacts. Certainly, this is the most rational workaround.
> - version: Existing tools depend on the schema, and rely
upon semantic interpretation that qualifiers are _sorted_, so feature A would become "older"
than feature "B", which is completely weird, as both have the same age.
> - classifier: Classifiers are needed in addition to variants, for example both A and
B shall publish javadoc and sources, so this would break existing features.
> To sum up, using the existing coordinates implies major drawbacks or even breaks existing
features. Also, it is counterintuitive, as a variant implies a separate timeline, neither
a new group or artifact, nor a sequence on one shared same timeline.
> Hence, to improve actual current workflow scenarios, I'd like to propose the addition
of an optional <variant> coordinate. The interpretation should be like this:
> * <variant> is optional.
> * <variant>, if existing, is added to the default file name between <artifactId>
and <version> (e. g. mylib-featureB-1.0.0-SNAPSHOT-javadoc.jar).
> * <variant>, if given, implies that a dependency with variant V of artifact A,
will can only be satisfied with exact that coordinates, neither with artifact "A-V", nor with
A having no version. On the other hand, just as with versions, a dependency not having a variant,
is happy with _any_ variant of the same artifact, unless the variant is marked as "exactly
this" using brackets [V].
> Adding support using these rules would allow tool / plugin vendors to greatly support
dealing with branches, e. g. in git and subversion, by better understand dependencies on features,
differences between branches, etc.

This message was sent by Atlassian JIRA

View raw message