maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: Version ranges and snapshots
Date Sun, 22 Mar 2015 16:18:53 GMT
Hi Jon,

Thank you for your great proposal.
I fixed some formatting issues and integrated it: I think the intro is now 
better

Regards,

Hervé

Le vendredi 20 mars 2015 19:28:24 Jon Harper a écrit :
> Hi Hervé,
> what do you think of the following first patch ? I haven't generated the
> corresponding html yet, just throwing some ideas..
> 
> Regards,
> Jon
> 
> Index: pom.apt
> ===================================================================
> --- pom.apt     (révision 1668105)
> +++ pom.apt     (copie de travail)
> @@ -303,8 +303,14 @@
>  +-----------------+
> 
>    * <<groupId>>, <<artifactId>>, <<version>>:\
> -  These elements are self-explanatory, and you will see them often. This
> trinity represents the coordinate
> -  of a specific project in time, demarcating it as a dependency of this
> project. You may be thinking:
> +  You will see these elements often. This trinity is used to compute the
> maven coordinate
> +  of a specific project in time, demarcating it as a dependency of this
> project. The purpose
> +  of this computation is to select a version that matches all the
> dependency declarations
> +  (due to transitive dependencies, there can be multiple dependency
> declarations for the
> +  same artifact). The values should be:
> +    * <<groupID>>, <<artifactID>>: directly the corresponding
coordinates
> of the dependency.
> +    * <<version>>: a <<version range>> that will be used to
compute the
> dependency's version.
> +  Since the dependency is described by maven coordinates, you may be
> thinking:
>    "This means that my project can only depend upon Maven artifacts!" The
> answer is, "Of course, but that's a
>    good thing." This forces you to depend solely on dependencies that Maven
> can manage. There are times,
>    unfortunately, when a project cannot be downloaded from the central
> Maven repository. For example, a project
> @@ -388,6 +394,21 @@
>    In the shortest terms, <<<optional>>> lets other projects know that,
> when you use this project, you
>    do not require this dependency in order to work correctly.
> 
> +*** {Version Ranges}
> +
> +  Version Ranges used for the <<version>> element have the following
> syntax (TODO only examples??):
> +  * 1.0: "Soft" requirement on 1.0 (just a recommendation - helps select
> the correct version if it matches all ranges)
> +  * (,1.0]: x <= 1.0
> +  * [1.0]: Hard requirement on 1.0
> +  * [1.2,1.3]: 1.2 <= x <= 1.3
> +  * [1.0,2.0): 1.0 <= x < 2.0
> +  * [1.5,): x >= 1.5
> +  * (,1.0],[1.2,): x <= 1.0 or x >= 1.2. Multiple sets are comma-separated
> +  * (,1.1),(1.1,): This excludes 1.1 if it is known not to work in
> combination with this library
> +
> +  TODO: describe the pseudo-lexicographical order used above, using major
> version, minor version, incremental version, and qualifier.
> +  examples: 1.0.0-SNAPSHOT < 1.0.0 ...
> +
>  *** {Exclusions}
> 
>    Exclusions explicitly tell Maven that you don't want to include the
> 
> 
> Jon
> 
> On Sun, Feb 15, 2015 at 10:09 PM, Hervé BOUTEMY <herve.boutemy@free.fr>
> 
> wrote:
> > Hi Jon,
> > 
> > Le dimanche 15 février 2015 21:41:52 Jon Harper a écrit :
> > > Hi,
> > > since there were no answers, I'm not sure I wrote to the correct mailing
> > > list for this problem.
> > 
> > good mailing list, but can of worm :)
> > 
> > > Can anyone direct me to someone who is interested in
> > > working on this issue ?
> > 
> > I can try to work on this once more: perhaps we'll manage to improve
> > something
> > 
> > > For info, the docs have been saying the following for 7+ years:
> > > "groupId, artifactId, version:
> > > These elements are self-explanatory"
> > > 
> > > The version element is *not* self-explanatory, especially regarding
> > > interactions between version ranges and *-SNAPSHOTs artifacts.
> > 
> > you're right: version *in dependencies* is not self explanatory (version
> > in
> > Maven coordinates is self explanatory)
> > It has a lot of subtle features: preferred vs exact match, version range,
> > then
> > the question of SNAPSHOTS
> > 
> > > Any thoughts on this matter would be appreciated.
> > 
> > if you have little patches for the source of the page [1], I can review
> > and we
> > can work and discuss on it step by step
> > 
> > Regards,
> > 
> > Hervé
> > 
> > [1] https://svn.apache.org/repos/asf/maven/site/trunk/content/apt/pom.apt
> > 
> > > Regards,
> > > Jon
> > > 
> > > On Thu, Feb 5, 2015 at 5:52 PM, Jon Harper <jon.harper87@gmail.com>
> > 
> > wrote:
> > > > Hi,
> > > > I'm resurrecting this old thread to ask if it's possible to change
> > > > http://maven.apache.org/pom.html to document the current
> > 
> > implementation
> > 
> > > > behavior (7+ years old).
> > 
> > > > Please see my comment on MNG-3092:
> > http://jira.codehaus.org/browse/MNG-3092?focusedCommentId=362616&page=com.
> > 
> > atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-36261
> > 
> > > > 6
> > > > 
> > > > Jon
> > > > 
> > > > Mark Hobson Fri, 06 Jul 2007 06:53:04 -0700
> > > > 
> > > > > Hi,
> > > > > 
> > > > > Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
> > > > > contrary to the 2.0 design docs:
> > > > > 
> > > > > http://jira.codehaus.org/browse/MNG-3092
> > > > > 
> > > > > Brett, Kenney and myself had a brief discussion on IRC about this:
> > > > > Kenney says that the behaviour is theoretically correct (which it
> > 
> > is),
> > 
> > > > > although I feel it goes against the practical usage described in
the
> > > > > docs.  The two main choices I can see are:
> > > > > 
> > > > > 1) We stick to the design docs and disallow snapshots in ranges when
> > > > > they aren't an explicit boundary, as per the MNG-3092 patch.
> > > > > 
> > > > > 2) We reconsider the design docs and leave range resolution behaving
> > > > > as it is, then use profiles to enable or disable snapshot
> > 
> > repositories
> > 
> > > > > at build time.
> > > > > 
> > > > > Any thoughts?
> > > > > 
> > > > > Mark
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message