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?
Cheers, Paul On Tue, Dec 16, 2014 at 11:25 AM, Manfred Moser <manf...@mosabuam.com> 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> > 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> 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 > >> > >>>> <java script:;>> wrote: > >> > >>>> > >> > >>>> Anders, like make a maven-zip-plugin project? > >> > >>>>> On Dec 11, 2014 1:50 AM, "Anders Hammar" <and...@hammar.net > >> > >>>>> > >> > >>>> <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 > >> > >>>>>> > >> > >>>>> <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 <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 > >> > >>>>>>>> > >> > >>>>>>> <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 > >> > >>>>>>>> > >> > >>>>>>> <java script:;> > >> > >>>> > >> > >>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >>>>>>>> > >> > >>>>>>> <java script:;> > >> > >>>> > >> > >>>>> > >> > >>>>>>>> > >> > >>> -- > >> > >>> Sent from my phone > >> > >>> > >> > >> > >> > > > >> > > >> > -- > >> > Sent from my phone > >> > > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
