Cargo

Cargo 1.2 and beyond fail to create the home directory for standalone deployements

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Not A Bug
  • Affects Version/s: 1.2.0, 1.2.3
  • Fix Version/s: 1.2.4
  • Component/s: Documentation
  • Labels:
    None
  • Environment:
    Windows XP
  • Complexity:
    Intermediate
  • Tested on JDKs:
    1.6
  • Number of attachments :
    0

Description

in the pom

			<plugin>
				<groupId>org.codehaus.cargo</groupId>
				<artifactId>cargo-maven2-plugin</artifactId>
                                <version>1.2.0</version>
				<configuration>
					<container>
						<containerId>tomcat7x</containerId>
						<home>E:/appft/apache-tomcat-7.0.29</home>
					</container>
					<configuration>
						<!-- for an unknow reason, cargo do not create the directory !!! -->
						<home>target/tomcat7x</home>
						<type>standalone</type>
					</configuration>

					<deployables>
						<deployable>
							<groupId>${project.groupId}</groupId>
							<artifactId>${project.artifactId}</artifactId>
							<type>war</type>
						</deployable>
					</deployables>
				</configuration>
			</plugin>

Console output

[INFO] --- cargo-maven2-plugin:1.2.0:deploy (default-cli) @ wicket-quickstart ---
[INFO] [edDeployerDeployMojo] Resolved container artifact org.codehaus.cargo:cargo-core-container-tomcat:jar:1.2.0 for container tomcat7x
[INFO] [stalledLocalDeployer] Deploying [E:\SLGD6749\Data\Projet-TAO\00_workspace\Etude Wicket\wicket-quickstart\target\wicket-quickstart-1.0.2-SNAPSHOT.war] to [target/tomcat7x/webapps]...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.031s
[INFO] Finished at: Wed Aug 01 12:35:44 CEST 2012
[INFO] Final Memory: 9M/23M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.2.0:deploy (default-cli) on project wicket-quickstart: Execution default-cli of goal org.codehaus.cargo:cargo-maven2-plugin:1.2.0:deploy failed: Failed to deploy [E:\SLGD6749\Data\Projet-TAO\00_workspace\Etude Wicket\wicket-quickstart\target\wicket-quickstart-1.0.2-SNAPSHOT.war] to [target/tomcat7x/webapps]: Target deployable directory does not exist: target/tomcat7x/webapps -> [Help 1]

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Savas Ali Tokmen added a comment -

Hi Zart

In order to configure a container (including the deployables), you should use cargo:configure and not cargo:deploy

Thank you

Show
Savas Ali Tokmen added a comment - Hi Zart In order to configure a container (including the deployables), you should use cargo:configure and not cargo:deploy Thank you
Hide
Permalink
Savas Ali Tokmen added a comment -

Committed revision 3374, so that other users who would try the same now easier understand which part of the documentation should be read in order to make deployers work properly.

Show
Savas Ali Tokmen added a comment - Committed revision 3374, so that other users who would try the same now easier understand which part of the documentation should be read in order to make deployers work properly.
Hide
Permalink
Tuomas Kiviaho added a comment - - edited

The revision 3375 caused a regression for my container/deployer that doesn't have a notion of home directory. At least until 1.2.2 the home could be left undeclared. More of an issue is that now I get an NPE instead of the error from DefaultFileHandler.isDirectory() when there is no declaration for home. And with home declared, I seem to be getting 'The configuration home parameter should not be specified for runtime configurations'

I suggest that this error message would be shown only when home is not null.

Show
Tuomas Kiviaho added a comment - - edited The revision 3375 caused a regression for my container/deployer that doesn't have a notion of home directory. At least until 1.2.2 the home could be left undeclared. More of an issue is that now I get an NPE instead of the error from DefaultFileHandler.isDirectory() when there is no declaration for home. And with home declared, I seem to be getting 'The configuration home parameter should not be specified for runtime configurations' I suggest that this error message would be shown only when home is not null.
Hide
Permalink
Savas Ali Tokmen added a comment -

