[
https://issues.apache.org/jira/browse/MNG-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17345993#comment-17345993
]
Markus Karg commented on MNG-6142:
----------------------------------
What are you actually missing to be "fleshed out"? Just today I had this exact
problem: There are two variants of "johnzon-jsonb" actually, one is using the
Jakarta namespace, one is using the Javax namespace. The implementation
otherwise is the same. Currently we are publishing the Jakarta variant using a
classifier "-jakarta" and the Javax variant without a classifier. While this
technically does work, it implies a problem: What if some day the Jakarta
variant actually has a different source code or JavaDoc? Then the classifier
suddenly covers a n:m matrix of "variant:classifier" (like
"jakarta:javadoc")... The only real solution for real variants is to either add
<variant> to the POM or define a n:m syntax for classifiers.
So is that what you are missing, or did you simply want to propose that we
discuss HOW we implement variants in a future major version of Maven?
> 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)
