You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Bocalinda <bo...@gmail.com> on 2009/05/11 16:28:41 UTC
Cargo and multi-module projects
Hi List,
In order to achieve automatic testing of my projects, I use Cargo to
automatically deploy newly generated war files to a Tomcat server.
All the specifics to the automatic testing (depedencies, plugin
configuration, etc) are contained inside of a super pom.
Because I have multitudes of projects, the super pom is quite general, thus
no specific info can be specified, such as exact war names, etc. as this
depends on the project that is being build.
Now, each project that I have specifies the super pom as it's parent, and
until now this was working great.
However, I got a project that consists out of different modules:
1. DAO jar
2. Manager jar
2. Webapp (which includes the DAO and the manager)
Now, to not have to invoke the creation of the DAO, manager and the webapp
manually, I created a parent pom which specifies out of which modules (the
dao, manager and the webapp) the project consists. This works great as well
(Really love Maven).
However, in this parent pom (which is of the type "pom") I also wanted to
include my super pom (with the generic settings for automatic testing).
And this is where the problem lies. The Cargo plugin is complaining that it
cannot create a deployable because the project is of the type "pom". Exact
error:
org.codehaus.cargo.container.ContainerException: Cannot create deployable.
There's no registered deployable for the parameters (container [id =
[default]], deployable type [pom]). Valid types for this deployable are:
- ear
- rar
- ejb
- sar
- file
- war
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.0</version>
<configuration>
<wait>false</wait>
<container>
<containerId>tomcat5x</containerId>
<zipUrlInstaller>
<url>
http://172.18.0.78/containers/apache-tomcat-5.5.27.tar.gz</url>
<installDir>${project.build.directory}</installDir>
</zipUrlInstaller>
<output>${project.build.directory}/container.log</output>
<log>${project.build.directory}/cargo.log</log>
<timeout>40000</timeout>
</container>
<configuration>
<home>${project.build.directory}/container</home>
<properties>
<cargo.logging>high</cargo.logging>
<cargo.servlet.port>${env.SERVER_PORT}</cargo.servlet.port>
<cargo.rmi.port>${env.SERVER_SHUTDOWN_PORT}</cargo.rmi.port>
<cargo.jvmargs>"-DXms=128M
-DXmx=128M"</cargo.jvmargs>
</properties>
</configuration>
<deployer>
<type>installed</type>
<deployables>
<deployable>
<pingURL>http://localhost:
${env.SERVER_PORT}/${pom.build.finalName}</pingURL>
<pingTimeout>30000</pingTimeout>
</deployable>
</deployables>
</deployer>
</configuration>
</plugin>
Explicitely specifying the deployable as WAR wouldn't change a thing.
A solution I thought of was including the generic super pom in the pom which
creates the WAR, instead of the parent pom of the project.
However, the problem is that I already have a parent pom specified in the
pom which creates the WAR. And it's not possible to specify two.
I'm kind kinda out of options on this (as I am not an experienced used of
Maven), and I was hoping whether somebody could share some alternative
solutions.
TIA
Re: Cargo and multi-module projects
Posted by Bocalinda <bo...@gmail.com>.
Btw, your solution didn't work for me (activating based on a property set in
another module). It seems that the profiles are being parsed before the
property is set in my module.
2009/5/12 Bocalinda <bo...@gmail.com>
> Hi Jesse,
>
> As a workaround for the profile activation by packaging type, it may be an
> option to use:
>
> <activation>
> <property>
> <name>${project.packaging}</name>
> <value>war</value>
> </property>
> </activation>
>
> Cheers,
>
> Pieter
>
> 2009/5/11 <ji...@gmail.com>
>
>> Hi Pieter,
>>
>>
>> On Mon, May 11, 2009 at 11:47 AM, Bocalinda <bo...@gmail.com> wrote:
>> >
>> > What exactly do you mean by "attachment to a life cycle phase"?
>> > You mean like this:
>> >
>> > <executions>
>> > <execution>
>> > <id>start-container</id>
>> > <phase>pre-integration-test</phase>
>> > <goals>
>> > <goal>start</goal>
>> > <goal>deploy</goal>
>> > </goals>
>> > </execution>
>> > <execution>
>> > <id>stop-container</id>
>> > <phase>post-integration-test</phase>
>> > <goals>
>> > <goal>stop</goal>
>> > </goals>
>> > </execution>
>> > </executions>
>> >
>>
>> Yes, that's exactly right. Inside a profile in your super pom.xml.
>> -jesse
>>
>> --
>> There are 10 types of people in this world, those
>> that can read binary and those that can not.
>>
>
>
Re: Cargo and multi-module projects
Posted by Bocalinda <bo...@gmail.com>.
Hi Jesse,
As a workaround for the profile activation by packaging type, it may be an
option to use:
<activation>
<property>
<name>${project.packaging}</name>
<value>war</value>
</property>
</activation>
Cheers,
Pieter
2009/5/11 <ji...@gmail.com>
> Hi Pieter,
>
> On Mon, May 11, 2009 at 11:47 AM, Bocalinda <bo...@gmail.com> wrote:
> >
> > What exactly do you mean by "attachment to a life cycle phase"?
> > You mean like this:
> >
> > <executions>
> > <execution>
> > <id>start-container</id>
> > <phase>pre-integration-test</phase>
> > <goals>
> > <goal>start</goal>
> > <goal>deploy</goal>
> > </goals>
> > </execution>
> > <execution>
> > <id>stop-container</id>
> > <phase>post-integration-test</phase>
> > <goals>
> > <goal>stop</goal>
> > </goals>
> > </execution>
> > </executions>
> >
>
> Yes, that's exactly right. Inside a profile in your super pom.xml.
> -jesse
>
> --
> There are 10 types of people in this world, those
> that can read binary and those that can not.
>
Re: Cargo and multi-module projects
Posted by ji...@gmail.com.
Hi Pieter,
On Mon, May 11, 2009 at 11:47 AM, Bocalinda <bo...@gmail.com> wrote:
>
> What exactly do you mean by "attachment to a life cycle phase"?
> You mean like this:
>
> <executions>
> <execution>
> <id>start-container</id>
> <phase>pre-integration-test</phase>
> <goals>
> <goal>start</goal>
> <goal>deploy</goal>
> </goals>
> </execution>
> <execution>
> <id>stop-container</id>
> <phase>post-integration-test</phase>
> <goals>
> <goal>stop</goal>
> </goals>
> </execution>
> </executions>
>
Yes, that's exactly right. Inside a profile in your super pom.xml.
-jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
Re: Cargo and multi-module projects
Posted by Bocalinda <bo...@gmail.com>.
Hi Jesse,
What exactly do you mean by "attachment to a life cycle phase"?
You mean like this:
<executions>
<execution>
<id>start-container</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
<goal>deploy</goal>
</goals>
</execution>
<execution>
<id>stop-container</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
P.D. Thanks for creating the JIRA case, would definitely be useful!
Cheers,
Pieter
2009/5/11 <ji...@gmail.com>
> Hi Bocalinda,
>
> On Mon, May 11, 2009 at 11:28 AM, Bocalinda <bo...@gmail.com> wrote:
> >
> > Glad I'm not the only one who is trying such thing.
> > Great solution you just gave me, I hope this works for me as well.
> >
> > Big thanks!
>
> You picked up on it, but, just to clearly state it this time (as I
> didn't previously), the profile would contain the configuration and
> attachment to a life cycle phase, of the Cargo plugin.
>
> Also, I've gone ahead and created a new JIRA[1] for the profile
> activation by packaging type I mentioned before. I found where I
> commented inside another JIRA[2], but this is worthy of its own
> ticket.
>
> [1] http://jira.codehaus.org/browse/MNG-4154
> [2] http://jira.codehaus.org/browse/MNG-1753
>
> You're welcome, :-)
> -jesse
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Cargo and multi-module projects
Posted by ji...@gmail.com.
Hi Bocalinda,
On Mon, May 11, 2009 at 11:28 AM, Bocalinda <bo...@gmail.com> wrote:
>
> Glad I'm not the only one who is trying such thing.
> Great solution you just gave me, I hope this works for me as well.
>
> Big thanks!
You picked up on it, but, just to clearly state it this time (as I
didn't previously), the profile would contain the configuration and
attachment to a life cycle phase, of the Cargo plugin.
Also, I've gone ahead and created a new JIRA[1] for the profile
activation by packaging type I mentioned before. I found where I
commented inside another JIRA[2], but this is worthy of its own
ticket.
[1] http://jira.codehaus.org/browse/MNG-4154
[2] http://jira.codehaus.org/browse/MNG-1753
You're welcome, :-)
-jesse
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Cargo and multi-module projects
Posted by Bocalinda <bo...@gmail.com>.
Hi Jesse,
Glad I'm not the only one who is trying such thing.
Great solution you just gave me, I hope this works for me as well.
Big thanks!
2009/5/11 <ji...@gmail.com>
> Hi Bocalinda,
>
> On Mon, May 11, 2009 at 10:28 AM, Bocalinda <bo...@gmail.com> wrote:
> >
> > In order to achieve automatic testing of my projects, I use Cargo to
> > automatically deploy newly generated war files to a Tomcat server.
> > All the specifics to the automatic testing (depedencies, plugin
> > configuration, etc) are contained inside of a super pom.
>
> Yep, I find myself in the same position. I don't think the Cargo
> plugin is behaving badly here. Instead, you can create a profile in
> your super pom which will be automatically activated by a property.
> Then, in your Maven modules which are packaging=war, you can set that
> property. Ideally, Maven would support profile activation by packaging
> type (I believe I created a JIRA for this, or commented in an existing
> Profile Enhancement type JIRA) but unfortunately it can not, yet..
>
> Anyhow, the solution I propose requires the least amount of specific
> per-Maven module configuration and allows the greatest amount
> configuration reusability. I have had it working in my environment for
> about 6 months of active development for several projects..
>
> Good luck!
> -jesse
>
> --
> There are 10 types of people in this world, those
> that can read binary and those that can not.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Cargo and multi-module projects
Posted by ji...@gmail.com.
Hi Bocalinda,
On Mon, May 11, 2009 at 10:28 AM, Bocalinda <bo...@gmail.com> wrote:
>
> In order to achieve automatic testing of my projects, I use Cargo to
> automatically deploy newly generated war files to a Tomcat server.
> All the specifics to the automatic testing (depedencies, plugin
> configuration, etc) are contained inside of a super pom.
Yep, I find myself in the same position. I don't think the Cargo
plugin is behaving badly here. Instead, you can create a profile in
your super pom which will be automatically activated by a property.
Then, in your Maven modules which are packaging=war, you can set that
property. Ideally, Maven would support profile activation by packaging
type (I believe I created a JIRA for this, or commented in an existing
Profile Enhancement type JIRA) but unfortunately it can not, yet..
Anyhow, the solution I propose requires the least amount of specific
per-Maven module configuration and allows the greatest amount
configuration reusability. I have had it working in my environment for
about 6 months of active development for several projects..
Good luck!
-jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org