Stephen, I don't feel strongly about it but I don't think there is another option. Unlike assembly:single which is used to create multiple distributions, this is about creating an artifact destined to be consumed as a dependency. Correct me if wrong, but Maven artifact types are meant to produce one single/prime artifact, otherwise you have to begin specifying "type" element on your dependencies. On Dec 17, 2014 1:26 AM, "Stephen Connolly" <stephen.alan.conno...@gmail.com> wrote:
> On Wednesday, December 17, 2014, Paul Benedict <pbened...@apache.org> > wrote: > > > With regards to the mythical "assembly" type, just like other artifact > > types, there is just only one primary artifact. Unlike running > > assembly:single, which can output multiple files (.zip, .gz, etc.), the > > output here will be just one artifact. Does anyone disagree with that > > perspective? If multiple files can still be generated, we'd still have to > > choose one as the primary, no > > > I would say that there is only one *descriptor* > > That descriptor could produce multiple formats, .zip and .tar.gz for > example > > But if you feel strongly otherwise... > > > > > > > > > > Cheers, > > Paul > > > > On Tue, Dec 16, 2014 at 11:25 AM, Manfred Moser <manf...@mosabuam.com > > <javascript:;>> > > wrote: > > > > > > I like this approach as well. Having to have an attached artifact to > have > > > a zip or tar.gz with a meaningless pom or jar always seemed a bit > weird. > > > > > > manfred > > > > > > Stephen Connolly wrote on 11.12.2014 07:14: > > > > > > > either mojo or a pull request against the assembly plugin (as you may > > > need > > > > to tweak the assembly:single default parameters) > > > > > > > > On 11 December 2014 at 14:54, Paul Benedict <pbened...@apache.org > > <javascript:;>> > > > wrote: > > > > > > > >> 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 <javascript:;>> 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 <javascript:;>> > > > >> > 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 <javascript:;>> 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 <javascript:;>> > > > >> > 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:;> > > > >> > >>>> <java script:;>> wrote: > > > >> > >>>> > > > >> > >>>> Anders, like make a maven-zip-plugin project? > > > >> > >>>>> On Dec 11, 2014 1:50 AM, "Anders Hammar" <and...@hammar.net > > <javascript:;> > > > >> > >>>>> > > > >> > >>>> <java script:;>> 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:;> > > > >> > >>>>>> > > > >> > >>>>> <java script:;>> > > > >> > >>>> > > > >> > >>>>> 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:;> <java > > script:;>> wrote: > > > >> > >>>>>>> > > > >> > >>>>>>>> Probably because people just use the assembly plugin ? > > > >> > >>>>>>>> > > > >> > >>>>>>>> Kristian > > > >> > >>>>>>>> > > > >> > >>>>>>>> > > > >> > >>>>>>>> > > > >> > >>>>>>>> 2014-12-11 6:38 GMT+01:00 Paul Benedict < > > > pbened...@apache.org <javascript:;> > > > >> > >>>>>>>> > > > >> > >>>>>>> <java script:;>>: > > > >> > >>>> > > > >> > >>>>> 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:;> > > > >> > >>>>>>>> > > > >> > >>>>>>> <java script:;> > > > >> > >>>> > > > >> > >>>>> For additional commands, e-mail: dev-h...@maven.apache.org > > <javascript:;> > > > >> > >>>>>>>> > > > >> > >>>>>>> <java script:;> > > > >> > >>>> > > > >> > >>>>> > > > >> > >>>>>>>> > > > >> > >>> -- > > > >> > >>> Sent from my phone > > > >> > >>> > > > >> > >> > > > >> > > > > > >> > > > > >> > -- > > > >> > Sent from my phone > > > >> > > > > >> > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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 >
