Markus Karg created MNG-6142:
--------------------------------
Summary: Support for additional <variant> coordinate to identify
branches, editions, private builds, etc.
Key: MNG-6142
URL: https://issues.apache.org/jira/browse/MNG-6142
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 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
