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 > <manf...@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.bout...@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-unsubscr...@maven.apache.org >>>> > > > >> For additional commands, e-mail: dev-h...@maven.apache.org >>>> > > > > >>>> > > > > >>>> -------------------------------------------------------------------- >>>> > > > > - >>>> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> > > > > For additional commands, e-mail: dev-h...@maven.apache.org >>>> > > >>>> > > >>>> --------------------------------------------------------------------- >>>> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> > > For additional commands, e-mail: dev-h...@maven.apache.org >>>> > >>>> > --------------------------------------------------------------------- >>>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> > For additional commands, e-mail: dev-h...@maven.apache.org >>>> > >>>> > -- >>>> >>>> Sent from my phone >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
