Re: Deploy large files

2010-09-30 Thread Em DauPhu
(DefaultLifecycleExecutor.java:519)
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:362)
at 
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
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)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error
deploying artifact: Read timed out
at 
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:189)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
... 17 more
Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
Error deploying artifact: Read timed out
at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:121)
at 
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:184)
... 19 more
Caused by: org.apache.maven.wagon.TransferFailedException: Read timed out
at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:336)
at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280)
at 
org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:262)
at 
org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:172)
at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107)
... 20 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at 
hidden.org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
at 
hidden.org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
at 
hidden.org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
at 
hidden.org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1413)
at 
hidden.org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
at 
hidden.org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
at 
hidden.org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
at 
hidden.org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at 
hidden.org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at 
hidden.org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at 
hidden.org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.execute(AbstractHttpClientWagon.java:446)
at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:330)
... 24 more
[INFO] 
[INFO] Total time: 3 minutes 21 seconds
[INFO] Finished at: Wed Sep 29 10:43:14 CEST 2010
[INFO] Final Memory: 36M/65M
[INFO] 
Finished: FAILURE


On Wed, Sep 29, 2010 at 1:47 PM, Brett Porter br...@apache.org wrote:


 On 29/09/2010, at 7:51 PM, Em DauPhu wrote:

 It doesn't seem related to the MRM as I get the same error with
 Archiva or Nexus.
 Btw I already set that property and the upload via the webapp works
 fine but I don't want to do it manually.
 I could submit the form automatically

Deploy large files

2010-09-29 Thread Em DauPhu
Hi,

I have troubles deploying large artifacts (simple clean deploy).
I have the same problem deploying to Archiva and Nexus in maven 2.2.0
and 2.2.1. (We though first it was related to maven 2.2.0 with -
MNG-4236 - [regression] http wagon uploads files twice with Maven
2.2.0 when preemptive auth is disabled (default setting)).

The file is deployed correctly (on repo manager part) and can be used
but the build still fail. The upload seems going to the double of the
file size before failing on a Read timed out error (see below).
The pom file has been deployed correctly without making the build fail
right before.

Do you have any idea ? I've tried dav over Archiva but it didn't help.
Thank you very much.

[DEBUG] Connecting to repository: 'repoId' with url: 'repoUrl'.
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
[DEBUG] not adding permissions to wagon connection
Uploading: 
http://repoUrl//groupId/8.1.100.00-SNAPSHOT/artifactId-8.1.100.00-20100928.134706-4.tar.gz
4/65969K
8/65969K
12/65969K
16/65969K
20/65969K
[...]
131937/65969K
131939/65969K
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Error deploying artifact: Read timed out

