maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <rfscho...@apache.org>
Subject Re: Maven resolver branch consolidation
Date Fri, 17 Nov 2017 11:10:49 GMT
"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  
<manfred@simpligility.com> 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 <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

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


Mime
View raw message