Re: Maven resolver branch consolidation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Maven resolver branch consolidation

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: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven resolver branch consolidation

michaelo
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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven resolver branch consolidation

Hervé BOUTEMY
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.

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: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven resolver branch consolidation

Hervé BOUTEMY
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 <[hidden email]> 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: [hidden email]
> > > > >> For additional commands, e-mail: [hidden email]
> > > > >
> > > > > --------------------------------------------------------------------
> > > > > -
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> > --
>
> Sent from my phone



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven resolver branch consolidation

Manfred Moser-4
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 <[hidden email]> 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: [hidden email]
>> > > > >> For additional commands, e-mail: [hidden email]
>> > > > >
>> > > > > --------------------------------------------------------------------
>> > > > > -
>> > > > > To unsubscribe, e-mail: [hidden email]
>> > > > > For additional commands, e-mail: [hidden email]
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [hidden email]
>> > > For additional commands, e-mail: [hidden email]
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> > --
>>
>> Sent from my phone
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven resolver branch consolidation

Hervé BOUTEMY
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 <[hidden email]> 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: [hidden email]
> >> > > > >> For additional commands, e-mail: [hidden email]
> >> > > > >
> >> > > > > -----------------------------------------------------------------
> >> > > > > ---
> >> > > > > -
> >> > > > > To unsubscribe, e-mail: [hidden email]
> >> > > > > For additional commands, e-mail: [hidden email]
> >> > >
> >> > > ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: [hidden email]
> >> > > For additional commands, e-mail: [hidden email]
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >> >
> >> > --
> >>
> >> Sent from my phone
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Maven resolver branch consolidation

Robert Scholte-8
In reply to this post by Manfred Moser-4
"We can solve any problem by introducing an extra level of indirection."  
[1]

Looking at this new image[1] it is weird to me that ant-tasks has a direct  
dependency on maven-resolver-provider. I would have expected some provider  
abstraction where you can choose to use the maven-resolver-provider.

Merging it into one project is an interesting option, but I think the  
maven-artifact-resolver is isolated enough to deserve its own project.

thanks,
Robert

[1]  
https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering
[2]  
https://git1-us-west.apache.org/repos/asf?p=maven-resolver.git;a=blob_plain;f=src/site/resources/images/maven-resolver-deps.png;hb=f5439fde

On Thu, 16 Nov 2017 18:13:15 +0100, Manfred Moser  
<[hidden email]> wrote:

> 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 <[hidden email]>  
>>> 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: [hidden email]
>>> > > > >> For additional commands, e-mail: [hidden email]
>>> > > > >
>>> > > > >  
>>> --------------------------------------------------------------------
>>> > > > > -
>>> > > > > To unsubscribe, e-mail: [hidden email]
>>> > > > > For additional commands, e-mail: [hidden email]
>>> > >
>>> > >  
>>> ---------------------------------------------------------------------
>>> > > To unsubscribe, e-mail: [hidden email]
>>> > > For additional commands, e-mail: [hidden email]
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: [hidden email]
>>> > For additional commands, e-mail: [hidden email]
>>> >
>>> > --
>>>
>>> Sent from my phone
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven resolver branch consolidation

Manfred Moser-4
Hahah ... what a pain. Since so at this stage I think I will move the demos into the master and leave the ant tasks as they stand and
close the relevant tickets with remarks that details this situation.

Manfred

Robert Scholte wrote on 2017-11-17 03:10:

> "We can solve any problem by introducing an extra level of indirection."  
> [1]
>
> Looking at this new image[1] it is weird to me that ant-tasks has a direct  
> dependency on maven-resolver-provider. I would have expected some provider  
> abstraction where you can choose to use the maven-resolver-provider.
>
> Merging it into one project is an interesting option, but I think the  
> maven-artifact-resolver is isolated enough to deserve its own project.
>
> thanks,
> Robert
>
> [1]  
> https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering
> [2]  
> https://git1-us-west.apache.org/repos/asf?p=maven-resolver.git;a=blob_plain;f=src/site/resources/images/maven-resolver-deps.png;hb=f5439fde
>
> On Thu, 16 Nov 2017 18:13:15 +0100, Manfred Moser  
> <[hidden email]> wrote:
>
>> 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 <[hidden email]>  
>>>> 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: [hidden email]
>>>> > > > >> For additional commands, e-mail: [hidden email]
>>>> > > > >
>>>> > > > >  
>>>> --------------------------------------------------------------------
>>>> > > > > -
>>>> > > > > To unsubscribe, e-mail: [hidden email]
>>>> > > > > For additional commands, e-mail: [hidden email]
>>>> > >
>>>> > >  
>>>> ---------------------------------------------------------------------
>>>> > > To unsubscribe, e-mail: [hidden email]
>>>> > > For additional commands, e-mail: [hidden email]
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: [hidden email]
>>>> > For additional commands, e-mail: [hidden email]
>>>> >
>>>> > --
>>>>
>>>> Sent from my phone
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]