Nabble - Cargo

question on specific server's config

2009-11-24T02:58:25Z

Hi,

I'm currently using cargo-maven2-plugin 1.0 with tomcat6 in mode Standalone Local.
If I'm right, the server's configuration used is from "/org/codehaus/cargo/container/internal/resources/" (method setupConfFiles from class AbstractCatalinaStandaloneLocalConfiguration).

However, I would like to use a custom tomcat config : I deploy a custom tomcat zip file because I need to share a custom context and I need to share properties files for my webapps (I know this is not recommended but I would like to make my webapps configurable from "outside"). So I customized the catalina.properties and the context.xml.

Is it possible to ask you the plugin to keep my files during the copy phase or to indicate this kind of information (I need the shared.loader from tomcat)? And if not may I suggest to add this functionality?

To do that I had to modify the method setupManager() from the class Tomcat6xStandaloneLocalConfiguration :
getFileHandler().copyFile(from + "/conf/catalina.properties", to + "/conf/catalina.properties", true);
getFileHandler().copyFile(from + "/conf/context.xml", to + "/conf/context.xml", true);

What do you think about? (I know that what I have done is not a solution but it's just to keep running)

Hope my question is clear enough.

Best Regards,

Khanh

From forum: Cargo - User

[jira] Commented: (CARGO-736) Unable to check out code.

2009-11-23T22:25:55Z

[ http://jira.codehaus.org/browse/CARGO-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199177#action_199177 ]

Bharath Srinivasan commented on CARGO-736:
------------------------------------------

Hi Matt,

Thanks for checking this. But we are still unable to check out code. Ping responds, browsing the repository works - normal or fish eye but checkout isn't happening. We are behind a firewall and I edited the SVN server configuration for proxy settings and still no progress. Also we tried from a machine that doesn't have any firewall and the result is same.

>svn co http://svn.codehaus.org/cargo/trunks
svn: OPTIONS of 'http://svn.codehaus.org/cargo/trunks': could not connect to server (http://svn.codehaus.org)

I appreciate any help on this regard.

Thanks,
Bharath

> Unable to check out code.
> -------------------------
>
> Key: CARGO-736
> URL: http://jira.codehaus.org/browse/CARGO-736
> Project: Cargo
> Issue Type: Bug
> Components: Build
> Environment: Windows XP SP2
> Reporter: Bharath Srinivasan
>
> Hello:
> I am unable to checkout code from SVN using the below command as suggested in http://cargo.codehaus.org/SVN
> >svn co http://svn.codehaus.org/cargo/trunks
> svn: OPTIONS of 'http://svn.codehaus.org/cargo/trunks': could not connect to server (http://svn.codehaus.org)
> Can you please help us move forward.
> Thanks,
> Bharath

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

http://xircles.codehaus.org/manage_email

From forum: Cargo - Dev

[jira] Closed: (CARGO-413) DeployableMonitor required to be used in a separate thread

2009-11-23T00:27:55Z

[ http://jira.codehaus.org/browse/CARGO-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrian Cole closed CARGO-413.
-----------------------------

Resolution: Fixed
Fix Version/s: 1.0.1

thanks for the patch, James. please re-open this case, if the remedy proves insufficient.

> DeployableMonitor required to be used in a separate thread
> ----------------------------------------------------------
>
> Key: CARGO-413
> URL: http://jira.codehaus.org/browse/CARGO-413
> Project: Cargo
> Issue Type: Improvement
> Components: Tomcat
> Affects Versions: 0.9
> Reporter: Juri Artamonov
> Assignee: Adrian Cole
> Fix For: 1.0.1
>
> Attachments: patch1.txt, patch2.txt, read-timeout.patch
>
>
> Sometimes deployment of the application hangs up and cargo couldn't get any answer from the tomcat manager. Currently there is timeout feature implemented in DeployableMonitor but monitor starts only after deployment is performed instead of starting in the same with deployment. For this DeployableMonitor required to be used in a separate thread and after timeout cargo can say that deployment is failed not waiting response from tomcat manager

From forum: Cargo - Dev

[cargo] r1992 - in core/trunk/api/container/src/main/java/org/codehaus/cargo/container: deployer internal/util

2009-11-23T00:26:02Z

Author: adriancole
Date: 2009-11-23 02:26:01 -0600 (Mon, 23 Nov 2009)
New Revision: 1992

Modified:
core/trunk/api/container/src/main/java/org/codehaus/cargo/container/deployer/URLDeployableMonitor.java
core/trunk/api/container/src/main/java/org/codehaus/cargo/container/internal/util/HttpUtils.java
Log:
CARGO-413: resolve tomcat shutdown issue by adding read and connect timeout

Modified: core/trunk/api/container/src/main/java/org/codehaus/cargo/container/deployer/URLDeployableMonitor.java
===================================================================
--- core/trunk/api/container/src/main/java/org/codehaus/cargo/container/deployer/URLDeployableMonitor.java 2009-11-20 17:50:09 UTC (rev 1991)
+++ core/trunk/api/container/src/main/java/org/codehaus/cargo/container/deployer/URLDeployableMonitor.java 2009-11-23 08:26:01 UTC (rev 1992)
@@ -106,7 +106,7 @@

// We check if the deployable is servicing requests by pinging a URL specified by the user
HttpUtils.HttpResult results = new HttpUtils.HttpResult();
- boolean isDeployed = this.httpUtils.ping(this.pingURL, results);
+ boolean isDeployed = this.httpUtils.ping(this.pingURL, results, getTimeout());

getLogger().debug("URL [" + this.pingURL + "] is " + (isDeployed ? "" : "not ")
+ "responding...", this.getClass().getName());

Modified: core/trunk/api/container/src/main/java/org/codehaus/cargo/container/internal/util/HttpUtils.java
===================================================================
--- core/trunk/api/container/src/main/java/org/codehaus/cargo/container/internal/util/HttpUtils.java 2009-11-20 17:50:09 UTC (rev 1991)
+++ core/trunk/api/container/src/main/java/org/codehaus/cargo/container/internal/util/HttpUtils.java 2009-11-23 08:26:01 UTC (rev 1992)
@@ -74,7 +74,7 @@
*/
public final boolean ping(URL pingURL)
{
- return isAvailable(testConnectivity(pingURL, null));
+ return isAvailable(testConnectivity(pingURL, null, 0L));
}

/**
@@ -93,13 +93,40 @@
* Ping a URL and store the detailed result in a {@link HttpResult} object.
*
* @param pingURL the URL to ping
+ * @param result the detailed ping result
+ * @param timeout the timeout to wait for, 0 if waiting to infinity
+ * @return true if the URL can be ping or false otherwise
+ */
+ public final boolean ping(URL pingURL, HttpResult result, long timeout)
+ {
+ return ping(pingURL, null, result, timeout);
+ }
+
+ /**
+ * Ping a URL and store the detailed result in a {@link HttpResult} object.
+ *
+ * @param pingURL the URL to ping
* @param requestProperties optional request properties to add to the connection (can be null)
* @param result the detailed ping result
* @return true if the URL can be ping or false otherwise
*/
public final boolean ping(URL pingURL, Map requestProperties, HttpResult result)
{
- HttpResult responseResult = testConnectivity(pingURL, requestProperties);
+ return ping(pingURL, requestProperties, result, 0L);
+ }
+
+ /**
+ * Ping a URL and store the detailed result in a {@link HttpResult} object.
+ *
+ * @param pingURL the URL to ping
+ * @param requestProperties optional request properties to add to the connection (can be null)
+ * @param result the detailed ping result
+ * @param timeout the timeout to wait for, 0 if waiting to infinity
+ * @return true if the URL can be ping or false otherwise
+ */
+ public final boolean ping(URL pingURL, Map requestProperties, HttpResult result, long timeout)
+ {
+ HttpResult responseResult = testConnectivity(pingURL, requestProperties, timeout);
result.responseBody = responseResult.responseBody;
result.responseCode = responseResult.responseCode;
result.responseMessage = responseResult.responseMessage;
@@ -112,10 +139,11 @@
*
* @param url the URL to check
* @param requestProperties optional request properties to add to the connection (can be null)
+ * @param timeout the timeout in ms, 0 for infinity
* @return the HTTP(S) result containing -1 as response code if no connection could be
* established
*/
- private HttpResult testConnectivity(URL url, Map requestProperties)
+ private HttpResult testConnectivity(URL url, Map requestProperties, long timeout)
{
HttpResult result = new HttpResult();
try
@@ -139,6 +167,11 @@
}

connection.setRequestProperty("Connection", "close");
+ if (timeout != 0)
+ {
+ connection.setReadTimeout((int) timeout);
+ connection.setConnectTimeout((int) timeout);
+ }

// Add optional request properties specified by the caller
if (requestProperties != null)

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

http://xircles.codehaus.org/manage_email

From forum: Cargo - Dev

[jira] Assigned: (CARGO-413) DeployableMonitor required to be used in a separate thread

2009-11-23T00:23:55Z

[ http://jira.codehaus.org/browse/CARGO-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrian Cole reassigned CARGO-413:
---------------------------------

Assignee: Adrian Cole

> DeployableMonitor required to be used in a separate thread
> ----------------------------------------------------------
>
> Key: CARGO-413
> URL: http://jira.codehaus.org/browse/CARGO-413
> Project: Cargo
> Issue Type: Improvement
> Components: Tomcat
> Affects Versions: 0.9
> Reporter: Juri Artamonov
> Assignee: Adrian Cole
> Attachments: patch1.txt, patch2.txt, read-timeout.patch
>
>
> Sometimes deployment of the application hangs up and cargo couldn't get any answer from the tomcat manager. Currently there is timeout feature implemented in DeployableMonitor but monitor starts only after deployment is performed instead of starting in the same with deployment. For this DeployableMonitor required to be used in a separate thread and after timeout cargo can say that deployment is failed not waiting response from tomcat manager

From forum: Cargo - Dev

[jira] Work started: (CARGO-413) DeployableMonitor required to be used in a separate thread

2009-11-23T00:23:55Z

[ http://jira.codehaus.org/browse/CARGO-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CARGO-413 started by Adrian Cole.

> DeployableMonitor required to be used in a separate thread
> ----------------------------------------------------------
>
> Key: CARGO-413
> URL: http://jira.codehaus.org/browse/CARGO-413
> Project: Cargo
> Issue Type: Improvement
> Components: Tomcat
> Affects Versions: 0.9
> Reporter: Juri Artamonov
> Assignee: Adrian Cole
> Attachments: patch1.txt, patch2.txt, read-timeout.patch
>
>
> Sometimes deployment of the application hangs up and cargo couldn't get any answer from the tomcat manager. Currently there is timeout feature implemented in DeployableMonitor but monitor starts only after deployment is performed instead of starting in the same with deployment. For this DeployableMonitor required to be used in a separate thread and after timeout cargo can say that deployment is failed not waiting response from tomcat manager

From forum: Cargo - Dev

[jira] Updated: (CARGO-413) DeployableMonitor required to be used in a separate thread

2009-11-22T18:38:55Z

[ http://jira.codehaus.org/browse/CARGO-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Roper updated CARGO-413:
------------------------------

Attachment: read-timeout.patch

Attaching an updated patch for Cargo 1.0. This patch is for the general community to use themselves, not the Cargo developers, because in my experience, and as this bug report shows, there's no point in giving Cargo developers patches, they always ignore them.

> DeployableMonitor required to be used in a separate thread
> ----------------------------------------------------------
>
> Key: CARGO-413
> URL: http://jira.codehaus.org/browse/CARGO-413
> Project: Cargo
> Issue Type: Improvement
> Components: Tomcat
> Affects Versions: 0.9
> Reporter: Juri Artamonov
> Attachments: patch1.txt, patch2.txt, read-timeout.patch
>
>
> Sometimes deployment of the application hangs up and cargo couldn't get any answer from the tomcat manager. Currently there is timeout feature implemented in DeployableMonitor but monitor starts only after deployment is performed instead of starting in the same with deployment. For this DeployableMonitor required to be used in a separate thread and after timeout cargo can say that deployment is failed not waiting response from tomcat manager

From forum: Cargo - Dev

[jira] Commented: (CARGO-413) DeployableMonitor required to be used in a separate thread

2009-11-22T18:19:55Z

[ http://jira.codehaus.org/browse/CARGO-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199020#action_199020 ]

James Roper commented on CARGO-413:
-----------------------------------

I'm have a related issue with shutting down, if Tomcat fails to shut down cleanly, but instead continues to receive connections but never returns any data, then the {{URLDeployableMonitor}} sits waiting forever on {{HttpUtils.ping()}} (This is in Cargo 1.0, which has been refactored a bit since this issue was reported). Option 2 would solve this quite easily, setting the setReadTimeout for the HttpUrlConnection, or running the monitor in a separate thread would also solve it.

> DeployableMonitor required to be used in a separate thread
> ----------------------------------------------------------
>
> Key: CARGO-413
> URL: http://jira.codehaus.org/browse/CARGO-413
> Project: Cargo
> Issue Type: Improvement
> Components: Tomcat
> Affects Versions: 0.9
> Reporter: Juri Artamonov
> Attachments: patch1.txt, patch2.txt
>
>
> Sometimes deployment of the application hangs up and cargo couldn't get any answer from the tomcat manager. Currently there is timeout feature implemented in DeployableMonitor but monitor starts only after deployment is performed instead of starting in the same with deployment. For this DeployableMonitor required to be used in a separate thread and after timeout cargo can say that deployment is failed not waiting response from tomcat manager

From forum: Cargo - Dev

[cargo] r1991 - pom/trunk

2009-11-20T09:50:09Z

Author: adriancole
Date: 2009-11-20 11:50:09 -0600 (Fri, 20 Nov 2009)
New Revision: 1991

Modified:
pom/trunk/pom.xml
Log:
locking to 2.3 checkstyle plugin until we update to 5.0 format

Modified: pom/trunk/pom.xml
===================================================================
--- pom/trunk/pom.xml 2009-11-17 23:05:28 UTC (rev 1990)
+++ pom/trunk/pom.xml 2009-11-20 17:50:09 UTC (rev 1991)
@@ -309,6 +309,7 @@
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
+ <version>2.3</version>
<dependencies>
<dependency>
<groupId>org.codehaus.cargo</groupId>

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

http://xircles.codehaus.org/manage_email

From forum: Cargo - Dev

Re: does anyone recognise this error?

2009-11-20T09:42:43Z

good catch, Ryan. I'm back in business. I'll commit the lock to 2.3 shortly.

-Adrian

On Fri, Nov 20, 2009 at 9:39 AM, Ryan Connolly <rynam0@...> wrote:

> Yep, I should have seen this before replying. Below is the release email
> for checkstyle stating they upgraded to checkstyle 5.0. I'm guessing that's
> the reason for this error.
>
> Best,
> -Ryan
>
>
> The Maven team is pleased to announce the release of the Maven
> Checkstyle Plugin, version 2.4.
> This plugin generates a report on violations of code style and
> optionally fails the build if violations are detected.
> http://maven.apache.org/plugins/maven-checkstyle-plugin/
> You should specify the version in your project's plugin configuration:
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-checkstyle-plugin</artifactId>
> <version>2.4</version>
> </plugin>
> Release Notes - Maven 2.x Checkstyle Plugin - Version 2.4
> ** Improvement
>    * [MCHECKSTYLE-105] - Update to Checkstyle 5.0
>    * [MCHECKSTYLE-122] - Add Portuguese (Brazil) translation
>    * [MCHECKSTYLE-124] - Add Swedish translation
> ** Task
>    * [MCHECKSTYLE-119] - Review the Doxia Sink calls
>    * [MCHECKSTYLE-120] - Bump to Doxia 1.0
>    * [MCHECKSTYLE-125] - Update to maven-reporting-impl-2.0.4.3
> Enjoy,
> -The Maven team
>
>
> On Fri, Nov 20, 2009 at 12:36 PM, Ryan Connolly <rynam0@...> wrote:
>>
>> Hi guys:
>>     It would appear that maven-checkstyle-plugin version 2.4 was put up to
>> the maven repo 2 days ago? Locking down the checkstyle plugin version to
>> 2.3 resolves the issue for me. I'm guessing that the checkstyle.xml in the
>> cargo-build-tools project would need to be updated to reflect the changes in
>> the new release of the plugin or cargo should be locking down the version
>> the checkstyle.xml file was targeted at. I would do some more detailed
>> investigation but I'm kind of in the middle of something currently.
>>
>> Hope this helps.
>> -Ryan
>>
>> On Fri, Nov 20, 2009 at 11:15 AM, Adrian Cole <ferncam1@...> wrote:
>>>
>>> ya.. I'm using 2.2.1
>>>
>>> Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
>>> Java version: 1.6.0_15
>>> Java home:
>>> /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
>>> Default locale: en_US, platform encoding: MacRoman
>>> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
>>>
>>> weird.. but darn-it, it's holding me up :(
>>>
>>> I can launch a windows vm, but I really like my macbook.
>>>
>>> -A
>>>
>>> On Fri, Nov 20, 2009 at 6:31 AM, Matt Wringe <mwringe@...> wrote:
>>> > On Thu, 2009-11-19 at 22:35 -0800, Adrian Cole wrote:
>>> >> Trying to dust off cargo, but somewhat later ;)
>>> >>
>>> >> I'm now on osx 10.5.8
>>> >>
>>> >> Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
>>> >> Java version: 1.6.0_15
>>> >> Java home:
>>> >> /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
>>> >> Default locale: en_US, platform encoding: MacRoman
>>> >> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
>>> >>
>>> >>
>>> >> Error below:
>>> >>
>>> >> Embedded error: Failed during checkstyle configuration
>>> >> Unable to instantiate j2ee.EntityBeanCheck
>>> >> [INFO]
>>> >> ------------------------------------------------------------------------
>>> >> [DEBUG] Trace
>>> >>
>>> >> --snip---
>>> >> Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException:
>>> >> Unable to instantiate j2ee.EntityBeanCheck
>>> >> at
>>> >> com.puppycrawl.tools.checkstyle.PackageObjectFactory.doMakeObject(PackageObjectFactory.java:99)
>>> >> at
>>> >> com.puppycrawl.tools.checkstyle.PackageObjectFactory.createModule(PackageObjectFactory.java:153)
>>> >> ... 30 more
>>> >>
>>> >>
>>> >> Any ideas before I aimlessly try things?
>>> >
>>> > Strange, I don't think I have ever seen that.
>>> > What version of maven are you using? I am using 2.2.1 without any
>>> > problems.
>>> >
>>> >> Cheers,
>>> >> -Adrian
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> 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
>>>
>>>
>>
>>
>>
>> --
>> ®¥@N
>
>
>
> --
> ®¥@N
>

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

http://xircles.codehaus.org/manage_email

From forum: Cargo - Dev

Re: does anyone recognise this error?

2009-11-20T09:39:37Z

Yep, I should have seen this before replying. Below is the release email for checkstyle stating they upgraded to checkstyle 5.0. I'm guessing that's the reason for this error.

Best,

-Ryan

The Maven team is pleased to announce the release of the Maven
Checkstyle Plugin, version 2.4.

This plugin generates a report on violations of code style and
optionally fails the build if violations are detected.

http://maven.apache.org/plugins/maven-checkstyle-plugin/

You should specify the version in your project's plugin configuration:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.4</version>
</plugin>

Release Notes - Maven 2.x Checkstyle Plugin - Version 2.4

** Improvement
   * [MCHECKSTYLE-105] - Update to Checkstyle 5.0
   * [MCHECKSTYLE-122] - Add Portuguese (Brazil) translation
   * [MCHECKSTYLE-124] - Add Swedish translation

** Task
   * [MCHECKSTYLE-119] - Review the Doxia Sink calls
   * [MCHECKSTYLE-120] - Bump to Doxia 1.0
   * [MCHECKSTYLE-125] - Update to maven-reporting-impl-2.0.4.3

Enjoy,

-The Maven team

On Fri, Nov 20, 2009 at 12:36 PM, Ryan Connolly <rynam0@...> wrote:

Hi guys:

It would appear that maven-checkstyle-plugin version 2.4 was put up to the maven repo 2 days ago? Locking down the checkstyle plugin version to 2.3 resolves the issue for me. I'm guessing that the checkstyle.xml in the cargo-build-tools project would need to be updated to reflect the changes in the new release of the plugin or cargo should be locking down the version the checkstyle.xml file was targeted at. I would do some more detailed investigation but I'm kind of in the middle of something currently.

Hope this helps.

-Ryan

On Fri, Nov 20, 2009 at 11:15 AM, Adrian Cole <ferncam1@...> wrote:

ya.. I'm using 2.2.1

Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
Java version: 1.6.0_15
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"

weird.. but darn-it, it's holding me up :(

I can launch a windows vm, but I really like my macbook.

-A

On Fri, Nov 20, 2009 at 6:31 AM, Matt Wringe <mwringe@...> wrote:
> On Thu, 2009-11-19 at 22:35 -0800, Adrian Cole wrote:
>> Trying to dust off cargo, but somewhat later ;)
>>
>> I'm now on osx 10.5.8
>>
>> Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
>> Java version: 1.6.0_15
>> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
>> Default locale: en_US, platform encoding: MacRoman
>> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
>>
>>
>> Error below:
>>
>> Embedded error: Failed during checkstyle configuration
>> Unable to instantiate j2ee.EntityBeanCheck
>> [INFO] ------------------------------------------------------------------------
>> [DEBUG] Trace
>>
>> --snip---
>> Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException:
>> Unable to instantiate j2ee.EntityBeanCheck
>> at com.puppycrawl.tools.checkstyle.PackageObjectFactory.doMakeObject(PackageObjectFactory.java:99)
>> at com.puppycrawl.tools.checkstyle.PackageObjectFactory.createModule(PackageObjectFactory.java:153)
>> ... 30 more
>>
>>
>> Any ideas before I aimlessly try things?
>
> Strange, I don't think I have ever seen that.
> What version of maven are you using? I am using 2.2.1 without any
> problems.
>
>> Cheers,
>> -Adrian
>>
>> ---------------------------------------------------------------------
>> 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

--
®¥@N

--
®¥@N

From forum: Cargo - Dev

Re: does anyone recognise this error?

2009-11-20T09:36:59Z

Hi guys:

It would appear that maven-checkstyle-plugin version 2.4 was put up to the maven repo 2 days ago? Locking down the checkstyle plugin version to 2.3 resolves the issue for me. I'm guessing that the checkstyle.xml in the cargo-build-tools project would need to be updated to reflect the changes in the new release of the plugin or cargo should be locking down the version the checkstyle.xml file was targeted at. I would do some more detailed investigation but I'm kind of in the middle of something currently.

Hope this helps.

-Ryan

On Fri, Nov 20, 2009 at 11:15 AM, Adrian Cole <ferncam1@...> wrote:

ya.. I'm using 2.2.1

Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
Java version: 1.6.0_15
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"

weird.. but darn-it, it's holding me up :(

I can launch a windows vm, but I really like my macbook.

-A

On Fri, Nov 20, 2009 at 6:31 AM, Matt Wringe <mwringe@...> wrote:
> On Thu, 2009-11-19 at 22:35 -0800, Adrian Cole wrote:
>> Trying to dust off cargo, but somewhat later ;)
>>
>> I'm now on osx 10.5.8
>>
>> Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
>> Java version: 1.6.0_15
>> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
>> Default locale: en_US, platform encoding: MacRoman
>> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
>>
>>
>> Error below:
>>
>> Embedded error: Failed during checkstyle configuration
>> Unable to instantiate j2ee.EntityBeanCheck
>> [INFO] ------------------------------------------------------------------------
>> [DEBUG] Trace
>>
>> --snip---
>> Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException:
>> Unable to instantiate j2ee.EntityBeanCheck
>> at com.puppycrawl.tools.checkstyle.PackageObjectFactory.doMakeObject(PackageObjectFactory.java:99)
>> at com.puppycrawl.tools.checkstyle.PackageObjectFactory.createModule(PackageObjectFactory.java:153)
>> ... 30 more
>>
>>
>> Any ideas before I aimlessly try things?
>
> Strange, I don't think I have ever seen that.
> What version of maven are you using? I am using 2.2.1 without any
> problems.
>
>> Cheers,
>> -Adrian
>>
>> ---------------------------------------------------------------------
>> 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

--
®¥@N

From forum: Cargo - Dev

Re: does anyone recognise this error?

2009-11-20T08:15:01Z

ya.. I'm using 2.2.1

Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
Java version: 1.6.0_15
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"

weird.. but darn-it, it's holding me up :(

I can launch a windows vm, but I really like my macbook.

-A

On Fri, Nov 20, 2009 at 6:31 AM, Matt Wringe <mwringe@...> wrote:

> On Thu, 2009-11-19 at 22:35 -0800, Adrian Cole wrote:
>> Trying to dust off cargo, but somewhat later ;)
>>
>> I'm now on osx 10.5.8
>>
>> Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
>> Java version: 1.6.0_15
>> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
>> Default locale: en_US, platform encoding: MacRoman
>> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
>>
>>
>> Error below:
>>
>> Embedded error: Failed during checkstyle configuration
>> Unable to instantiate j2ee.EntityBeanCheck
>> [INFO] ------------------------------------------------------------------------
>> [DEBUG] Trace
>>
>> --snip---
>> Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException:
>> Unable to instantiate j2ee.EntityBeanCheck
>> at com.puppycrawl.tools.checkstyle.PackageObjectFactory.doMakeObject(PackageObjectFactory.java:99)
>> at com.puppycrawl.tools.checkstyle.PackageObjectFactory.createModule(PackageObjectFactory.java:153)
>> ... 30 more
>>
>>
>> Any ideas before I aimlessly try things?
>
> Strange, I don't think I have ever seen that.
> What version of maven are you using? I am using 2.2.1 without any
> problems.
>
>> Cheers,
>> -Adrian
>>
>> ---------------------------------------------------------------------
>> 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

From forum: Cargo - Dev

Re: does anyone recognise this error?

2009-11-20T06:31:34Z

On Thu, 2009-11-19 at 22:35 -0800, Adrian Cole wrote:

> Trying to dust off cargo, but somewhat later ;)
>
> I'm now on osx 10.5.8
>
> Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
> Java version: 1.6.0_15
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
>
>
> Error below:
>
> Embedded error: Failed during checkstyle configuration
> Unable to instantiate j2ee.EntityBeanCheck
> [INFO] ------------------------------------------------------------------------
> [DEBUG] Trace
>
> --snip---
> Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException:
> Unable to instantiate j2ee.EntityBeanCheck
> at com.puppycrawl.tools.checkstyle.PackageObjectFactory.doMakeObject(PackageObjectFactory.java:99)
> at com.puppycrawl.tools.checkstyle.PackageObjectFactory.createModule(PackageObjectFactory.java:153)
> ... 30 more
>
>
> Any ideas before I aimlessly try things?

Strange, I don't think I have ever seen that.
What version of maven are you using? I am using 2.2.1 without any
problems.

> Cheers,
> -Adrian
>
> ---------------------------------------------------------------------
> 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

From forum: Cargo - Dev

[jira] Closed: (CARGO-736) Unable to check out code.

2009-11-20T06:29:55Z

[ http://jira.codehaus.org/browse/CARGO-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Wringe closed CARGO-736.
-----------------------------

Resolution: Not A Bug

This was probably due to the server being momentarily down. I am having no problems accessing the svn server.

From forum: Cargo - Dev

does anyone recognise this error?

2009-11-19T22:35:40Z

Trying to dust off cargo, but somewhat later ;)

I'm now on osx 10.5.8

Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
Java version: 1.6.0_15
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"

Error below:

Embedded error: Failed during checkstyle configuration
Unable to instantiate j2ee.EntityBeanCheck
[INFO] ------------------------------------------------------------------------
[DEBUG] Trace

--snip---
Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException:
Unable to instantiate j2ee.EntityBeanCheck
at com.puppycrawl.tools.checkstyle.PackageObjectFactory.doMakeObject(PackageObjectFactory.java:99)
at com.puppycrawl.tools.checkstyle.PackageObjectFactory.createModule(PackageObjectFactory.java:153)
... 30 more

Any ideas before I aimlessly try things?

Cheers,
-Adrian

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

http://xircles.codehaus.org/manage_email

From forum: Cargo - Dev

[jira] Created: (CARGO-736) Unable to check out code.

2009-11-19T21:04:55Z

Unable to check out code.
-------------------------

Key: CARGO-736
URL: http://jira.codehaus.org/browse/CARGO-736
Project: Cargo
Issue Type: Bug
Components: Build
Environment: Windows XP SP2
Reporter: Bharath Srinivasan

Hello:

I am unable to checkout code from SVN using the below command as suggested in http://cargo.codehaus.org/SVN

>svn co http://svn.codehaus.org/cargo/trunks
svn: OPTIONS of 'http://svn.codehaus.org/cargo/trunks': could not connect to server (http://svn.codehaus.org)

Can you please help us move forward.

Thanks,
Bharath

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

http://xircles.codehaus.org/manage_email

From forum: Cargo - Dev

[jira] Updated: (CARGO-734) Add Tomcat support for multi-level context paths

2009-11-17T16:21:55Z

> Add Tomcat support for multi-level context paths
> ------------------------------------------------
>
> Key: CARGO-734
> URL: http://jira.codehaus.org/browse/CARGO-734
> Project: Cargo
> Issue Type: Improvement
> Components: Tomcat
> Reporter: Chris Marks
> Priority: Minor
> Attachments: cargo-core-container-tomcat_2009_11_17.patch
>
>
> Tomcat provides support for multi-level contexts as of v5.5.27 and v6.0.18. A multi-level context is when an application appears to be deployed to a sub-directory, such as random/location. When using Tomcat, you can name your WAR file using a # to indicate a directory change, so for the previous example, the war file name would be random#location.war. In order to use Cargo to deploy a war that is named in this convention, TomcatWAR.getContext() needs to be modified to accomodate the new convention.
> Attached is a patch that does a regular expression replace of '#' with '/' for the context name. It does include a unit test to test the situation and a sample war file using the new naming scheme.

From forum: Cargo - Dev

[jira] Updated: (CARGO-734) Add Tomcat support for multi-level context paths

2009-11-17T16:21:55Z

[ http://jira.codehaus.org/browse/CARGO-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Marks updated CARGO-734:
------------------------------

Attachment: cargo-core-container-tomcat_2009_11_17.patch

Added a patch that did not include the new binary file tomcat#multi.war per instruction. The war file was a copy of tomcat-empty.war and is necessary for the new unit test in org.codehaus.cargo.container.tomcat.TomcatWARTest to pass.

From forum: Cargo - Dev

[jira] Closed: (CARGO-715) log4j.xml for jboss42x is broken (invalid syntax)

2009-11-17T15:06:55Z

[ http://jira.codehaus.org/browse/CARGO-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Wringe closed CARGO-715.
-----------------------------

Resolution: Fixed

Should now be fixed in svn.
Please comment on this task if your issue is not resolved.

> log4j.xml for jboss42x is broken (invalid syntax)
> -------------------------------------------------
>
> Key: CARGO-715
> URL: http://jira.codehaus.org/browse/CARGO-715
> Project: Cargo
> Issue Type: Bug
> Components: JBoss
> Environment: Any
> Reporter: Per Lewau
> Attachments: log4j.xml.patch
>
>
> The file installed in .../cargo/conf/conf/log4j.xml[1] when using the jboss42x container is broken. The file contains the same XML content twice resulting in invalid XML and errors when starting the container.
> I included the trivial patch that corrects the file.
> [1] http://fisheye.codehaus.org/browse/~br=core%3Atrunk/cargo/core/trunk/containers/jboss/src/main/resources/org/codehaus/cargo/container/internal/resources/jboss42x/log4j.xml

From forum: Cargo - Dev

[cargo] r1990 - core/trunk/containers/jboss/src/main/resources/org/codehaus/cargo/container/internal/resources/jboss42x

2009-11-17T15:05:29Z

Author: mwringe
Date: 2009-11-17 17:05:28 -0600 (Tue, 17 Nov 2009)
New Revision: 1990

Modified:
core/trunk/containers/jboss/src/main/resources/org/codehaus/cargo/container/internal/resources/jboss42x/log4j.xml
Log:
Remove duplicated text in file (CARGO-715)

Modified: core/trunk/containers/jboss/src/main/resources/org/codehaus/cargo/container/internal/resources/jboss42x/log4j.xml
===================================================================
--- core/trunk/containers/jboss/src/main/resources/org/codehaus/cargo/container/internal/resources/jboss42x/log4j.xml 2009-11-17 22:58:07 UTC (rev 1989)
+++ core/trunk/containers/jboss/src/main/resources/org/codehaus/cargo/container/internal/resources/jboss42x/log4j.xml 2009-11-17 23:05:28 UTC (rev 1990)
@@ -295,302 +295,4 @@
</category>
-->

-</log4j:configuration>
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
-
-
-
-
-
-
-
-
-
-
-
-<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">
-
- 
- 
- 
-
- 
- <appender name="FILE" class="org.jboss.logging.appender.DailyRollingFileAppender">
- <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
- <param name="File" value="${jboss.server.log.dir}/server.log"/>
- <param name="Append" value="false"/>
- <param name="Threshold" value="@cargo.logging@"/>
-
- 
- <param name="DatePattern" value="'.'yyyy-MM-dd"/>
-
- 
-
- <layout class="org.apache.log4j.PatternLayout">
- 
- <param name="ConversionPattern" value="%d %-5p [%c] %m%n"/>
-
- 
- </layout>
- </appender>
-
- 
-
- 
- 
- 
-
- <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
- <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
- <param name="Target" value="System.out"/>
- <param name="Threshold" value="@cargo.logging@"/>
-
- <layout class="org.apache.log4j.PatternLayout">
- 
- <param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>
- </layout>
- </appender>
-
- 
- 
- 
-
- 
-
- 
-
- 
-
- 
-
- 
-
- 
-
- 
- 
- 
-
- 
- <category name="org.apache">
- <priority value="INFO"/>
- </category>
-
- 
- <category name="org.jboss.serial">
- <priority value="INFO"/>
- </category>
-
- 
- <category name="org.jgroups">
- <priority value="WARN"/>
- </category>
-
- 
- <category name="jacorb">
- <priority value="WARN"/>
- </category>
-
- 
-
- 
- <category name="org.jboss.management">
- <priority value="INFO"/>
- </category>
-
- 
-
- 
-
- 
-
- 
-
- 
-
- 
- 
- 
-
- <root>
- <appender-ref ref="CONSOLE"/>
- <appender-ref ref="FILE"/>
- </root>
-
- 
- 
-
-</log4j:configuration>
+</log4j:configuration>
\ No newline at end of file

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

http://xircles.codehaus.org/manage_email

From forum: Cargo - Dev

[jira] Closed: (CARGO-731) Undeploy with Jetty Cargo Deployer does now work under Windows

2009-11-17T14:58:55Z

[ http://jira.codehaus.org/browse/CARGO-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Wringe closed CARGO-731.
-----------------------------

Resolution: Fixed

It should now be fixed in svn.
Please open a bug if this does not fix your issue.

> Undeploy with Jetty Cargo Deployer does now work under Windows
> --------------------------------------------------------------
>
> Key: CARGO-731
> URL: http://jira.codehaus.org/browse/CARGO-731
> Project: Cargo
> Issue Type: Bug
> Components: Jetty
> Affects Versions: 1.0
> Reporter: Jens Schuetter
> Attachments: aaa.txt, DeployerServlet.java
>
>
> DeployerServlet needs to use File.separator instead of "/"
> Currently some checks for file and folder existence don't work properly under Windows which results e.g in failed undeployment.
> Java error trace and patched DeployerServlet.java attached.
> Latest snapshot version was used for tests:
> http://snapshots.repository.codehaus.org//org/codehaus/cargo/cargo-jetty-deployer/1.0.1-SNAPSHOT/cargo-jetty-deployer-1.0.1-20090902.191521-8.war

From forum: Cargo - Dev

[cargo] r1989 - resources/trunk/jetty-deployer/src/main/java/org/codehaus/cargo/deployer/jetty

2009-11-17T14:58:07Z

Author: mwringe
Date: 2009-11-17 16:58:07 -0600 (Tue, 17 Nov 2009)
New Revision: 1989

Modified:
resources/trunk/jetty-deployer/src/main/java/org/codehaus/cargo/deployer/jetty/DeployerServlet.java
Log:
Use File.separator instead of hardcoding to "/" for better portability (CARGO-731).

Modified: resources/trunk/jetty-deployer/src/main/java/org/codehaus/cargo/deployer/jetty/DeployerServlet.java
===================================================================
--- resources/trunk/jetty-deployer/src/main/java/org/codehaus/cargo/deployer/jetty/DeployerServlet.java 2009-11-17 22:34:26 UTC (rev 1988)
+++ resources/trunk/jetty-deployer/src/main/java/org/codehaus/cargo/deployer/jetty/DeployerServlet.java 2009-11-17 22:58:07 UTC (rev 1989)
@@ -88,7 +88,7 @@
{
this.configHome = System.getProperty("config.home");
}
- this.webAppDirectory = configHome + "/webapps";
+ this.webAppDirectory = configHome + File.separator + "webapps";

// TODO there could potentially be more than one context handler
// collection
@@ -266,8 +266,8 @@
fileName = contextPath;
}

- File webappArchive = new File(webAppDirectory + "/" + fileName + ".war");
- File webappDirectory = new File(webAppDirectory + "/" + fileName);
+ File webappArchive = new File(webAppDirectory + File.separator + fileName + ".war");
+ File webappDirectory = new File(webAppDirectory + File.separator + fileName);

File returnedFile = null;

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

http://xircles.codehaus.org/manage_email

From forum: Cargo - Dev

[jira] Commented: (CARGO-734) Add Tomcat support for multi-level context paths

2009-11-17T14:47:55Z

[ http://jira.codehaus.org/browse/CARGO-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198564#action_198564 ]

Matt Wringe commented on CARGO-734:
-----------------------------------

The patch contains binary information (src/test/resources/org/codehaus/cargo/container/tomcat/tomcat#multi.war).
Can you please provide a patch that only contains source code.

> Add Tomcat support for multi-level context paths
> ------------------------------------------------
>
> Key: CARGO-734
> URL: http://jira.codehaus.org/browse/CARGO-734
> Project: Cargo
> Issue Type: Improvement
> Components: Tomcat
> Reporter: Chris Marks
> Priority: Minor
> Attachments: cargo-core-container-tomcat.patch
>
>
> Tomcat provides support for multi-level contexts as of v5.5.27 and v6.0.18. A multi-level context is when an application appears to be deployed to a sub-directory, such as random/location. When using Tomcat, you can name your WAR file using a # to indicate a directory change, so for the previous example, the war file name would be random#location.war. In order to use Cargo to deploy a war that is named in this convention, TomcatWAR.getContext() needs to be modified to accomodate the new convention.
> Attached is a patch that does a regular expression replace of '#' with '/' for the context name. It does include a unit test to test the situation and a sample war file using the new naming scheme.

From forum: Cargo - Dev

[jira] Closed: (CARGO-735) AbstractInstalledLocalContainer will cause a NullPointerException if a simple file name is used as the "output" file

2009-11-17T14:35:55Z

[ http://jira.codehaus.org/browse/CARGO-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Wringe closed CARGO-735.
-----------------------------

Resolution: Fixed

Patch committed into svn head.

> AbstractInstalledLocalContainer will cause a NullPointerException if a simple file name is used as the "output" file
> --------------------------------------------------------------------------------------------------------------------
>
> Key: CARGO-735
> URL: http://jira.codehaus.org/browse/CARGO-735
> Project: Cargo
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.1
> Reporter: Christopher Rued
> Priority: Minor
> Attachments: diff.txt
>
>
> AbstractInstalledLocalContainer's createJavaTask method attempts to ensure that all the correct folders exist before creating the output file. It does this by calling outputFile.getParentFile().mkdirs() without first ensuring that outputFile.getParentFile() is not null.
> To work around this, the value of outputFile.getParentFile() should be checked, or outputFile.getAbsoluteFile().getParentFile().mkdirs() should be used (since the absolute file must have a parent).
> Patch attached.

From forum: Cargo - Dev

[cargo] r1988 - core/trunk/api/container/src/main/java/org/codehaus/cargo/container/spi

2009-11-17T14:34:26Z

Author: mwringe
Date: 2009-11-17 16:34:26 -0600 (Tue, 17 Nov 2009)
New Revision: 1988

Modified:
core/trunk/api/container/src/main/java/org/codehaus/cargo/container/spi/AbstractInstalledLocalContainer.java
Log:
Fix issue with not using absolute file path for outout file (CARGO-735, patch from Christopher Rued)

Modified: core/trunk/api/container/src/main/java/org/codehaus/cargo/container/spi/AbstractInstalledLocalContainer.java
===================================================================
--- core/trunk/api/container/src/main/java/org/codehaus/cargo/container/spi/AbstractInstalledLocalContainer.java 2009-10-14 22:31:37 UTC (rev 1987)
+++ core/trunk/api/container/src/main/java/org/codehaus/cargo/container/spi/AbstractInstalledLocalContainer.java 2009-11-17 22:34:26 UTC (rev 1988)
@@ -302,7 +302,7 @@
File outputFile = new File(getOutput());

// Ensure that directories where the output file will go are created
- outputFile.getParentFile().mkdirs();
+ outputFile.getAbsoluteFile().getParentFile().mkdirs();

java.setOutput(outputFile);
java.setAppend(isAppend());

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

http://xircles.codehaus.org/manage_email

From forum: Cargo - Dev

Re: collaboration on platform modernization of cargo

2009-11-13T10:59:38Z

Thanks for the support, Vincent.

Cargo already supports sftp (via vfs), a key cloud enabler. The first
change we need is redirecting the execution of java commands to
optionally happen across the wire. This first milestone can be tested
without clouds using loopback or traditional ssh. While ssh limits us
to non-windows, I'd consider it a pragmatic constraint allowing us to
quickly prototype without introducing too much complexity.

The next piece would involve creation and deletion of cloud hosts,
including means of passing vitals such as cloud credentials, instance
ids, ssh keys and public ips to and from cargo. We'll also need a way
to plugin various cloud providers which may end up looking quite
similar to how we do containers. This allows us to make meaningful
default size and os image choices per-provider.

Please speak up, if you are interested in being involved. I'd like to
start this effort in anger within the next ten days. (Don't worry,
I'll create a branch ;) )

Cheers,
-Adrian

On Sun, Nov 8, 2009 at 11:03 PM, Vincent Massol <vincent@...> wrote:

> Hi Adrian,
>
> On Nov 9, 2009, at 5:22 AM, Adrian Cole wrote:
>
>> Hi, Team.
>>
>> It's been a while since I've sunk day and night into Cargo... I guess
>> I'm looking for some more action!
>>
>> As you probably know, I run the jclouds [1] project, which is a cloud
>> framework. It would seem quite useful and appropriate to have a means
>> to deploy to compute clouds directly from cargo. jclouds currently
>> has tools to manage google appengine, amazon, rackspace, and vmware
>> clouds.
>>
>> With some collaboration, we could make cargo a cloud launch-pad.
>> Anyone interested in something like this?
>
> From the outside it looks like a very good idea.
>
> Cheers,
> -Vincent
>
>>
>> Cheers,
>> -Adrian
>> [1] http://code.google.com/p/jclouds/
>
> ---------------------------------------------------------------------
> 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

From forum: Cargo - Dev

Re: Remote undeploy, redeploy deployer-stop does not work for Tomcat 6

2009-11-13T05:21:24Z

That is it. Thanks a lot, Mathieu! (I've updated JIRA).

From:	Mathieu Hicauber <mhicauber@...>
To:	user@...
Date:	13.11.2009 13:44
Subject:	Re: [cargo-user] Remote undeploy, redeploy deployer-stop does not work for Tomcat 6

Hi, Don't you have to strip off the last part of the tomcat manager url property in the pom ? This sould be : <cargo.tomcat.manager.url>http://example:8080/manager</cargo.tomcat.manager.url> I think. Mathieu On Fri, Nov 13, 2009 at 11:26 AM, <w.kruse@...> wrote: > I've added a comment to: > >http://jira.codehaus.org/browse/CARGO-634> > Did someone manage to get "cargo:redeploy" or "cargo:undeploy" working on > remote tomcat 6.0.x? > In both cases there is a request to "/manager/html/list" which throws an > exception. The same happens on "mvn install", but fortunately > after "cargo:deploy". > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

From forum: Cargo - User

[jira] Commented: (CARGO-634) Remote undeploy, redeploy deployer-stop does not work for Tomcat 6

2009-11-13T05:20:55Z

[ http://jira.codehaus.org/browse/CARGO-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198227#action_198227 ]

Wadim Kruse commented on CARGO-634:
-----------------------------------

That is it. Thanks, Mathieu!

{quote}
Hi,

Don't you have to strip off the last part of the tomcat manager url
property in the pom ?

This sould be :

<cargo.tomcat.manager.url>http://example:8080/manager</cargo.tomcat.manager.url>

I think.

Mathieu
{quote}

> Remote undeploy, redeploy deployer-stop does not work for Tomcat 6
> ------------------------------------------------------------------
>
> Key: CARGO-634
> URL: http://jira.codehaus.org/browse/CARGO-634
> Project: Cargo
> Issue Type: Bug
> Components: Maven2, Tomcat
> Affects Versions: 1.0
> Environment: Tomcat 6.0.14
> Reporter: Chris Wewerka
>
> By using mvn cargo:deploy a WAR is successfully deployed to a remote Tomcat 6.0.14 container.
> However undeploy, redeploy, deployer-stop does not work and throws an exception:
> First whole Tomcat Manager site is sent to stdout with Message : OK
> ...
> [INFO] ------------------------------------------------------------------------
> [INFO] Trace
> org.codehaus.cargo.container.ContainerException: Failed to stop [e:\var\opt\maven-2\repo-kvb\de\kvb\smarakt\eule-web\3.1.0-SNAPSHOT\eule-web-3.1.0-SNAPSHOT.war]
> at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.stop(AbstractTomcatManagerDeployer.java:247)
> ...

From forum: Cargo - Dev

Re: Remote undeploy, redeploy deployer-stop does not work for Tomcat 6

2009-11-13T04:44:06Z

Hi,

Don't you have to strip off the last part of the tomcat manager url
property in the pom ?

This sould be :

<cargo.tomcat.manager.url>http://example:8080/manager</cargo.tomcat.manager.url>

I think.

Mathieu

On Fri, Nov 13, 2009 at 11:26 AM, <w.kruse@...> wrote:

> I've added a comment to:
>
> http://jira.codehaus.org/browse/CARGO-634
>
> Did someone manage to get "cargo:redeploy" or "cargo:undeploy" working on
> remote tomcat 6.0.x?
> In both cases there is a request to "/manager/html/list" which throws an
> exception. The same happens on "mvn install", but fortunately
> after "cargo:deploy".
>
>

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

http://xircles.codehaus.org/manage_email

From forum: Cargo - User

Re: Setting up

2009-11-13T03:44:55Z

It is also possible to put your properties in the separate *.properties file and using "properties-maven-plugin":

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<executions>
<execution>
<id>pre-build</id>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
</execution>
</executions>
<configuration>
<files>
<file>build.properties</file>
</files>
</configuration>
</plugin>

and then:

<properties>
<cargo.tomcat.manager.url>${tomcat.prod}</cargo.tomcat.manager.url>
<cargo.remote.username>${tomcat.prod.username}</cargo.remote.username>
<cargo.remote.password>${comcat.prod.password}</cargo.remote.password>
</properties>

Works great with profiles.

From forum: Cargo - User

Remote undeploy, redeploy deployer-stop does not work for Tomcat 6

2009-11-13T02:26:05Z

I've added a comment to:

http://jira.codehaus.org/browse/CARGO-634

Did someone manage to get "cargo:redeploy" or "cargo:undeploy" working on remote tomcat 6.0.x?
In both cases there is a request to "/manager/html/list" which throws an exception. The same happens on "mvn install", but fortunately
after "cargo:deploy".

From forum: Cargo - User

[jira] Commented: (CARGO-481) Add a configuration element that allows you to skip plugin's execution

2009-11-12T18:23:55Z

[ http://jira.codehaus.org/browse/CARGO-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198188#action_198188 ]

Matt Raible commented on CARGO-481:
-----------------------------------

Any chance of getting this added? I've found I'm in need of this to skip Cargo from running when -DskipTests is passed in. I can put everything in a profile, but I'm only able to active one profile in my pom at a time.

> Add a <skip> configuration element that allows you to skip plugin's execution
> -----------------------------------------------------------------------------
>
> Key: CARGO-481
> URL: http://jira.codehaus.org/browse/CARGO-481
> Project: Cargo
> Issue Type: New Feature
> Components: Maven2
> Affects Versions: 0.2-maven2
> Reporter: Matt Raible
>
> The DbUnit, Hibernate3 and SQL Maven 2 Plugins have a "skip" configuration element that can be set to true in order to skip execution. This is a nice feature because it allows you pass in -Dmaven.test.skip=true and skip execution by adding the following in your pom.xml.
> <configuration>
> ...
> <skip>${maven.test.skip}</skip>
> </configuration>

From forum: Cargo - Dev

[jira] Commented: (CARGO-634) Remote undeploy, redeploy deployer-stop does not work for Tomcat 6

2009-11-12T11:57:55Z

[ http://jira.codehaus.org/browse/CARGO-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198148#action_198148 ]

Wadim Kruse commented on CARGO-634:
-----------------------------------

Wireshark says, there is only one request to "manager/html/list", the whole site is sent to stdout with exceptions in between.

Tomcat 6.0.18, cargo-maven2-plugin 1.0.1-SNAPSHOT *cargo:undeploy* and *cargo:redeploy* (*cargo:deploy* works):

Tomcat Manager HTML here...

{code:java}
org.codehaus.cargo.container.ContainerException: Failed to undeploy/redeploy [xxx.war]

at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.undeploy(AbstractTomcatManagerDeployer.java:137) //cargo:undeploy

at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:183) //cargo:redeploy

at org.codehaus.cargo.maven2.DeployerUndeployMojo.performDeployerActionOnSingleDeployable(DeployerUndeployMojo.java:39)

at org.codehaus.cargo.maven2.AbstractDeployerMojo.performDeployerActionOnAllDeployables(AbstractDeployerMojo.java:104)

at org.codehaus.cargo.maven2.AbstractDeployerMojo.doExecute(AbstractDeployerMojo.java:47)

at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:255)

at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)

at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)

at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)

at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)

at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)

at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
{code}

Tomcat Manger HTML here...

{code:java}
// both (cargo:undeploy and cargo:redeploy)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:525)

at org.codehaus.cargo.container.tomcat.internal.TomcatManager.list(TomcatManager.java:640)

at org.codehaus.cargo.container.tomcat.internal.TomcatManager.getStatus(TomcatManager.java:653)

at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.undeploy(AbstractTomcatManagerDeployer.java:124)

at org.codehaus.cargo.maven2.DeployerUndeployMojo.performDeployerActionOnSingleDeployable(DeployerUndeployMojo.java:39)

at org.codehaus.cargo.maven2.AbstractDeployerMojo.performDeployerActionOnAllDeployables(AbstractDeployerMojo.java:104)

at org.codehaus.cargo.maven2.AbstractDeployerMojo.doExecute(AbstractDeployerMojo.java:47)

at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:255)

at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)

at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)

at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)

at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)

at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)

at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
{code}

pom.xml
{code:xml}
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.0.1-SNAPSHOT</version>
<configuration>
<container>
<containerId>tomcat6x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.tomcat.manager.url>http://example:8080/manager/html</cargo.tomcat.manager.url>
<cargo.remote.username>admin</cargo.remote.username>
<cargo.remote.password>password</cargo.remote.password>
</properties>
</configuration>
<deployer>
<type>remote</type>
<deployables>
<deployable>
<properties>
<context>xxx</context>
</properties>
<pingURL>http://example:8080/xxx</pingURL>
</deployable>
</deployables>
</deployer>
</configuration>
<executions>
<execution>
<id>start-container</id>
<phase>pre-integration-test</phase>
<goals>
<goal>deployer-deploy</goal>
</goals>
</execution>
<execution>
<id>stop-container</id>
<phase>post-integration-test</phase>
<goals>
<goal>deployer-undeploy</goal>
</goals>
</execution>
<execution>
<id>verify-deploy</id>
<phase>install</phase>
<goals>
<goal>deployer-deploy</goal>
</goals>
</execution>
<execution>
<id>clean-undeploy</id>
<phase>pre-clean</phase>
<goals>
<goal>deployer-undeploy</goal>
</goals>
</execution>
</executions>
</plugin>
{code}

From forum: Cargo - Dev

Re: Setting up

2009-11-12T03:39:26Z

Hi all,

Just so this answer is recorded somewhere (I certainly couldn't find a decent example anywhere on the web) this worked for me:

To use cargo-maven2-plugin to deploy to a remote server but use a settings.xml file for the username and password you can use a profile with properties and use those properties but probably easier:

define a server in your settings.xml file for example like this:

<container>
<containerId>tomcat6x</containerId>
<type>remote</type>
</container>


<configuration>
<type>runtime</type>
<properties>
<cargo.server.settings>myServer</cargo.server.settings> 
</properties>
/configuration>

then define a server in your ~/.m2/settings.xml file

<id>myServer</id>

<cargo.tomcat.manager.url>http://myexampleurl.com/manager</cargo.tomcat.manager.url>

<cargo.remote.username>foo</cargo.remote.username>

<cargo.remote.password>bar</cargo.remote.password>

</configuration>

</server>

</servers>

</settings>

and you should be away

On 12 Nov 2009, at 11:24, Alexander Brill wrote:

On Wed, Nov 11, 2009 at 3:35 PM, Robert Denison <rob@...> wrote:
Hi,

I'm using cargo-maven2-plugin to deploy to my running tomcat container. While testing I have my connect details (username password etc) in my pom.xml.

Now I'm ready to go live I want to remove them. Searching seems to yield 3 possibilities using settings.xml - using profiles and properties, or standard maven2 <server> tags, or I found this reference to different server tags http://jira.codehaus.org/browse/CARGO-596 involving elements like cargo.remote.password.

Can anyone tell me what the correct method for keeping login details out of your pom is when using this plugin? If this is documented somewhere I would love a link as I've spent quite a bit of time searching for this answer. Failing that if someone has the time a small example of what you would use would be perfect.

Thanks for any help.

R.

You could put your login details in .m2/settings.xml.
Something like this:

<properties>
<tomcat.server.1.username>myuser</tomcat.server.1.username>

<tomcat.server.1.passwd>password</tomcat.server.1.password>
</properties>

And then reference them in your pom.xml as a variable with ${tomcat.server.1.username}

Alexander
http://brill.no

From forum: Cargo - User