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 Tue, 19 Mar 2013 11:13:15 GMT
On 18 March 2013 22:52, Stephen Connolly <>wrote:

> 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
> now.
> 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:
> pom/jar/war/ear/rar/ejb-jar
> 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
> problem.
> But if you are building a .jar file then you really just have three
> choices:
>   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="
> ">
>   <modelVersion>4.0.0</modelVersion>
>   <groupId></groupId>
>   <artifactId>manchu</artifactId>
>   <version>1-SNAPSHOT</version>
>   <packaging>jar</packaging>
>   <build>
>     <plugins>
>       <plugin>
>         <artifactId>maven-antrun-plugin</artifactId>
>         <version>1.7</version>
>         <executions>
>           <execution>
>             <id>attach-artifacts</id>
>             <phase>package</phase>
>             <goals>
>               <goal>run</goal>
>             </goals>
>             <configuration>
>               <target>
>                 <copy file="foobar.jar"
> tofile="${}/${}.jar"
> overwrite="true"/>
>               </target>
>             </configuration>
>           </execution>
>         </executions>
>       </plugin>
>     </plugins>
>   </build>
> </project>
> 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
> again!


Just for you, I have taken the 30 minutes out of my life and written a
Maven Plugin that will solve your issues with those pesky non-maven

You will need to wait a couple of hours for the sync to central before you
can use that plugin.

But it is designed for your exact use-case (adapted to the Maven way of
course ;-) )


>> 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