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
