> 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. This looks overengineered to me. n types of ZIPs? We don't have this for JAR either.
> 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 > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
