I
On 3/19/06, Brett Porter <[EMAIL PROTECTED]> wrote:
> Hi Howard,
>
> I answered this question for you here:
> http://mail-archives.apache.org/mod_mbox/maven-users/200511.mbox/[EMAIL
> PROTECTED]
<configuration>
<skip>true</skip>
<source>1.3</source>
<target>1.3</target>
</configuration>
<executions>
<execution>
<configuration>
<skip>false</skip>
<source>1.5</source>
<target>1.5</target>
</configuration>
<goals>
<goal>test-compile</goal>
</goals>
</execution>
</executions>
Does <skip>true</skip> mean skip the normal mojo? I can't quite track
why one <skip> is false, the other true.
>
> I filed: http://jira.codehaus.org/browse/MCOMPILER-15 as a result. You
> might like to watch/vote for it. It should be something we are able to
> support properly, but that workaround should work in either parent or
> individual module in the mean time.
>
> On 3/20/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
> > OK, moving the <plugin> element from the parent POM to the module POM
> > fixes things; it works as expected.
>
> It shouldn't have, I don't think, unless I'm missing something.
It mostly definately did. I had to cut-and-paste it into each module's pom.xml.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>compile</id>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<source>1.3</source>
<target>1.5</target>
<optimize>true</optimize>
</configuration>
</execution>
<execution>
<id>test-compile</id>
<goals>
<goal>testCompile</goal>
</goals>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Using maven -X I was able to see that it built just once (once for
main, once for test), with the correct parameters.
>
> > > I'm interpreting this as:
> > >
> > > "when the goal is compile:compile, use source 1.3, etc." and
> > > "when the goal is "compile:testCompile, user source 1.5, etc."
> > >
> > > However, that's isn't quite what I see when I build:
> > >
>
> An execution is always an additional binding to the lifecycle, so it
> doubles up when it is already bound through the presets for the
> packaging. The only way to configure the presets is through the
> configuration element in the plugin node itself (outside of
> executions). Unfortunately, you only get one per plugin.
The term "plugin node" doesn't really help me here. This is kind of
what I was getting at.
I hate to say this, but a flow chart showing how Maven decides what to
do, how it instantiates Mojos, the algorithm used to collect
configuration information, might be useful.
>From what I can tell, my original setup was creating an additional
compiler Mojo, with a different configuration, that got scheduled
after the normal compiler Mojo, within the compile phase.
What I didn't see was how I could displace the original Mojo and just
leave my own.
I'm not sure my terminology is quite right.
Its pretty important for the underlying structure to be known, or even
knowable. I don't like "Cargo Cult" approaches
(http://www.physics.brocku.ca/etc/cargo_cult_science.html).
>
> I think we should reconsider this use case for 2.1, but also the
> compiler plugin should have separate test configuration that uses the
> others as defaults to avoid doubling up, but allows them to be set
> differently if needed.
>
> > > Further, how am I expected to know the correct goal/phase/whatever
> > > from the documentation? Sometimes Maven feels like an exclusive club
> > > that leaves a lot of people, people not initmately familiar with the
> > > source code and implications thereof, out in the cold!
>
> I attempted to explain how executions work here:
> http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
My head still spins at the relationship between phases and goals, and
the relationship between goals and plugins.
I'd love to see a MUCH more detailed multi-project example, that
includes some of my usecases (i.e., reports, dependencies, and certain
plugin configurations defined in a parent POM), plus all the other
details in terms of getting source packaged and ultimately getting
source and binaries distributed into a repository. I've got some of
these things figured out, but always with odd side-effects, such as
running surefire multiple times.
Importantly, don't just show a snippet of XML; please try to explain
how that XML, and the objects it represents, fits into the overall
runtime model of Maven.
Thanks for the help! I'm off to figure out to convert reams of
Forrest XML documentation into Maven XML or APT.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
