maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Markus Karg (JIRA)" <j...@apache.org>
Subject [jira] [Created] (MNG-6142) Support for additional <variant> coordinate to identify branches, editions, private builds, etc.
Date Sat, 31 Dec 2016 10:58:58 GMT
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)

Mime
View raw message