Configuration difficulties

View: New views
7 Messages — Rating Filter:   Alert me  

Configuration difficulties

by Brian Cribbs :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Matt asked me to mail the group to explain my project's configuration and what I'm having difficulties with.

I'm working on a Maven enabled project with (currently) 7 modules that's bound to increase in number with upcoming project additions.  5 of the 7 modules produce wars, the other 2 produce jars that are consumed by one or more of the other modules.

I was trying to set up cargo in the parent pom to be profile enabled to do the following through bound executions:  shutdown JBoss, compile the modules, undeploy any modules that are currently deployed, deploy and start up JBoss.  The Container's home is based on profile set properties.
There were a few problems with this:
1.  The home element in the container configuration points to the root directory of the JBoss install.  This allowed the executables in JBOSS_HOME\bin to run correctly but deployed the deployables to JBOSS_HOME\deploy. 
2. The cargo commands were executed on a per-module basis instead of a project basis causing it to try to shut down, undeploy, and redploy 7 times leaving only the last module in the modules list deployed on a running JBoss instance.  I think this is a Maven limitation and not a Cargo limitation

After speaking with Matt, I was told the deploy directory wasn't configurable.

I believe the container's deploy directory should be configurable in the POM and it'd be nice if Cargo could somehow be aware that it should be bound at the parent pom's level instead of the child pom's level.

My current workaround is to manually shut down jboss and execute a batch file that does the following and seems to work well:
call mvn clean install -P%1
call mvn cargo:undeploy cargo:start

Re: Configuration difficulties

by Matt Wringe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Thu, 2008-12-18 at 13:30 -0500, Brian Cribbs wrote:

> Matt asked me to mail the group to explain my project's configuration
> and what I'm having difficulties with.
>
> I'm working on a Maven enabled project with (currently) 7 modules
> that's bound to increase in number with upcoming project additions.  5
> of the 7 modules produce wars, the other 2 produce jars that are
> consumed by one or more of the other modules.
>
> I was trying to set up cargo in the parent pom to be profile enabled
> to do the following through bound executions:  shutdown JBoss, compile
> the modules, undeploy any modules that are currently deployed, deploy
> and start up JBoss.  The Container's home is based on profile set
> properties.
> There were a few problems with this:
> 1.  The home element in the container configuration points to the root
> directory of the JBoss install.  This allowed the executables in
> JBOSS_HOME\bin to run correctly but deployed the deployables to
> JBOSS_HOME\deploy.
this is wrong, are you using JBoss 4.2.x but using the jboss4x option in
Cargo? If so you will either need to set which JBoss Configuration you
want to use (set property cargo.jboss.configuration) or switch to the
jboss42x option.

> 2. The cargo commands were executed on a per-module basis instead of a
> project basis causing it to try to shut down, undeploy, and redploy 7
> times leaving only the last module in the modules list deployed on a
> running JBoss instance.  I think this is a Maven limitation and not a
> Cargo limitation

Ok, what exactly do you want the build to do?
Do you want it to deploy 7 wars to a server (or different servers) and
have the server running at the end? Do you want to be starting a server,
deploying a war, run tests and then stop the server?



>
> After speaking with Matt, I was told the deploy directory wasn't
> configurable.
right, you can't specify an arbitrary location for the directory to
contain wars.

>
> I believe the container's deploy directory should be configurable in
> the POM and it'd be nice if Cargo could somehow be aware that it
> should be bound at the parent pom's level instead of the child pom's
> level.
why do you want to specify the deploy directory? Cargo should already
know where to put things, if they are being put in another location then
its a bug (note for things like installed jboss containers, you can
specify which of the servers to use (ie minimal, default, all)).

> My current workaround is to manually shut down jboss and execute a
> batch file that does the following and seems to work well:
> call mvn clean install -P%1
> call mvn cargo:undeploy cargo:start
you shouldn't need to do this.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Re: Configuration difficulties

by Brian Cribbs :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



On Thu, Dec 18, 2008 at 1:56 PM, Matt Wringe <mwringe@...> wrote:

