Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
From: =?ISO-8859-1?Q?Herv=E9?= BOUTEMY <herve.boutemy@free.fr>
To: Maven Developers List <dev@maven.apache.org>
Subject: Re: Maven resolver branch consolidation
Date: Fri, 17 Nov 2017 19:03:45 +0100
Message-ID: <4446841.k3EPkmc5E0@giga>
In-Reply-To: <op.y9uhcbmikdkhrr@desktop-2khsk44>
References: <20171109053551.957D429C50D1@dd17332.kasserver.com> <20171116171315.3663629C0081@dd17332.kasserver.com> <op.y9uhcbmikdkhrr@desktop-2khsk44>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
archived-at: Fri, 17 Nov 2017 18:03:57 -0000

this won't work: you'll be able to fool the compiler, but not maven-shade-
plugin when it builds the full jar with runtime dependencies

Regards,

Herv=E9

Le vendredi 17 novembre 2017, 12:10:49 CET Robert Scholte a =E9crit :
> "We can solve any problem by introducing an extra level of indirection."
> [1]
>=20
> 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.
>=20
> Merging it into one project is an interesting option, but I think the
> maven-artifact-resolver is isolated enough to deserve its own project.
>=20
> thanks,
> Robert
>=20
> [1]
> https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering
> [2]
> https://git1-us-west.apache.org/repos/asf?p=3Dmaven-resolver.git;a=3Dblob=
_plain;
> f=3Dsrc/site/resources/images/maven-resolver-deps.png;hb=3Df5439fde
>=20
> On Thu, 16 Nov 2017 18:13:15 +0100, Manfred Moser
>=20
> <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.
> >=20
> > 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.
> >=20
> > 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?
> >=20
> > 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..
> >=20
> > Manfred
> >=20
> > Herv=E9 BOUTEMY wrote on 2017-11-16 05:49:
> >> feasible, but I really don't like it: separation is good.
> >>=20
> >> 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...)
> >>=20
> >> Regards,
> >>=20
> >> Herv=E9
> >>=20
> >> Le jeudi 16 novembre 2017, 10:03:07 CET Stephen Connolly a =E9crit :
> >>> On Thu 16 Nov 2017 at 07:51, Herv=E9 BOUTEMY <herve.boutemy@free.fr>
> >>>=20
> >>> wrote:
> >>> > I just pushed an update of dependencies image that shows the extern=
al
> >>> > maven-
> >>> > resolver-provider (in yellow) inside the reactor dependency graph (=
in
> >>> > blue)
> >>> >=20
> >>> > 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
> >>>=20
> >>> the
> >>>=20
> >>> > issue
> >>> > also.
> >>> >=20
> >>> > 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
> >>>=20
> >>> not
> >>>=20
> >>> > publish
> >>> > the artifact: this will have a visible impact.
> >>>=20
> >>> Should we just bite the bullet and bring resolver in-tree as modules =
in
> >>> maven core... leaving demos and ant tasks here?
> >>>=20
> >>> > Regards,
> >>> >=20
> >>> > Herv=E9
> >>> >=20
> >>> > Le mercredi 15 novembre 2017, 23:05:14 CET Herv=E9 BOUTEMY a =E9cri=
t :
> >>> > > it seems I have not been clear: I'll try to explain better
> >>> > >=20
> >>> > > 1. maven-resolver-ant-tasks depends on maven-resolver-provider
> >>>=20
> >>> (from
> >>>=20
> >>> > Maven
> >>> >=20
> >>> > > core)
> >>> > > 2. maven-resolver-provider (then Maven core) depends on
> >>>=20
> >>> maven-resolver
> >>>=20
> >>> > > if we put maven-resolver-ant-tasks in the same reactor than
> >>> >=20
> >>> > maven-resolver,
> >>> >=20
> >>> > > we can't release any maven-resolver API change that breaks
> >>> >=20
> >>> > maven-resolver-
> >>> >=20
> >>> > > provider
> >>> > >=20
> >>> > > example: if we move maven-resolver code to org.apache.maven java
> >>>=20
> >>> package
> >>>=20
> >>> > in
> >>> >=20
> >>> > > 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
> >>>=20
> >>> new
> >>>=20
> >>> > > java
> >>> > > package. Then try to release anything: you can't, unless you don't
> >>>=20
> >>> try
> >>>=20
> >>> > > to
> >>> > > release maven- resolver-ant-tasks
> >>> > >=20
> >>> > > (the consequence on version consistency is another way to describe
> >>>=20
> >>> the
> >>>=20
> >>> > > issue, but that is more subtle, then I chose to describe the most
> >>> > > visible
> >>> > > issue, with API breaking change)
> >>> > >=20
> >>> > > IMHO, another consequence could be: maven-resolver-ant-tasks would
> >>> >=20
> >>> > perhaps
> >>> >=20
> >>> > > better be versionned like maven-resolver-provider
> >>> > >=20
> >>> > >=20
> >>> > > Merging resolver-demos is really the great big idea: with that
> >>>=20
> >>> merge,
> >>>=20
> >>> > > modifying maven-rresolver can immediately be tested with demos:
> >>> that'll
> >>>=20
> >>> > be
> >>> >=20
> >>> > > so much easier to make changes to maven-resolver code!
> >>> > >=20
> >>> > > Regards,
> >>> > >=20
> >>> > > Herv=E9
> >>> > >=20
> >>> > > Le mercredi 15 novembre 2017, 09:02:12 CET Michael Osipov a =E9cr=
it :
> >>> > > > Why -1 on the Ant tasks?
> >>> > > >=20
> >>> > > > Am 2017-11-15 um 00:50 schrieb Herv=E9 BOUTEMY:
> >>> > > > > I answered on the mailing list and on the 2 Jira issues
> >>> > > > > In summary, +1 to merge demos, -1 to merge ant-tasks
> >>> > > > >=20
> >>> > > > > Regards,
> >>> > > > >=20
> >>> > > > > Herv=E9
> >>> > > > >=20
> >>> > > > > Le mardi 14 novembre 2017, 18:19:40 CET Manfred Moser a =E9cr=
it :
> >>> > > > >> Any feedback or should I just go ahead with the cleanup?
> >>> > > > >>=20
> >>> > > > >> Manfred
> >>> > > > >>=20
> >>> > > > >> Manfred Moser wrote on 2017-11-08 21:35:
> >>> > > > >>> Hi all,
> >>> > > > >>>=20
> >>> > > > >>> I have started and made good progress on getting Maven
> >>>=20
> >>> resolver
> >>>=20
> >>> > > > >>> all
> >>> > > > >>> into
> >>> > > > >>> the master branch instead of having master, demos and
> >>>=20
> >>> ant-tasks in
> >>>=20
> >>> > > > >>> separate branches.
> >>> > > > >>>=20
> >>> > > > >>> Details are tracked in
> >>> > > > >>> https://issues.apache.org/jira/browse/MRESOLVER-28
> >>> > > > >>>=20
> >>> > > > >>> All of it is now in a new branch called master-all for you
> >>>=20
> >>> to see.
> >>>=20
> >>> > > > >>> I am now wondering what the next steps are. I added what I
> >>>=20
> >>> think
> >>>=20
> >>> > > > >>> should
> >>> > > > >>> happen next in the issue in a comment and would appreciate
> >>>=20
> >>> any
> >>>=20
> >>> > input
> >>> >=20
> >>> > > > >>> on
> >>> > > > >>> the current setup and next steps.
> >>> > > > >>>=20
> >>> > > > >>> Any help would be appreciated.
> >>> > > > >>>=20
> >>> > > > >>> manfred
> >>> >=20
> >>> > -------------------------------------------------------------------=
=2D-
> >>> >=20
> >>> > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> >>>=20
> >>> --------------------------------------------------------------------
> >>>=20
> >>> > > > > -
> >>> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> >>>=20
> >>> ---------------------------------------------------------------------
> >>>=20
> >>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> > > For additional commands, e-mail: dev-help@maven.apache.org
> >>> >=20
> >>> > -------------------------------------------------------------------=
=2D-
> >>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> > For additional commands, e-mail: dev-help@maven.apache.org
> >>> >=20
> >>> > --
> >>>=20
> >>> Sent from my phone
> >>=20
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >=20
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>=20
> ---------------------------------------------------------------------
> 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