Hi Tuomas

Can you please give us:

  1. An explanation of what you're trying to achieve
  2. Your pom.xml file
  3. The command you're running
  4. The output of the command when run with the mvn -e option
  5. What you're expecting this command to do

I've fixed the NPE, but I don't understand why the AbstractLocalDeployer is used when you're attempting to use a remote configuration.

Thank you

Show
Savas Ali Tokmen added a comment - Hi Tuomas Can you please give us: An explanation of what you're trying to achieve Your pom.xml file The command you're running The output of the command when run with the mvn -e option What you're expecting this command to do I've fixed the NPE, but I don't understand why the AbstractLocalDeployer is used when you're attempting to use a remote configuration. Thank you
Hide
Permalink
Tuomas Kiviaho added a comment -

Hello Ali,

Thanks for the quick fix.

It seems that I should be using STANDALONE configuration type instead of RUNTIME for an embedded container. I had even copy/pasted the <type>runtime</type> without so much giving a though about it as shown in this example <http://github.com/TuomasKiviaho/org.codehaus.cargo.container.osgi/blob/cb4f4530b963687ebc83794d7d59b2b7fa2ba7d5/README.md> of how to setup OSGi framework using cargo (followed by section of how to get failsafe to execute attached tests from within of the container).

Due to this I was able to derive an AbstractLocalConfiguration with no-param. constructor by just passing a null home argument to the super so I must have though this approach to be fantastic once upon the time. I changed the confs and the configuration type as it is supposed to be for local containers but now I seem to be required to deliver an one-param. constructor so that home can be forced to FileHandler#getTmpPath("conf") by DefaultConfigurationFactory whichapplies other than maven environments. There the non-existing home is beforehand forced to ${project.build.directory}/cargo/configurations/\${containerId} by Configuration class for both STANDALONE and EXISTING types.

Nevertheless all this will cause new CARGO-1131 message to appear because the artificial home (no matter how it's actually generated) doesn't exist. I can now workaround the issue by providing an one-param. constructor and just neglect the home.

hack
public OsgiLocalConfiguration(String home)
{
  super(null);
}

This trick will do it fine for me at least for the time being.

Show
Tuomas Kiviaho added a comment - Hello Ali, Thanks for the quick fix. It seems that I should be using STANDALONE configuration type instead of RUNTIME for an embedded container. I had even copy/pasted the <type>runtime</type> without so much giving a though about it as shown in this example < http://github.com/TuomasKiviaho/org.codehaus.cargo.container.osgi/blob/cb4f4530b963687ebc83794d7d59b2b7fa2ba7d5/README.md > of how to setup OSGi framework using cargo (followed by section of how to get failsafe to execute attached tests from within of the container). Due to this I was able to derive an AbstractLocalConfiguration with no-param. constructor by just passing a null home argument to the super so I must have though this approach to be fantastic once upon the time. I changed the confs and the configuration type as it is supposed to be for local containers but now I seem to be required to deliver an one-param. constructor so that home can be forced to FileHandler#getTmpPath("conf") by DefaultConfigurationFactory whichapplies other than maven environments. There the non-existing home is beforehand forced to ${project.build.directory}/cargo/configurations/\${containerId } by Configuration class for both STANDALONE and EXISTING types. Nevertheless all this will cause new CARGO-1131 message to appear because the artificial home (no matter how it's actually generated) doesn't exist. I can now workaround the issue by providing an one-param. constructor and just neglect the home. hack public OsgiLocalConfiguration( String home) { super ( null ); } This trick will do it fine for me at least for the time being.
Hide
Permalink
Savas Ali Tokmen added a comment -

Hi Tuomas

OK, I get it now This "hack" should then solve your issue; sorry about the hassle caused...

Thank you

Show
Savas Ali Tokmen added a comment - Hi Tuomas OK, I get it now This "hack" should then solve your issue; sorry about the hassle caused... Thank you

People

  • Assignee:
    Unassigned
    Reporter:
    zart colwing
Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: