On 9 February 2017 at 10:26, Michael Osipov <1983-01...@gmx.net> wrote:
> Why not 4.0.0? I think this must come in tandem with Packaging zip
finally.
>
> > I don't see any compelling reason to add zips to the classpath now.
> >
> > We should have maybe done it from the start, but I don't see that
we can
> do
> > it now before 5.0.0
> >
> > (And I am not even seeing a compelling reason to add it then...
just it
> > won't be as problematic)
> >
> > On Wed 8 Feb 2017 at 20:11, Michael Osipov <micha...@apache.org>
wrote:
> >
> > > Am 2017-02-07 um 10:07 schrieb Jörg Schaible:
> > > > Hi,
> > > >
> > > > there's currently a discussion in JIRA regarding MNG-5576 (Zips
on
> > > classpth)
> > > > and Michael Osipov suggested to bring the discussion to the dev
list.
> > > > Actually this already happened once last August:
> > > >
> > > > Paul Benedict wrote:
> > > >
> > > >> I would like to reopen MNG-5567 because I find the solution
> incomplete.
> > > As
> > > >> the ticket stands today, any "zip" listed as a dependency will
get
> put
> > > on
> > > >> the classpath. The rationale behind that decision was:
> > > >>
> > > >> (a) the classpath supports "zip" extensions
> > > >> (b) there is apparently no harm in automatically putting
everything
> > > "zip"
> > > >> on the classpath
> > > >> (c) there is no apparent reason to opt-out
> > > >>
> > > >> I have an issue with (b) and (c). Here's why:
> > > >>
> > > >> First, it violates the principle that developers should
control what
> > > goes
> > > >> on the classpath. I really can't believe Maven would wrestle
this
> > > control
> > > >> away. The assumption that every "zip" is meant to be on the
> classpath is
> > > >> erroneous. This is not the case and Maven shouldn't
automatically
> assume
> > > >> it. Even if Maven was to assume it, the lack of opt-in behavior
> gives no
> > > >> escape hatch.
> > > >>
> > > >> Second, for projects that I personally deal with, these "zip"
> artifacts
> > > >> are nothing but shared front-end web resources. These are not
meant
> to
> > > on
> > > >> the class path. The dependencies are there so other goals can
unpack
> > > them
> > > >> during the build and place them in the context root.
> > > >>
> > > >> Third, it's possible a "zip" non-classpath resource could
conflict
> with
> > > a
> > > >> same named resource in the classpath. I haven't had to be
concerned
> with
> > > >> this (yet), but I will be on the lookout if MNG-5567 doesn't
change.
> > > >
> > > > my concern is also (b), because it is today quite common to use
the
> > > assembly
> > > > plugin to create attached artficats with additional resources
> required
> > > later
> > > > elsewhere (SQL scripts, WSDLs and their schema files, start
scripts,
> > > ...).
> > > > None of this stuff is meant to be on classpath.
> > > >
> > > > On top, all these artifacts will suddenly inject transitive
> dependencies
> > > > whereever they are referenced - just by using a new Maven
version.
> We'll
> > > > face bloated WARs and EARs with stuff not belonging there for
> *existing*
> > > > projects. IMHO MNG-4467 has much more unwanted side-effects in
the
> curent
> > > > ecosystem compared to the support of one or two projects that
deliver
> > > their
> > > > Java archives as ZIP files.
> > >
> > > Seems like there no opinion on that. What now?
> > >
> > >
> > >
> > >
---------------------------------------------------------------------
> > > 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
>
>
