I think having an assembly type with a default binding of assembly:single to the packaging phase and a default descriptor being the zip or zip and tar.gz descriptors would achieve what is required while simplifying escalating to more complex descriptors
On Thursday, December 11, 2014, Timothy Astle <timothy.as...@caris.com> wrote: > I have a situation/problem/use-case where I would like to take a > collection of XML schemas and create a bundle of themso that they could be > included into other projects. The destination projects vary. Some are > written in Java, some in C++, etc. So I'd like to produce amore platform > agnostic bundling artifact. At the moment, we lean on Subversion externals, > which I really dislike doing. > > In this type of case, I figured a ZIP packaging type would have described > the project and produced the expected output, while using Maven. A big > thing that I like about Maven is how you model the project. Plugins are > great, but opening up a POM and seeing the packaging type is just so nice > and explicit. > > There are several ways I can accomplish my goal, but somewhere, deepdown, > Ihad hoped that I'd live long enough to see a first-class ZIP packaging > type become available. :-) > > Tim > > > On 11/12/2014 4:41 AM, domi wrote: > >> Hmm, not sure I agree - I think its just fact that users would love to >> have simpler way to create ZIPs/TARs >> and the most logical/simple way (from a users point of view) to do this >> is a packaging typ for these. >> Domi >> >> >> On 11.12.2014, at 09:27, Stephen Connolly < >> stephen.alan.conno...@gmail.com> wrote: >> >> Well the real question is what would you do with dependencies? >>> >>> So, for example, if you have a zip dependency, do you unpack it and >>> overlay >>> or do you copy it in? Or do you do nothing and leave it to the dependency >>> plugin? >>> >>> What about zip vs tar.gz dependency? If building a zip I might expect >>> exploding the zip dependencies and copy tar.gz? >>> >>> A better approach might be an "assembly" packaging with a default >>> assembly descriptor directory and if empty it falls back to zip and >>> tar.gz >>> of target/classes with the resources plugin being in the default >>> lifecycle >>> binding >>> >>> That would make using the assembly plugin less work and ack the fact >>> that a >>> zip or tar.gz needs the descriptor to control file permissions >>> >>> On Thursday, December 11, 2014, Anders Hammar <and...@hammar.net> wrote: >>> >>> Yes, but I don't think making a specific plugin just for adding zip >>>> packaging is optimal. Hence the idea of having it in the assembly >>>> plugin. >>>> Thinking of it though, one very likely wants to create both a zip and a >>>> tar >>>> file. So maybe the packaging type should be something else, and then it >>>> creates both types. But then I always advocate that one maven project >>>> should only create one artifact...hmm. >>>> >>>> /Anders >>>> >>>> On Thu, Dec 11, 2014 at 8:55 AM, Paul Benedict <pbened...@apache.org >>>> <javascript:;>> wrote: >>>> >>>> Anders, like make a maven-zip-plugin project? >>>>> On Dec 11, 2014 1:50 AM, "Anders Hammar" <and...@hammar.net >>>>> >>>> <javascript:;>> wrote: >>>> >>>>> I don't think that the zip package type should be part of Maven core, >>>>>> >>>>> but >>>> >>>>> we could provide some plugin which provides for it as a custom >>>>>> >>>>> packaging >>>> >>>>> type. Possibly this could be part of the assembly plugin. >>>>>> >>>>>> /Anders >>>>>> >>>>>> On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict <pbened...@apache.org >>>>>> >>>>> <javascript:;>> >>>> >>>>> wrote: >>>>>> >>>>>> Well my experience in building a zip *as a dependency* feels like >>>>>>> >>>>>> it's >>>> >>>>> hackish. For example, I create a "pom" packaging type and then >>>>>>> >>>>>> configure >>>>> >>>>>> the assembly plugin for the "package" phase. Okay, but I say this is >>>>>>> hackish because it's not straight forward, and the zip is a second >>>>>>> >>>>>> artifact >>>>>> >>>>>>> (the pom is first) for installation. This pattern kind of smells to >>>>>>> >>>>>> me >>>> >>>>> and >>>>>> >>>>>>> makes me think an official "zip" type really is needed. Having such a >>>>>>> >>>>>> type >>>>>> >>>>>>> can take away all this boilerplate. >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Paul >>>>>>> >>>>>>> On Thu, Dec 11, 2014 at 12:27 AM, Kristian Rosenvold < >>>>>>> kristian.rosenv...@gmail.com <javascript:;>> wrote: >>>>>>> >>>>>>>> Probably because people just use the assembly plugin ? >>>>>>>> >>>>>>>> Kristian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2014-12-11 6:38 GMT+01:00 Paul Benedict <pbened...@apache.org >>>>>>>> >>>>>>> <javascript:;>>: >>>> >>>>> Recently I needed to create zip artifacts for overlays into WAR. >>>>>>>>> >>>>>>>> Maven >>>>>> >>>>>>> doesn't have support for "zip" packaging type projects, but >>>>>>>>> >>>>>>>> MNG-1683 >>>>> >>>>>> wants >>>>>>>> >>>>>>>>> to introduce it. >>>>>>>>> >>>>>>>>> I am curious why this issue has been ignored. Is it just a lack >>>>>>>>> >>>>>>>> of >>>> >>>>> time >>>>>> >>>>>>> or >>>>>>>> >>>>>>>>> interest? Or is there a philosophical issue behind the delay? I >>>>>>>>> >>>>>>>> can't >>>>> >>>>>> see >>>>>>> >>>>>>>> much difference between the zip lifecycle and jar lifecycle >>>>>>>>> >>>>>>>> except >>>> >>>>> there >>>>>>> >>>>>>>> is >>>>>>>> >>>>>>>>> no default "compile" or "test" bindings. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Paul >>>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------ >>>> --------- >>>> >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>> >>>>>>> <javascript:;> >>>> >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>> >>>>>>> <javascript:;> >>>> >>>>> >>>>>>>> >>> -- >>> Sent from my phone >>> >> > -- Sent from my phone
