[jira] [Commented] (MNG-6142) Support for additional coordinate to identify branches, editions, private builds, etc.

["Robert Scholte (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MNG-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15789605#comment-15789605 ] 

Robert Scholte commented on MNG-6142:
-------------------------------------

Since this is about extending the Maven coordinate, is seems related to the platform proposal from [~stephenc] ( see https://s.apache.org/pom5 )

> 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)