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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > > -- Sent from my phone
