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