[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 2 minutes 57 seconds
[INFO] Finished at: Tue Sep 28 15:49:36 CEST 2010
[INFO] Final Memory: 36M/64M
[INFO] 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: Deploy large files

2010-09-29 Thread Em DauPhu
It doesn't seem related to the MRM as I get the same error with
Archiva or Nexus.
Btw I already set that property and the upload via the webapp works
fine but I don't want to do it manually.
I could submit the form automatically as well but that's not the point. ;)

Thank you,
Em

On Wed, Sep 29, 2010 at 11:30 AM, Deng Ching och...@apache.org wrote:
 You can also upload the file from the webapp in Archiva, but you have
 to increase the max size for struts to allow larger uploads. Just
 increase the value of property struts.multipart.maxSize in
 apps/archiva/WEB-INF/classes/struts.properties. Maximum size that can
 be set is 2gb btw.

 HTH,
 Deng

 On Wed, Sep 29, 2010 at 5:01 PM, Em DauPhu emdau...@gmail.com wrote:
 Hi,

 I have troubles deploying large artifacts (simple clean deploy).
 I have the same problem deploying to Archiva and Nexus in maven 2.2.0
 and 2.2.1. (We though first it was related to maven 2.2.0 with -
 MNG-4236 - [regression] http wagon uploads files twice with Maven
 2.2.0 when preemptive auth is disabled (default setting)).

 The file is deployed correctly (on repo manager part) and can be used
 but the build still fail. The upload seems going to the double of the
 file size before failing on a Read timed out error (see below).
 The pom file has been deployed correctly without making the build fail
 right before.

 Do you have any idea ? I've tried dav over Archiva but it didn't help.
 Thank you very much.

 [DEBUG] Connecting to repository: 'repoId' with url: 'repoUrl'.
 [DEBUG] Checking for pre-existing User-Agent configuration.
 [DEBUG] Adding User-Agent configuration.
 [DEBUG] not adding permissions to wagon connection
 Uploading: 
 http://repoUrl//groupId/8.1.100.00-SNAPSHOT/artifactId-8.1.100.00-20100928.134706-4.tar.gz
 4/65969K
 8/65969K
 12/65969K
 16/65969K
 20/65969K
 [...]
 131937/65969K
 131939/65969K
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Error deploying artifact: Read timed out

 [INFO] 
 
 [INFO] For more information, run Maven with the -e switch
 [INFO] 
 
 [INFO] Total time: 2 minutes 57 seconds
 [INFO] Finished at: Tue Sep 28 15:49:36 CEST 2010
 [INFO] Final Memory: 36M/64M
 [INFO] 
 

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Mixing local repo and managed repo

2010-09-15 Thread Em DauPhu
Hi,

I came across a continuous integration server hosting both an Hudson
and an Archiva (as a proxy to our central).
The settings.xml used in maven builds declare as the local repo the
managed repository of the archiva (same directory).
Is that wrong to use as a local repository (declared in the maven
settings.xml) the actual managed repository of the repository manager?
Can it leads to any trouble (it apparently does)?

I'm about to change that anyway but I could use some explanations as
the local and remote repositories are structured the same way if it
causes any trouble.

Thank you,
Em.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: Mixing local repo and managed repo

2010-09-15 Thread Em DauPhu
Didn't know metadata were different, as I quoted from maven website:
the local and remote repositories are structured the same way.

Thank you for the great answer, couldn't expect less from an ig2k student ;)
Em.

On Wed, Sep 15, 2010 at 11:16 AM, Baptiste MATHUS m...@batmat.net wrote:
 Hi,

 Yes, first local and remote maven repository doesn't contain the same
 metadata.
 And by the way, accessing a local repository by many instances isn't
 concurrent-safe (at least, in maven 2, I don't know precisely what's been
 done for maven 3, particularly along the parallel build evolution). So, both
 must be avoided.

 You also better want to isolate every hudson build from each other, having a
 local repository by job. And wiping those jobs regularly.
 http://www.sonatype.com/people/2009/01/maven-continuous-integration-best-practices/
 http://www.sonatype.com/people/2009/01/maven-continuous-integration-best-practices/And
 a specific setting for hudson on my blog:
 http://batmat.net/blog/post/2009/10/09/[Hudson]-How-to-set-a-private-maven-repository-by-job-and-easily-be-able-to-delete-them
 .

 Cheers

 2010/9/15 Em DauPhu emdau...@gmail.com

 Hi,

 I came across a continuous integration server hosting both an Hudson
 and an Archiva (as a proxy to our central).
 The settings.xml used in maven builds declare as the local repo the
 managed repository of the archiva (same directory).
 Is that wrong to use as a local repository (declared in the maven
 settings.xml) the actual managed repository of the repository manager?
 Can it leads to any trouble (it apparently does)?

 I'm about to change that anyway but I could use some explanations as
 the local and remote repositories are structured the same way if it
 causes any trouble.

 Thank you,
 Em.

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org




 --
 Baptiste Batmat MATHUS - http://batmat.net
 Sauvez un arbre,
 Mangez un castor !


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



difference in cobertura instrumented tests

2010-07-28 Thread Em DauPhu
Hi,

I run mvn clean deploy site -U -Pcobertura,andOtherProfiles using the
profile described below.
I use the cobertura plugin version 2.3.

When I launch a job using this goals and options, tests are executed 4
times.
First question, is that correct ? (2 times with and without instrumentation
and 2 times this for deploy and site lifecycles)
Next question, my build reports for each run in order:
- during deploy lifecycle, before instrumentation
Tests run: 835, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 162.928
sec
- during deploy lifecycle, after instrumentation
Tests run: 841, Failures: 664, Errors: 0, Skipped: 20, Time elapsed: 139.084
sec  FAILURE!
- during site lifecycle, before instrumentation
Tests run: 835, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 161.537
sec
- during site lifecycle, after instrumentation
Tests run: 841, Failures: 664, Errors: 0, Skipped: 20, Time elapsed: 140.021
sec  FAILURE!

How can I investigate ? How do I have more tests while executing surefire on
instrumented tests ?

Thank you in advance.

The cobertura profile in super pom:
profile
idcobertura/id
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
configuration
check
branchRate50/branchRate
lineRate50/lineRate
haltOnFailurefalse/haltOnFailure
totalBranchRate50/totalBranchRate
totalLineRate50/totalLineRate
packageLineRate50/packageLineRate
packageBranchRate50/packageBranchRate
/check
formats
formathtml/format
formatxml/format
/formats
/configuration
executions
execution
goals
goalclean/goal
goalcheck/goal
/goals
/execution
/executions
/plugin
/plugins
/build
reporting
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version${version.cobertura.plugin}/version
configuration
formats
formathtml/format
formatxml/format
/formats
/configuration
/plugin
/plugins
/reporting
/profile


maven plugin phase binding

2010-07-26 Thread Em DauPhu
Hi,

I use a plugin which is attached to the phase validate (I want it to be
executed at the very beginning - not first but at the beginning).
I can see phasevalidate/phase in the plugin.xml descriptor.

In my maven build, it is called a lot of times (e.g. before report goal,
findbugs, cobertura, javadocs...)

Should I bind the plugin to another phase or is there something else I don't
see?
Thanks