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
>

Reply via email to