On Wednesday, December 17, 2014, Paul Benedict <[email protected]> wrote:
> 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. No you have it wrong there. Type defaults to `jar` if unspecified, so you will need to declare a type to consume either the zip or tar.gz The only case I know of where you get away from that is the horrible hack in jenkins plugins where you depend on the jar and the hpi plugin up-interprets the actual type from the resolved pom so that hpi "dependencies" are linked at runtime and non-hpi dependencies are packaged in WEB-INF/lib Most of the other packaging types produce jar files and use the packaging to determine the lifecycle Having said all that, the *default* descriptor should be just a zip... But if you override the default you can have a descriptor that produces .tar.gz and .tar.bz2 as well as .zip So I would say that the mojo should: * use its default descriptor if none in src/assembly * use the descriptor if one and only one in src/assembly * fail if more than one descriptor in src/assembly unless the user adds config to say which one to use HTH On Dec 17, 2014 1:26 AM, "Stephen Connolly" <[email protected] > <javascript:;>> > wrote: > > > On Wednesday, December 17, 2014, Paul Benedict <[email protected] > <javascript:;>> > > 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 <[email protected] > <javascript:;> > > > <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 <[email protected] > <javascript:;> > > > <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 < > > > > >> [email protected] <javascript:;> <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 < > > > > [email protected] <javascript:;> <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 < > > > > >> > >> [email protected] <javascript:;> > <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 < > > > [email protected] <javascript:;> <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 < > > > > >> [email protected] <javascript:;> <javascript:;> > > > > >> > >>>> <java script:;>> wrote: > > > > >> > >>>> > > > > >> > >>>> Anders, like make a maven-zip-plugin project? > > > > >> > >>>>> On Dec 11, 2014 1:50 AM, "Anders Hammar" < > [email protected] <javascript:;> > > > <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 < > > > > >> > [email protected] <javascript:;> <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 < > > > > >> > >>>>>>> [email protected] <javascript:;> > <javascript:;> <java > > > script:;>> wrote: > > > > >> > >>>>>>> > > > > >> > >>>>>>>> Probably because people just use the assembly plugin ? > > > > >> > >>>>>>>> > > > > >> > >>>>>>>> Kristian > > > > >> > >>>>>>>> > > > > >> > >>>>>>>> > > > > >> > >>>>>>>> > > > > >> > >>>>>>>> 2014-12-11 6:38 GMT+01:00 Paul Benedict < > > > > [email protected] <javascript:;> <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: [email protected] > <javascript:;> > > > <javascript:;> > > > > >> > >>>>>>>> > > > > >> > >>>>>>> <java script:;> > > > > >> > >>>> > > > > >> > >>>>> For additional commands, e-mail: > [email protected] <javascript:;> > > > <javascript:;> > > > > >> > >>>>>>>> > > > > >> > >>>>>>> <java script:;> > > > > >> > >>>> > > > > >> > >>>>> > > > > >> > >>>>>>>> > > > > >> > >>> -- > > > > >> > >>> Sent from my phone > > > > >> > >>> > > > > >> > >> > > > > >> > > > > > > >> > > > > > >> > -- > > > > >> > Sent from my phone > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > <javascript:;> > > <javascript:;> > > > > For additional commands, e-mail: [email protected] > <javascript:;> > > > <javascript:;> > > > > > > > > > > > > > > > > > -- > > Sent from my phone > > > -- Sent from my phone
