1 Module - N output jars

[Alexis Midon <al...@gmail.com>]

Hi all,

I'm currently migrating a big project from Ant to Maven.
I have exploded the source code in modules as much as possible but for
legacy reasons I want one of them to generate N output jars (instead of a
single one).

My question is How can I do that?
I have several leads but some questions remain.
Here they are :

1. add to package phase an antrun plugin to create the desired jars,
   but then the underlying question is: how to disable the 'jar:jar' goal
during this phase?

1bis. use the assembly plugin to build several jars, sounds quite cumbersome
and not better than the ant plugin solution.

2. is there a way to make the jar plugin generate several jars?

Thanks for your help!

Alexis

Re: 1 Module - N output jars

[Russ Tremain <Ru...@Sun.COM>]

At 12:48 PM -0400 7/27/06, John Casey wrote:
>One of the fundamental principles that Maven operates on is the 1:1
>association of POMs to primary output artifacts (not counting special
>assemblies, source, or javadoc jars). If you want, you might be able to
>construct a set of POMs that all reference the same source directory, and
>setup compiler excludes configurations such that each POM generates a jar
>based on a different subset of the sources in that single directory...


I wonder why the compiler-plugin doesn't let us set the output directory so
we don't have to propogate poms?

(snipet from maven-compiler-2.1-SNAPSHOT/META-INF/maven/plugin.xml):

        <parameter>
          <name>outputDirectory</name>
          <type>java.io.File</type>
          <required>true</required>
          <editable>false</editable>
          <description>The directory for compiled classes.</description>
        </parameter>

This seems to be a common design "feature" in many of the standard plugins -
they are only tested for one instantiation per build cycle, and give the
user little control over the configuration of secondary executions.

Or is there a hidden way to configure the default execution such that
the configuration won't override subsequent executions of the same
plugin?  The only way that seems to be implied is to use a <configuration>
element in parallel with <executions>, i.e.:

<project><build>
...
<plugin>
<artifactId>maven-some-plugin</artifactId>
<configuration>
[A]
</configuration>
    <executions>
        <execution>
            <configuration>
                [B]
            </configuration>

In the plugins I tried, [A] trumps [B] (jar-plugin, resources-plugin, surefire-plugin)

But why would I specify [B] if I wanted to use [A]?

In other words, the [A] configuration seems to be recognized for the
default (or implied) execution of say, the jar-plugin, but in specifying [A],
we no longer have [B] available.

On the other hand, if we specify:

    <executions>
        <execution>
            <configuration>
                [B]
            </configuration>
        </execution>
        <execution>
            <configuration>
                [C]
            </configuration>
        </execution>

Then I can successfully provide 2 configurations in addition to the "implied",
untouched configuration.

What this means in the case of the jar-plugin, is, we get 3 executions
instead of 2 in order to create 2 jars.  One jar is wasted.  This is true
regardless of whether or not we use ant, since there appears to be no way to
turn off the default jar execution during packaging.  (This is a case where
the source tree is generated as a unit, and then packaged into two
non-overlapping jars).

Or, again, is there an way to specify a configuration for the default <execution>
with some magic <id> element?

Bottom line is I think that if I go to the trouble of specifying
an configuration for an execution, then mvn should use it, and we should
have clearly defined semantics for plug-in writers on how to handle
the scope of a configuration element.

This would greatly reduce the amount of ant code that is required in
an m2 project, especially a large legacy project where we don't necessarily
have the luxury of implementing the one-artifact-per-pom dogma pervasively.

In the case of the jar-plugin, simply providing <include>/<exclude>
elements would go a long way in solving our particular packaging problems,
but this would have to be in addition to a fix for the configuration scoping
problem outlined above.

-Russ

>On 7/27/06, Alexis Midon <al...@gmail.com> wrote:
>>
>>Hi all,
>>
>>I'm currently migrating a big project from Ant to Maven.
>>I have exploded the source code in modules as much as possible but for
>>legacy reasons I want one of them to generate N output jars (instead of a
>>single one).
>>
>>My question is How can I do that?
>>I have several leads but some questions remain.
>>Here they are :
>>
>>1. add to package phase an antrun plugin to create the desired jars,
>>   but then the underlying question is: how to disable the 'jar:jar' goal
>>during this phase?
>>
>>1bis. use the assembly plugin to build several jars, sounds quite
>>cumbersome
>>and not better than the ant plugin solution.
>>
>>2. is there a way to make the jar plugin generate several jars?
>>
>>Thanks for your help!
>>
>>Alexis


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: 1 Module - N output jars

[John Casey <ca...@gmail.com>]

One of the fundamental principles that Maven operates on is the 1:1
association of POMs to primary output artifacts (not counting special
assemblies, source, or javadoc jars). If you want, you might be able to
construct a set of POMs that all reference the same source directory, and
setup compiler excludes configurations such that each POM generates a jar
based on a different subset of the sources in that single directory...

On 7/27/06, Alexis Midon <al...@gmail.com> wrote:
>
> Hi all,
>
> I'm currently migrating a big project from Ant to Maven.
> I have exploded the source code in modules as much as possible but for
> legacy reasons I want one of them to generate N output jars (instead of a
> single one).
>
> My question is How can I do that?
> I have several leads but some questions remain.
> Here they are :
>
> 1. add to package phase an antrun plugin to create the desired jars,
>    but then the underlying question is: how to disable the 'jar:jar' goal
> during this phase?
>
> 1bis. use the assembly plugin to build several jars, sounds quite
> cumbersome
> and not better than the ant plugin solution.
>
> 2. is there a way to make the jar plugin generate several jars?
>
> Thanks for your help!
>
> Alexis
>
>