[
https://issues.apache.org/jira/browse/MNG-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MNG-6142.
--------------------------------------
> 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
> Assignee: Elliotte Rusty Harold
> Priority: Major
>
> 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
(v8.3.4#803005)
