maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject Re: Unpacking jars into target/classes
Date Mon, 18 Mar 2013 22:52:45 GMT
On 18 March 2013 21:48, Joachim Durchholz <> wrote:

> Am 18.03.2013 12:45, schrieb Stephen Connolly:
>  I would not base your opinion on this one thread.
>> Joachim got off on the wrong foot by mistaking us trying to guide him
>> towards a path (where he won't fight maven all the way) for us being
>> evangelical and spouting religious dogma...
> Just for the record: I heartily disagree with that view of what happened
> there.
> In fact I have reason to believe that such a path doesn't even exist, and
> in more situations than any Maven proponent would like to admit.
> Of course, Maven proponents would heartily disagree with that view, and in
> fact that part of the debate never reached a conclusion (nor will it ever,
> I think).

Well I think there is a path, but let's not re-open that whole thing right

Perhaps when I revamp the docs you might consider reading them and then
respond because I believe at that point you might agree that I had a valid
point and that there is a path... just a path that you don't want to go
down because your experiences have coloured how you evaluate the set of
trade-offs that need to be made.

> > Some of us in this list may
>> have egged on the troll vs troll style of this interaction, but the past
>> is
>> a foreign country that we cannot visit, personally I think it should be
>> left behind, fault on both sides, therefore both sides gave some learning
>> to do.
> I can agree with that.
>  I am currently working on trying to find a way to revamp the main maven
>> site to make it easier for people to get up to speed and grok the reasons
>> for maven picking the sides it picks as well as grok *where* maven says
>> "not my problem" (anything after a deployment environment agnostic
>> artifact
>> has been delivered into the maven repository is not maven's problem BTW,
>> use other tools: Chef/Puppet/ANT/Gradle/Buildr/**BASH/etc to turn that
>> into
>> an artifact configured for the specific environment it will be deployed
>> into and put it in that environment)
> Good plan.
> I'd also add a paragraph that Maven is not a toolbox, with the tools to be
> mixed and matched as a desired workflow mandates. Instead, you're supposed
> to study the workflows available, select the one that best fits your
> requirements, and stick with that no matter what. Of course you can
> configure the workflows, but the extent to which that is possible is
> strictly controlled.

I think you really should wait for me to revamp the docs before making that
kind of proposition.

Maven has one primary lifecycle and considers its core responsibility to be
delivering artifacts that are target agnostic into the maven repository.
What you can do in that lifecycle is very mix and match and a lot more
flexible than you would suspect, but after the end of that lifecycle you
should not be using Maven.

Handling the mix and match most likely will involve writing either
extensions (unlikely) or plugins (most likely) which will need to be pushed
to a Maven repository...

If you don't have an internal Maven repository manager to host such things,
or if you cannot push those plugins/extensions to central, then you might
not realize how flexible Maven is in this respect

> I consider that approach to be a core mistake in Maven's, but I can agree
> to disagree about that one and move on, in the knowledge that little could
> be done about it even if it's true so there's little to be gained in
> discussing that.

> What we probably can agree on is that (a) the workflows are implicit in
> what's available in the plugins and what isn't, which makes it hard to get
> an overview of the available workflows and select the right one;

There is 1 primary lifecycle: initialize -> ... -> compile -> ... -> test
-> ... -> package -> ... -> verify -> install -> deploy

There are different packagings: jar/war/ear/etc

I am guessing that you are referring to these as workflows.

Defining custom packaging is actually quite trivial, just an XML file in a
.jar that you add as a build extension (or include in a maven plugin). You
can do quite a lot with that.

The Maven project can only document our packagings and their lifecycles:

We cannot be responsible for documenting other people's lifecycles. For
example (and I am pointing now at a personal project) the
jszip-maven-plugin defines its own lifecycle:
documentation of that lifecycle is not the responsibility of the Maven
project (or the ASF unless/until I seek to move that project into the ASF,
but that is a separate story).

I agree that it can be hard to decide what packaging type to pick for your
use case when there are multiple similar ones, e.g. webjars is solving a
similar problem to jszip so if you are packaging up javascript "modules"
for consumption by Maven projects which should you choose? That is a hard

But if you are building a .jar file then you really just have three
  1. <packaging>jar</packaging> (if you don't give a rats arse about OSGi);
  2. <packaging>bundle</packaging> (if you need OSGi)
  3. your own custom lifecycle if one of the above does not fit your needs.

But of course the problem that kicked this whole thread off has a simple
solution, one that I mentioned quite some time ago, but I think you
ignored. Namely making proxy modules for each of the 3rd party jars that
you have to consume. They are just a pom.xml in a directory and they attach
the jar you are getting from the file system into the reactor in place of
the jar produced by jar:jar... they look a little something like this:

<?xml version="1.0" encoding="utf-8"?>
<project xmlns="" xmlns:xsi="" xsi:schemaLocation="">


                <copy file="foobar.jar"


You have one of those for each non maven artifact and you just ensure that
the correct dependencies are listed and that these pom files are referenced
in the root aggregator pom and presto-chango there is your build. AFAIR I
even suggested this when you first came to the list. It's a little hacky...
you could do better with a custom lifecycle and your own plugin, but mostly
around removing some boilerplate and simplification of the pom... but that
would require pushing the maven plugin to a MRM (or central) and off we go

> and (b) the problem is massively worsened if plugin descriptions are vague
> or incomplete, and that this has in fact grown to be a real problem.

Well docs are a problem, and then the slew of poorly written plugins (99%
of the org.apache.maven.plugins and org.codehaus.mojo plugins are not in
this category) with no documentation that don't follow the Maven principles
(and instead just blindly rely on defaults) which make it harder to deviate
from some aspects of the Maven way when it is needed.

> Which is why I wholeheartedly agree that Maven could profit from better
> docs. Even if I disagree about what it should do ;-)
> Regards,
> Jo
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**<>
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message