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: Maven resolver branch consolidation
Date Fri, 17 Nov 2017 08:40:22 GMT
on the second option, I was ready to just answer "not possible", but decided I 
could try at high level before answering...

I took Maven core dependency tree [1], picked green color as the definition of 
Maven Artifact Resolver, put maven-resolver-provider in green + settings 
builder (since used by resolver ant tasks: that's a detail I didn't put in 
latest resolver dependency tree)
Then I extended green to every transitive dependency to have an independent 
releasable reactor

You'll find as a result the attached image.

Analysis:
- this splits Maven core in 2 parts: lower part on dependency resolution, 
higher part on build
- settings.xml and pom.xml are in dependency resolution

Reaction: it could be for Maven 5 or 6, when consumer pom is strictly separate 
from build pom...

Regards,

Hervé

[1] http://maven.apache.org/ref/3.5.2/

Le jeudi 16 novembre 2017, 18:13:15 CET Manfred Moser a écrit :
> Thanks for the explanation and details Herve. Seems to be that to do this
> cleanly we have to break the circle. From my limited knowledge there are
> two ways to do that.
> 
> 1. As stephen suggested.. get the resolver into maven core tree. That makes
> core bigger again and ties the two projects into one release cycle.
> Feasible but I am not a fan.
> 
> 2. I am not sure if possible but .. could we get the maven resolver provider
> out of maven core and into the resolver project and have it all together in
> there?
> 
> In either case .. both of those seem rather large tasks so I will definitely
> go ahead with demo branch merge first. I just have to redo the work I did
> without the ant tasks in the tree. Stay tuned on that..
> 
> Manfred
> 
> Hervé BOUTEMY wrote on 2017-11-16 05:49:
> > feasible, but I really don't like it: separation is good.
> > 
> > seriously, just merge demos and let ant-tasks separate, and we have a
> > pretty good compromise on every aspect
> > (or even drop ant tasks if really this is causing us too much headache...)
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le jeudi 16 novembre 2017, 10:03:07 CET Stephen Connolly a écrit :
> >> On Thu 16 Nov 2017 at 07:51, Hervé BOUTEMY <herve.boutemy@free.fr> wrote:
> >> > I just pushed an update of dependencies image that shows the external
> >> > maven-
> >> > resolver-provider (in yellow) inside the reactor dependency graph (in
> >> > blue)
> >> > 
> >> > That shows the chicken and egg issue on releasing we'll have on API
> >> > breaking
> >> > change. People always building from source (like Debian) will have the
> >> > issue
> >> > also.
> >> > 
> >> > For demos, which are not really published during the release (just as
> >> > documentation), disabling the module in the build when necessary is
> >> > sufficient,
> >> > won't change many things. For ant tasks, disabling the module will not
> >> > publish
> >> > the artifact: this will have a visible impact.
> >> 
> >> Should we just bite the bullet and bring resolver in-tree as modules in
> >> maven core... leaving demos and ant tasks here?
> >> 
> >> > Regards,
> >> > 
> >> > Hervé
> >> > 
> >> > Le mercredi 15 novembre 2017, 23:05:14 CET Hervé BOUTEMY a écrit :
> >> > > it seems I have not been clear: I'll try to explain better
> >> > > 
> >> > > 1. maven-resolver-ant-tasks depends on maven-resolver-provider (from
> >> > 
> >> > Maven
> >> > 
> >> > > core)
> >> > > 2. maven-resolver-provider (then Maven core) depends on
> >> > > maven-resolver
> >> > > 
> >> > > if we put maven-resolver-ant-tasks in the same reactor than
> >> > 
> >> > maven-resolver,
> >> > 
> >> > > we can't release any maven-resolver API change that breaks
> >> > 
> >> > maven-resolver-
> >> > 
> >> > > provider
> >> > > 
> >> > > example: if we move maven-resolver code to org.apache.maven java
> >> > > package
> >> > 
> >> > in
> >> > 
> >> > > maven-resolver 2.0.0-SNAPSHOT, we need maven-resolver-provider
> >> > > 4.0.0-SNAPSHOT that uses maven-resolver 2.0.0-SNAPSHOT with this new
> >> > > java
> >> > > package. Then try to release anything: you can't, unless you don't
> >> > > try
> >> > > to
> >> > > release maven- resolver-ant-tasks
> >> > > 
> >> > > (the consequence on version consistency is another way to describe
> >> > > the
> >> > > issue, but that is more subtle, then I chose to describe the most
> >> > > visible
> >> > > issue, with API breaking change)
> >> > > 
> >> > > IMHO, another consequence could be: maven-resolver-ant-tasks would
> >> > 
> >> > perhaps
> >> > 
> >> > > better be versionned like maven-resolver-provider
> >> > > 
> >> > > 
> >> > > Merging resolver-demos is really the great big idea: with that merge,
> >> > > modifying maven-rresolver can immediately be tested with demos:
> >> > > that'll
> >> > 
> >> > be
> >> > 
> >> > > so much easier to make changes to maven-resolver code!
> >> > > 
> >> > > Regards,
> >> > > 
> >> > > Hervé
> >> > > 
> >> > > Le mercredi 15 novembre 2017, 09:02:12 CET Michael Osipov a écrit
:
> >> > > > Why -1 on the Ant tasks?
> >> > > > 
> >> > > > Am 2017-11-15 um 00:50 schrieb Hervé BOUTEMY:
> >> > > > > I answered on the mailing list and on the 2 Jira issues
> >> > > > > In summary, +1 to merge demos, -1 to merge ant-tasks
> >> > > > > 
> >> > > > > Regards,
> >> > > > > 
> >> > > > > Hervé
> >> > > > > 
> >> > > > > Le mardi 14 novembre 2017, 18:19:40 CET Manfred Moser a
écrit :
> >> > > > >> Any feedback or should I just go ahead with the cleanup?
> >> > > > >> 
> >> > > > >> Manfred
> >> > > > >> 
> >> > > > >> Manfred Moser wrote on 2017-11-08 21:35:
> >> > > > >>> Hi all,
> >> > > > >>> 
> >> > > > >>> I have started and made good progress on getting
Maven resolver
> >> > > > >>> all
> >> > > > >>> into
> >> > > > >>> the master branch instead of having master, demos
and ant-tasks
> >> > > > >>> in
> >> > > > >>> separate branches.
> >> > > > >>> 
> >> > > > >>> Details are tracked in
> >> > > > >>> https://issues.apache.org/jira/browse/MRESOLVER-28
> >> > > > >>> 
> >> > > > >>> All of it is now in a new branch called master-all
for you to
> >> > > > >>> see.
> >> > > > >>> 
> >> > > > >>> I am now wondering what the next steps are. I added
what I
> >> > > > >>> think
> >> > > > >>> should
> >> > > > >>> happen next in the issue in a comment and would
appreciate any
> >> > 
> >> > input
> >> > 
> >> > > > >>> on
> >> > > > >>> the current setup and next steps.
> >> > > > >>> 
> >> > > > >>> Any help would be appreciated.
> >> > > > >>> 
> >> > > > >>> manfred
> >> > 
> >> > ---------------------------------------------------------------------
> >> > 
> >> > > > >> 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
> >> > > 
> >> > > ---------------------------------------------------------------------
> >> > > 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
> >> > 
> >> > --
> >> 
> >> Sent from my phone
> > 
> > ---------------------------------------------------------------------
> > 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