Because if it lands in 4.0.0 then it will break existing POMs that have relied on ZIP files not being added to the classpath.
Only when we get the PDT in 5.0.0 can we safely add them to the classpath... Now a ZIP packaging could do something different... we could have a `classpath-zip` packaging with the extension type `zip` so then if you go `<type>classpath-zip</type>` then Maven would know to look for a zip but add it on the classpath. If you want to do that, :+1: 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 > >
