I am in agreement with Stephen. If I decide to try to prototype this out, where is a good place to lay down some code?
Cheers, Paul On Thu, Dec 11, 2014 at 7:29 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > > 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 >