On Thu, 2008-12-18 at 13:30 -0500, Brian Cribbs wrote:
> Matt asked me to mail the group to explain my project's configuration
> and what I'm having difficulties with.
>
> I'm working on a Maven enabled project with (currently) 7 modules
> that's bound to increase in number with upcoming project additions.  5
> of the 7 modules produce wars, the other 2 produce jars that are
> consumed by one or more of the other modules.
>
> I was trying to set up cargo in the parent pom to be profile enabled
> to do the following through bound executions:  shutdown JBoss, compile
> the modules, undeploy any modules that are currently deployed, deploy
> and start up JBoss.  The Container's home is based on profile set
> properties.
> There were a few problems with this:
> 1.  The home element in the container configuration points to the root
> directory of the JBoss install.  This allowed the executables in
> JBOSS_HOME\bin to run correctly but deployed the deployables to
> JBOSS_HOME\deploy.
this is wrong, are you using JBoss 4.2.x but using the jboss4x option in
Cargo? If so you will either need to set which JBoss Configuration you
want to use (set property cargo.jboss.configuration) or switch to the
jboss42x option.

I'm using the jboss42x option


> 2. The cargo commands were executed on a per-module basis instead of a
> project basis causing it to try to shut down, undeploy, and redploy 7
> times leaving only the last module in the modules list deployed on a
> running JBoss instance.  I think this is a Maven limitation and not a
> Cargo limitation

Ok, what exactly do you want the build to do?
Do you want it to deploy 7 wars to a server (or different servers) and
have the server running at the end? Do you want to be starting a server,
deploying a war, run tests and then stop the server?
I want the build to stop the JBoss server, remove the existing files(if any), deploy the 5 wars to the server, then start JBoss.  This is purely for deployment use.



>
> After speaking with Matt, I was told the deploy directory wasn't
> configurable.
right, you can't specify an arbitrary location for the directory to
contain wars.

>
> I believe the container's deploy directory should be configurable in
> the POM and it'd be nice if Cargo could somehow be aware that it
> should be bound at the parent pom's level instead of the child pom's
> level.
why do you want to specify the deploy directory? Cargo should already
know where to put things, if they are being put in another location then
its a bug (note for things like installed jboss containers, you can
specify which of the servers to use (ie minimal, default, all)).

I wasn't aware that this existed.  Where is this information configured?


> My current workaround is to manually shut down jboss and execute a
> batch file that does the following and seems to work well:
> call mvn clean install -P%1
> call mvn cargo:undeploy cargo:start
you shouldn't need to do this.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




Re: Configuration difficulties

by Matt Wringe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Thu, 2008-12-18 at 14:01 -0500, Brian Cribbs wrote:

>
>
> On Thu, Dec 18, 2008 at 1:56 PM, Matt Wringe <mwringe@...>
> wrote:
>        
>         On Thu, 2008-12-18 at 13:30 -0500, Brian Cribbs wrote:
>         > Matt asked me to mail the group to explain my project's
>         configuration
>         > and what I'm having difficulties with.
>         >
>         > I'm working on a Maven enabled project with (currently) 7
>         modules
>         > that's bound to increase in number with upcoming project
>         additions.  5
>         > of the 7 modules produce wars, the other 2 produce jars that
>         are
>         > consumed by one or more of the other modules.
>         >
>         > I was trying to set up cargo in the parent pom to be profile
>         enabled
>         > to do the following through bound executions:  shutdown
>         JBoss, compile
>         > the modules, undeploy any modules that are currently
>         deployed, deploy
>         > and start up JBoss.  The Container's home is based on
>         profile set
>         > properties.
>         > There were a few problems with this:
>         > 1.  The home element in the container configuration points
>         to the root
>         > directory of the JBoss install.  This allowed the
>         executables in
>         > JBOSS_HOME\bin to run correctly but deployed the deployables
>         to
>         > JBOSS_HOME\deploy.
>        
>         this is wrong, are you using JBoss 4.2.x but using the jboss4x
>         option in
>         Cargo? If so you will either need to set which JBoss
>         Configuration you
>         want to use (set property cargo.jboss.configuration) or switch
>         to the
>         jboss42x option.
>
> I'm using the jboss42x option
hmm, ok this is a bug then :(
What type of deployer are you using? standalone, installed, remote?

>
>        
>        
>         > 2. The cargo commands were executed on a per-module basis
>         instead of a
>         > project basis causing it to try to shut down, undeploy, and
>         redploy 7
>         > times leaving only the last module in the modules list
>         deployed on a
>         > running JBoss instance.  I think this is a Maven limitation
>         and not a
>         > Cargo limitation
>        
>        
>         Ok, what exactly do you want the build to do?
>         Do you want it to deploy 7 wars to a server (or different
>         servers) and
>         have the server running at the end? Do you want to be starting
>         a server,
>         deploying a war, run tests and then stop the server?
>        
> I want the build to stop the JBoss server, remove the existing
> files(if any), deploy the 5 wars to the server, then start JBoss.
> This is purely for deployment use.

ok, then it would make sense to just specify this in the parent pom (I
am not entirely sure how to make maven build the submodules before
running the cargo plugin. If that doesn't work then you could create
another submodule whose only function is to handle cargo and the
server).

>        
>        
>        
>         >
>         > After speaking with Matt, I was told the deploy directory
>         wasn't
>         > configurable.
>        
>         right, you can't specify an arbitrary location for the
>         directory to
>         contain wars.
>        
>         >
>         > I believe the container's deploy directory should be
>         configurable in
>         > the POM and it'd be nice if Cargo could somehow be aware
>         that it
>         > should be bound at the parent pom's level instead of the
>         child pom's
>         > level.
>        
>         why do you want to specify the deploy directory? Cargo should
>         already
>         know where to put things, if they are being put in another
>         location then
>         its a bug (note for things like installed jboss containers,
>         you can
>         specify which of the servers to use (ie minimal, default,
>         all)).
>
> I wasn't aware that this existed.  Where is this information
> configured?

set the property cargo.jboss.configuration to the server configuration
you want to use.

http://cargo.codehaus.org/JBoss+4.2.x

>
>        
>        
>         > My current workaround is to manually shut down jboss and
>         execute a
>         > batch file that does the following and seems to work well:
>         > call mvn clean install -P%1
>         > call mvn cargo:undeploy cargo:start
>        
>         you shouldn't need to do this.
>        
>        
>         ---------------------------------------------------------------------
>         To unsubscribe from this list, please visit:
>        
>            http://xircles.codehaus.org/manage_email
>        
>        
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Re: Configuration difficulties

by Brian Cribbs :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



On Thu, Dec 18, 2008 at 2:28 PM, Matt Wringe <mwringe@...> wrote:

On Thu, 2008-12-18 at 14:01 -0500, Brian Cribbs wrote:
>
>
> On Thu, Dec 18, 2008 at 1:56 PM, Matt Wringe <mwringe@...>
> wrote:
>
>         On Thu, 2008-12-18 at 13:30 -0500, Brian Cribbs wrote:
>         > Matt asked me to mail the group to explain my project's
>         configuration
>         > and what I'm having difficulties with.
>         >
>         > I'm working on a Maven enabled project with (currently) 7
>         modules
>         > that's bound to increase in number with upcoming project
>         additions.  5
>         > of the 7 modules produce wars, the other 2 produce jars that
>         are
>         > consumed by one or more of the other modules.
>         >
>         > I was trying to set up cargo in the parent pom to be profile
>         enabled
>         > to do the following through bound executions:  shutdown
>         JBoss, compile
>         > the modules, undeploy any modules that are currently
>         deployed, deploy
>         > and start up JBoss.  The Container's home is based on
>         profile set
>         > properties.
>         > There were a few problems with this:
>         > 1.  The home element in the container configuration points
>         to the root
>         > directory of the JBoss install.  This allowed the
>         executables in
>         > JBOSS_HOME\bin to run correctly but deployed the deployables
>         to
>         > JBOSS_HOME\deploy.
>
>         this is wrong, are you using JBoss 4.2.x but using the jboss4x
>         option in
>         Cargo? If so you will either need to set which JBoss
>         Configuration you
>         want to use (set property cargo.jboss.configuration) or switch
>         to the
>         jboss42x option.
>
> I'm using the jboss42x option
hmm, ok this is a bug then :(
What type of deployer are you using? standalone, installed, remote?

>
>
>
>         > 2. The cargo commands were executed on a per-module basis
>         instead of a
>         > project basis causing it to try to shut down, undeploy, and
>         redploy 7
>         > times leaving only the last module in the modules list
>         deployed on a
>         > running JBoss instance.  I think this is a Maven limitation
>         and not a
>         > Cargo limitation
>
>
>         Ok, what exactly do you want the build to do?
>         Do you want it to deploy 7 wars to a server (or different
>         servers) and
>         have the server running at the end? Do you want to be starting
>         a server,
>         deploying a war, run tests and then stop the server?
>
> I want the build to stop the JBoss server, remove the existing
> files(if any), deploy the 5 wars to the server, then start JBoss.
> This is purely for deployment use.

ok, then it would make sense to just specify this in the parent pom (I
am not entirely sure how to make maven build the submodules before
running the cargo plugin. If that doesn't work then you could create
another submodule whose only function is to handle cargo and the
server).

>
>
>
>         >
>         > After speaking with Matt, I was told the deploy directory
>         wasn't
>         > configurable.
>
>         right, you can't specify an arbitrary location for the
>         directory to
>         contain wars.
>
>         >
>         > I believe the container's deploy directory should be
>         configurable in
>         > the POM and it'd be nice if Cargo could somehow be aware
>         that it
>         > should be bound at the parent pom's level instead of the
>         child pom's
>         > level.
>
>         why do you want to specify the deploy directory? Cargo should
>         already
>         know where to put things, if they are being put in another
>         location then
>         its a bug (note for things like installed jboss containers,
>         you can
>         specify which of the servers to use (ie minimal, default,
>         all)).
>
> I wasn't aware that this existed.  Where is this information
> configured?

set the property cargo.jboss.configuration to the server configuration
you want to use.

http://cargo.codehaus.org/JBoss+4.2.x

It defaults to default (what a novel idea) but it doesn't deploy to JBOSS_HOME/server/default/deploy like it should.  It deploys to JBOSS_HOME/deploy


>
>
>
>         > My current workaround is to manually shut down jboss and
>         execute a
>         > batch file that does the following and seems to work well:
>         > call mvn clean install -P%1
>         > call mvn cargo:undeploy cargo:start
>
>         you shouldn't need to do this.
>
>
>         ---------------------------------------------------------------------
>         To unsubscribe from this list, please visit:
>
>            http://xircles.codehaus.org/manage_email
>
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




Re: Configuration difficulties

by Matt Wringe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Thu, 2008-12-18 at 14:36 -0500, Brian Cribbs wrote:

>
>
> On Thu, Dec 18, 2008 at 2:28 PM, Matt Wringe <mwringe@...>
> wrote:
>        
>        
>         On Thu, 2008-12-18 at 14:01 -0500, Brian Cribbs wrote:
>         >
>         >
>         > On Thu, Dec 18, 2008 at 1:56 PM, Matt Wringe
>         <mwringe@...>
>         > wrote:
>         >
>         >         On Thu, 2008-12-18 at 13:30 -0500, Brian Cribbs
>         wrote:
>         >         > Matt asked me to mail the group to explain my
>         project's
>         >         configuration
>         >         > and what I'm having difficulties with.
>         >         >
>         >         > I'm working on a Maven enabled project with
>         (currently) 7
>         >         modules
>         >         > that's bound to increase in number with upcoming
>         project
>         >         additions.  5
>         >         > of the 7 modules produce wars, the other 2 produce
>         jars that
>         >         are
>         >         > consumed by one or more of the other modules.
>         >         >
>         >         > I was trying to set up cargo in the parent pom to
>         be profile
>         >         enabled
>         >         > to do the following through bound executions:
>          shutdown
>         >         JBoss, compile
>         >         > the modules, undeploy any modules that are
>         currently
>         >         deployed, deploy
>         >         > and start up JBoss.  The Container's home is based
>         on
>         >         profile set
>         >         > properties.
>         >         > There were a few problems with this:
>         >         > 1.  The home element in the container
>         configuration points
>         >         to the root
>         >         > directory of the JBoss install.  This allowed the
>         >         executables in
>         >         > JBOSS_HOME\bin to run correctly but deployed the
>         deployables
>         >         to
>         >         > JBOSS_HOME\deploy.
>         >
>         >         this is wrong, are you using JBoss 4.2.x but using
>         the jboss4x
>         >         option in
>         >         Cargo? If so you will either need to set which JBoss
>         >         Configuration you
>         >         want to use (set property cargo.jboss.configuration)
>         or switch
>         >         to the
>         >         jboss42x option.
>         >
>         > I'm using the jboss42x option
>        
>         hmm, ok this is a bug then :(
>         What type of deployer are you using? standalone, installed,
>         remote?
>        
>         >
>         >
>         >
>         >         > 2. The cargo commands were executed on a
>         per-module basis
>         >         instead of a
>         >         > project basis causing it to try to shut down,
>         undeploy, and
>         >         redploy 7
>         >         > times leaving only the last module in the modules
>         list
>         >         deployed on a
>         >         > running JBoss instance.  I think this is a Maven
>         limitation
>         >         and not a
>         >         > Cargo limitation
>         >
>         >
>         >         Ok, what exactly do you want the build to do?
>         >         Do you want it to deploy 7 wars to a server (or
>         different
>         >         servers) and
>         >         have the server running at the end? Do you want to
>         be starting
>         >         a server,
>         >         deploying a war, run tests and then stop the server?
>         >
>         > I want the build to stop the JBoss server, remove the
>         existing
>         > files(if any), deploy the 5 wars to the server, then start
>         JBoss.
>         > This is purely for deployment use.
>        
>        
>         ok, then it would make sense to just specify this in the
>         parent pom (I
>         am not entirely sure how to make maven build the submodules
>         before
>         running the cargo plugin. If that doesn't work then you could
>         create
>         another submodule whose only function is to handle cargo and
>         the
>         server).
>        
>         >
>         >
>         >
>         >         >
>         >         > After speaking with Matt, I was told the deploy
>         directory
>         >         wasn't
>         >         > configurable.
>         >
>         >         right, you can't specify an arbitrary location for
>         the
>         >         directory to
>         >         contain wars.
>         >
>         >         >
>         >         > I believe the container's deploy directory should
>         be
>         >         configurable in
>         >         > the POM and it'd be nice if Cargo could somehow be
>         aware
>         >         that it
>         >         > should be bound at the parent pom's level instead
>         of the
>         >         child pom's
>         >         > level.
>         >
>         >         why do you want to specify the deploy directory?
>         Cargo should
>         >         already
>         >         know where to put things, if they are being put in
>         another
>         >         location then
>         >         its a bug (note for things like installed jboss
>         containers,
>         >         you can
>         >         specify which of the servers to use (ie minimal,
>         default,
>         >         all)).
>         >
>         > I wasn't aware that this existed.  Where is this information
>         > configured?
>        
>        
>         set the property cargo.jboss.configuration to the server
>         configuration
>         you want to use.
>        
>         http://cargo.codehaus.org/JBoss+4.2.x
>
> It defaults to default (what a novel idea) but it doesn't deploy to
> JBOSS_HOME/server/default/deploy like it should.  It deploys to
> JBOSS_HOME/deploy

are you sure you are using an installed container?
can you attach part of your pom that sets up cargo?

>        
>        
>        
>         >
>         >
>         >
>         >         > My current workaround is to manually shut down
>         jboss and
>         >         execute a
>         >         > batch file that does the following and seems to
>         work well:
>         >         > call mvn clean install -P%1
>         >         > call mvn cargo:undeploy cargo:start
>         >
>         >         you shouldn't need to do this.
>         >
>         >
>         >
>         ---------------------------------------------------------------------
>         >         To unsubscribe from this list, please visit:
>         >
>         >            http://xircles.codehaus.org/manage_email
>         >
>         >
>         >
>        
>        
>         ---------------------------------------------------------------------
>         To unsubscribe from this list, please visit:
>        
>            http://xircles.codehaus.org/manage_email
>        
>        
>        
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Re: Configuration difficulties

by Brian Cribbs :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

<plugin>
                <groupId>org.codehaus.cargo</groupId>
                <artifactId>cargo-maven2-plugin</artifactId>
                <configuration>
                    <container>
                        <containerId>jboss42x</containerId>
                        <home>${jbossDir}\server\default</home>
                       
                    </container>
                    <configuration>
                        <type>existing</type>
                        <home>${jbossDir}\server\default</home>
                        <properties>
                           
                        </properties>
                    </configuration>
                    <deployer>
                        <type>installed</type>
                        <deployables>
                            <deployable>
                                <groupId>${pom.groupId}</groupId>
                                <artifactId>web-services</artifactId>
                                <location>web-services/target/services.war</location>
                                <type>war</type>
                                <properties>
                                </properties>
                              </deployable>
                              <deployable>
                                <groupId>${pom.groupId}</groupId>
                                <artifactId>css</artifactId>
                                <location>css/target/css.war</location>
                                <type>war</type>
                                <properties>
                                </properties>
                              </deployable>
                              <deployable>
                                <groupId>${pom.groupId}</groupId>
                                <artifactId>admin-web</artifactId>
                                <location>admin-web/target/hermes.war</location>
                                <type>war</type>
                                <properties>
                                </properties>
                              </deployable>
                              <deployable>
                                <groupId>${pom.groupId}</groupId>
                                <artifactId>customer-admin-web</artifactId>
                                <location>customer-admin-web/target/customer.war</location>
                                <type>war</type>
                                <properties>
                                </properties>
                              </deployable>
                              <deployable>
                                <groupId>${pom.groupId}</groupId>
                                <artifactId>supplier-admin-web</artifactId>
                                <location>supplier-admin-web/target/suppliers.war</location>
                                <type>war</type>
                                <properties>
                                </properties>
                              </deployable>
                        </deployables>
                    </deployer>
                </configuration>
            </plugin>

<profile>
           <id>development</id>
           <activation><activeByDefault>true</activeByDefault></activation>
           <properties>
               <jbossDir>c:\jboss-4.2.3.GA</jbossDir>
           </properties>
       </profile>
       <profile>
           <id>uat</id>
           <activation><activeByDefault>false</activeByDefault></activation>
           <properties>
               <jbossDir>c:\opt\jboss-4.2.3.GA</jbossDir>
           </properties>
       </profile>
       <profile>
           <id>qa</id>
           <activation><activeByDefault>false</activeByDefault></activation>
           <properties>
               <jbossDir>c:\opt\jboss-4.2.3.GA</jbossDir>
           </properties>
       </profile>

On Thu, Dec 18, 2008 at 3:33 PM, Matt Wringe <mwringe@...> wrote:

On Thu, 2008-12-18 at 14:36 -0500, Brian Cribbs wrote:
>
>
> On Thu, Dec 18, 2008 at 2:28 PM, Matt Wringe <mwringe@...>
> wrote:
>
>
>         On Thu, 2008-12-18 at 14:01 -0500, Brian Cribbs wrote:
>         >
>         >
>         > On Thu, Dec 18, 2008 at 1:56 PM, Matt Wringe
>         <mwringe@...>
>         > wrote:
>         >
>         >         On Thu, 2008-12-18 at 13:30 -0500, Brian Cribbs
>         wrote:
>         >         > Matt asked me to mail the group to explain my
>         project's
>         >         configuration
>         >         > and what I'm having difficulties with.
>         >         >
>         >         > I'm working on a Maven enabled project with
>         (currently) 7
>         >         modules
>         >         > that's bound to increase in number with upcoming
>         project
>         >         additions.  5
>         >         > of the 7 modules produce wars, the other 2 produce
>         jars that
>         >         are
>         >         > consumed by one or more of the other modules.
>         >         >
>         >         > I was trying to set up cargo in the parent pom to
>         be profile
>         >         enabled
>         >         > to do the following through bound executions:
>          shutdown
>         >         JBoss, compile
>         >         > the modules, undeploy any modules that are
>         currently
>         >         deployed, deploy
>         >         > and start up JBoss.  The Container's home is based
>         on
>         >         profile set
>         >         > properties.
>         >         > There were a few problems with this:
>         >         > 1.  The home element in the container
>         configuration points
>         >         to the root
>         >         > directory of the JBoss install.  This allowed the
>         >         executables in
>         >         > JBOSS_HOME\bin to run correctly but deployed the
>         deployables
>         >         to
>         >         > JBOSS_HOME\deploy.
>         >
>         >         this is wrong, are you using JBoss 4.2.x but using
>         the jboss4x
>         >         option in
>         >         Cargo? If so you will either need to set which JBoss
>         >         Configuration you
>         >         want to use (set property cargo.jboss.configuration)
>         or switch
>         >         to the
>         >         jboss42x option.
>         >
>         > I'm using the jboss42x option
>
>         hmm, ok this is a bug then :(
>         What type of deployer are you using? standalone, installed,
>         remote?
>
>         >
>         >
>         >
>         >         > 2. The cargo commands were executed on a
>         per-module basis
>         >         instead of a
>         >         > project basis causing it to try to shut down,
>         undeploy, and
>         >         redploy 7
>         >         > times leaving only the last module in the modules
>         list
>         >         deployed on a
>         >         > running JBoss instance.  I think this is a Maven
>         limitation
>         >         and not a
>         >         > Cargo limitation
>         >
>         >
>         >         Ok, what exactly do you want the build to do?
>         >         Do you want it to deploy 7 wars to a server (or
>         different
>         >         servers) and
>         >         have the server running at the end? Do you want to
>         be starting
>         >         a server,
>         >         deploying a war, run tests and then stop the server?
>         >
>         > I want the build to stop the JBoss server, remove the
>         existing
>         > files(if any), deploy the 5 wars to the server, then start
>         JBoss.
>         > This is purely for deployment use.
>
>
>         ok, then it would make sense to just specify this in the
>         parent pom (I
>         am not entirely sure how to make maven build the submodules
>         before
>         running the cargo plugin. If that doesn't work then you could
>         create
>         another submodule whose only function is to handle cargo and
>         the
>         server).
>
>         >
>         >
>         >
>         >         >
>         >         > After speaking with Matt, I was told the deploy
>         directory
>         >         wasn't
>         >         > configurable.
>         >
>         >         right, you can't specify an arbitrary location for
>         the
>         >         directory to
>         >         contain wars.
>         >
>         >         >
>         >         > I believe the container's deploy directory should
>         be
>         >         configurable in
>         >         > the POM and it'd be nice if Cargo could somehow be
>         aware
>         >         that it
>         >         > should be bound at the parent pom's level instead
>         of the
>         >         child pom's
>         >         > level.
>         >
>         >         why do you want to specify the deploy directory?
>         Cargo should
>         >         already
>         >         know where to put things, if they are being put in
>         another
>         >         location then
>         >         its a bug (note for things like installed jboss
>         containers,
>         >         you can
>         >         specify which of the servers to use (ie minimal,
>         default,
>         >         all)).
>         >
>         > I wasn't aware that this existed.  Where is this information
>         > configured?
>
>
>         set the property cargo.jboss.configuration to the server
>         configuration
>         you want to use.
>
>         http://cargo.codehaus.org/JBoss+4.2.x
>
> It defaults to default (what a novel idea) but it doesn't deploy to
> JBOSS_HOME/server/default/deploy like it should.  It deploys to
> JBOSS_HOME/deploy

are you sure you are using an installed container?
can you attach part of your pom that sets up cargo?

>
>
>
>         >
>         >
>         >
>         >         > My current workaround is to manually shut down
>         jboss and
>         >         execute a
>         >         > batch file that does the following and seems to
>         work well:
>         >         > call mvn clean install -P%1
>         >         > call mvn cargo:undeploy cargo:start
>         >
>         >         you shouldn't need to do this.
>         >
>         >
>         >
>         ---------------------------------------------------------------------
>         >         To unsubscribe from this list, please visit:
>         >
>         >            http://xircles.codehaus.org/manage_email
>         >
>         >
>         >
>
>
>         ---------------------------------------------------------------------
>         To unsubscribe from this list, please visit:
>
>            http://xircles.codehaus.org/manage_email
>
>
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email