Details
-
Wish
-
Status: Closed
-
Major
-
Resolution: Abandoned
-
None
-
None
-
None
Description
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 major.minor.build-qualifier 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.