Re: Problem with Maven deploy (Error writing to server)
Just an additional note...this fix works for Maven 2.2.1. Not sure
whether there is a way to make it work for older versions of Maven.
On Fri, Dec 11, 2009 at 5:34 PM, K J gomm...@gmail.com wrote:
Update on my solution for anyones else who has the same problem...
Thanks for the input Brendan. Although setting those properties
(maxPostSize and SSLRenegBufferSize and a few others) didn't make a
difference, I think you had the underlying cause right. The solution
that worked for me was to execute maven using a different wagon:
mvn -Dmaven.wagon.provider.http=httpclient clean install
See http://maven.apache.org/guides/mini/guide-wagon-providers.html for
more info.
On Thu, Dec 10, 2009 at 5:23 PM, Brendan Sibre bts...@gmail.com wrote:
If you're running Apache 2.2, take a look at
http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslrenegbuffersize
Essentially, it might not really be the size, it might be the size in
combination with
opening a new connection. If there is already an active SSL connection it
won't need
to be renegotiated during the post of the file. If it needs to create a new
connection
then it might fail for larger files.
Tomcat has a similar setting, maxPostSize you can set on the connector so
you might need to
set both.
This has bitten me with other similar things and it's really frustrating.
I'm not quite sure why the
client can't wait for the renegotiation to complete before sending the file.
On Thu, Dec 10, 2009 at 8:17 PM, K J gomm...@gmail.com wrote:
I have a very strange problem when I try to deploy artifacts. For
certain artifacts, the deployment fails with the message 'Error
deploying artifact: Error transferring file...Error writing to server'
(I included the stacktrace below). It appears to be related to the
size of the artifact, but here's the kicker -- the size restriction
isn't consistent acrosss artifact types. I can deploy an 11M WAR, but
can't deploy a 30M WAR. I can deploy a 96K JAR, but can't deploy a
128K JAR. (Sorry for the broad size range, I haven't had enough time
to narrow it down further).
I don't know if it's related, but I also noticed an oddity when I was
trying to narrow down the 'breaking point' for the size. I set up a
test project which deploys a jar and added images as resources to
build up the size. After passing the size threshold (which caused the
deploy to fail), I would remove the newest image and try to rebuild,
but now the deploy would fail with a 'connection reset' or 'connection
reset by peer: socket write error' message. Without making any
changes, I rerun 'mvn clean deploy' or 'mvn deploy. Most of the time
everything deploys fine; although sometimes it takes two tries before
it succeeds. For clarity, I outlined those steps below:
1.) Add image. Build and deploy fine. Size 96K.
2.) Add another image. Build fine, deploy breaks: Error writing to
server. Size 128K.
3.) Remove last image. Build fine, deploy breaks: Connection reset. Size
96K.
4.) No changes. Build and deploy fine. Size 96K.
Some additional information:
* I experience this problem using both Maven 2.0.9 and 2.2.1.
* Our repository is managed by Nexus (deployed to Tomcat with SSL from
apache). Nexus might be part of the problem, but I've checked some of
the logs, but I can't find any indication of errors on that side of
things.
* Our network uses a socks proxy (v5).
Lastly, here is the stack trace (and a bit of the Maven output):
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-deploy-plugin:2.4:deploy' --
[DEBUG] (f) artifact = com.cdmtech.icodes.ciw:test:jar:0.0.1-SNAPSHOT
[DEBUG] (f) attachedArtifacts = []
[DEBUG] (f) deploymentRepository =
Repository[snapshots|
https://hudson149/nexus/content/repositories/snapshots]
[DEBUG] (s) localRepository = Repository[local|file://C:\Documents
and Settings\kj\.m2\repository]
[DEBUG] (f) packaging = jar
[DEBUG] (f) pomFile =
C:\eclipse\eclipse-workspaces\eclipse-jee-ganymede-3.4.2\m2eclipse\ciw\test\pom.xml
[DEBUG] (f) skip = false
[DEBUG] (f) updateReleaseInfo = false
[DEBUG] -- end configuration --
[INFO] [deploy:deploy {execution: default-deploy}]
[INFO] Retrieving previous build number from snapshots
[DEBUG] Using Wagon implementation lightweight from default mapping
for protocol https
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
[DEBUG] Connecting to repository: 'snapshots' with url:
'https://hudson149/nexus/content/repositories/snapshots'.
[DEBUG] Using Wagon implementation lightweight from default mapping
for protocol https
[DEBUG] Using Wagon implementation lightweight from default mapping
for protocol https
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
[DEBUG] not adding permissions to wagon connection
Uploading:
https://hudson149/nexus/content/repositories/snapshots/ciw/test/0.0.1-SNAPSHOT/test
Re: Problem with Maven deploy (Error writing to server)
Update on my solution for anyones else who has the same problem...
Thanks for the input Brendan. Although setting those properties
(maxPostSize and SSLRenegBufferSize and a few others) didn't make a
difference, I think you had the underlying cause right. The solution
that worked for me was to execute maven using a different wagon:
mvn -Dmaven.wagon.provider.http=httpclient clean install
See http://maven.apache.org/guides/mini/guide-wagon-providers.html for
more info.
On Thu, Dec 10, 2009 at 5:23 PM, Brendan Sibre bts...@gmail.com wrote:
If you're running Apache 2.2, take a look at
http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslrenegbuffersize
Essentially, it might not really be the size, it might be the size in
combination with
opening a new connection. If there is already an active SSL connection it
won't need
to be renegotiated during the post of the file. If it needs to create a new
connection
then it might fail for larger files.
Tomcat has a similar setting, maxPostSize you can set on the connector so
you might need to
set both.
This has bitten me with other similar things and it's really frustrating.
I'm not quite sure why the
client can't wait for the renegotiation to complete before sending the file.
On Thu, Dec 10, 2009 at 8:17 PM, K J gomm...@gmail.com wrote:
I have a very strange problem when I try to deploy artifacts. For
certain artifacts, the deployment fails with the message 'Error
deploying artifact: Error transferring file...Error writing to server'
(I included the stacktrace below). It appears to be related to the
size of the artifact, but here's the kicker -- the size restriction
isn't consistent acrosss artifact types. I can deploy an 11M WAR, but
can't deploy a 30M WAR. I can deploy a 96K JAR, but can't deploy a
128K JAR. (Sorry for the broad size range, I haven't had enough time
to narrow it down further).
I don't know if it's related, but I also noticed an oddity when I was
trying to narrow down the 'breaking point' for the size. I set up a
test project which deploys a jar and added images as resources to
build up the size. After passing the size threshold (which caused the
deploy to fail), I would remove the newest image and try to rebuild,
but now the deploy would fail with a 'connection reset' or 'connection
reset by peer: socket write error' message. Without making any
changes, I rerun 'mvn clean deploy' or 'mvn deploy. Most of the time
everything deploys fine; although sometimes it takes two tries before
it succeeds. For clarity, I outlined those steps below:
1.) Add image. Build and deploy fine. Size 96K.
2.) Add another image. Build fine, deploy breaks: Error writing to
server. Size 128K.
3.) Remove last image. Build fine, deploy breaks: Connection reset. Size
96K.
4.) No changes. Build and deploy fine. Size 96K.
Some additional information:
* I experience this problem using both Maven 2.0.9 and 2.2.1.
* Our repository is managed by Nexus (deployed to Tomcat with SSL from
apache). Nexus might be part of the problem, but I've checked some of
the logs, but I can't find any indication of errors on that side of
things.
* Our network uses a socks proxy (v5).
Lastly, here is the stack trace (and a bit of the Maven output):
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-deploy-plugin:2.4:deploy' --
[DEBUG] (f) artifact = com.cdmtech.icodes.ciw:test:jar:0.0.1-SNAPSHOT
[DEBUG] (f) attachedArtifacts = []
[DEBUG] (f) deploymentRepository =
Repository[snapshots|
https://hudson149/nexus/content/repositories/snapshots]
[DEBUG] (s) localRepository = Repository[local|file://C:\Documents
and Settings\kj\.m2\repository]
[DEBUG] (f) packaging = jar
[DEBUG] (f) pomFile =
C:\eclipse\eclipse-workspaces\eclipse-jee-ganymede-3.4.2\m2eclipse\ciw\test\pom.xml
[DEBUG] (f) skip = false
[DEBUG] (f) updateReleaseInfo = false
[DEBUG] -- end configuration --
[INFO] [deploy:deploy {execution: default-deploy}]
[INFO] Retrieving previous build number from snapshots
[DEBUG] Using Wagon implementation lightweight from default mapping
for protocol https
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
[DEBUG] Connecting to repository: 'snapshots' with url:
'https://hudson149/nexus/content/repositories/snapshots'.
[DEBUG] Using Wagon implementation lightweight from default mapping
for protocol https
[DEBUG] Using Wagon implementation lightweight from default mapping
for protocol https
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
[DEBUG] not adding permissions to wagon connection
Uploading:
https://hudson149/nexus/content/repositories/snapshots/ciw/test/0.0.1-SNAPSHOT/test-0.0.1-20091210.183044-14.jar
4/128Khttps://hudson149/nexus/content/repositories/snapshots/ciw/test/0.0.1-SNAPSHOT/test-0.0.1-20091210.183044-14.jar%0A4/128K
...
128/128K
[DEBUG] Error writing to server
Problem with deploy (Error writing to server)
I have a very strange problem when I try to deploy artifacts. For
certain artifacts, the deployment fails with the message 'Error
deploying artifact: Error transferring file...Error writing to server'
(I included the stacktrace below). It appears to be related to the
size of the artifact, but here's the kicker -- the size restriction
isn't consistent acrosss artifact types. I can deploy an 11M WAR, but
can't deploy a 30M WAR. I can deploy a 96K JAR, but can't deploy a
128K JAR. (Sorry for the broad size range, I haven't had enough time
to narrow it down further).
I don't know if it's related, but I also noticed an oddity when I was
trying to narrow down the 'breaking point' for the size. I set up a
test project which deploys a jar and added images as resources to
build up the size. After passing the size threshold (which caused the
deploy to fail), I would remove the newest image and try to rebuild,
but now the deploy would fail with a 'connection reset' or 'connection
reset by peer: socket write error' message. Without making any
changes, I rerun 'mvn clean deploy' or 'mvn deploy. Most of the time
everything deploys fine; although sometimes it takes two tries before
it succeeds. For clarity, I outlined those steps below:
1.) Add image. Build and deploy fine. Size 96K.
2.) Add another image. Build fine, deploy breaks: Error writing to
server. Size 128K.
3.) Remove last image. Build fine, deploy breaks: Connection reset. Size 96K.
4.) No changes. Build and deploy fine. Size 96K.
Some additional information:
* I experience this problem using both Maven 2.0.9 and 2.2.1.
* Our repository is managed by Nexus (deployed to Tomcat with SSL from
apache). Nexus might be part of the problem, but I've checked some of
the logs, but I can't find any indication of errors on that side of
things.
* Our network uses a socks proxy (v5).
Lastly, here is the stack trace (and a bit of the Maven output):
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-deploy-plugin:2.4:deploy' --
[DEBUG] (f) artifact = com.cdmtech.icodes.ciw:test:jar:0.0.1-SNAPSHOT
[DEBUG] (f) attachedArtifacts = []
[DEBUG] (f) deploymentRepository =
Repository[snapshots|https://hudson149/nexus/content/repositories/snapshots]
[DEBUG] (s) localRepository = Repository[local|file://C:\Documents
and Settings\kj\.m2\repository]
[DEBUG] (f) packaging = jar
[DEBUG] (f) pomFile =
C:\eclipse\eclipse-workspaces\eclipse-jee-ganymede-3.4.2\m2eclipse\ciw\test\pom.xml
[DEBUG] (f) skip = false
[DEBUG] (f) updateReleaseInfo = false
[DEBUG] -- end configuration --
[INFO] [deploy:deploy {execution: default-deploy}]
[INFO] Retrieving previous build number from snapshots
[DEBUG] Using Wagon implementation lightweight from default mapping
for protocol https
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
[DEBUG] Connecting to repository: 'snapshots' with url:
'https://hudson149/nexus/content/repositories/snapshots'.
[DEBUG] Using Wagon implementation lightweight from default mapping
for protocol https
[DEBUG] Using Wagon implementation lightweight from default mapping
for protocol https
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
[DEBUG] not adding permissions to wagon connection
Uploading:
https://hudson149/nexus/content/repositories/snapshots/ciw/test/0.0.1-SNAPSHOT/test-0.0.1-20091210.183044-14.jar
4/128K
...
128/128K
[DEBUG] Error writing to server
java.io.IOException: Error writing to server
at
sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:438)
at
sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:450)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1002)
at
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:373)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at
org.apache.maven.wagon.providers.http.LightweightHttpWagon.finishPutTransfer(LightweightHttpWagon.java:185)
at
org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:413)
at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:392)
at
org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:365)
at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:163)
at
org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317)
at
org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227)
at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107)
at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:173)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
Problem with Maven deploy (Error writing to server)
I have a very strange problem when I try to deploy artifacts. For
certain artifacts, the deployment fails with the message 'Error
deploying artifact: Error transferring file...Error writing to server'
(I included the stacktrace below). It appears to be related to the
size of the artifact, but here's the kicker -- the size restriction
isn't consistent acrosss artifact types. I can deploy an 11M WAR, but
can't deploy a 30M WAR. I can deploy a 96K JAR, but can't deploy a
128K JAR. (Sorry for the broad size range, I haven't had enough time
to narrow it down further).
I don't know if it's related, but I also noticed an oddity when I was
trying to narrow down the 'breaking point' for the size. I set up a
test project which deploys a jar and added images as resources to
build up the size. After passing the size threshold (which caused the
deploy to fail), I would remove the newest image and try to rebuild,
but now the deploy would fail with a 'connection reset' or 'connection
reset by peer: socket write error' message. Without making any
changes, I rerun 'mvn clean deploy' or 'mvn deploy. Most of the time
everything deploys fine; although sometimes it takes two tries before
it succeeds. For clarity, I outlined those steps below:
1.) Add image. Build and deploy fine. Size 96K.
2.) Add another image. Build fine, deploy breaks: Error writing to
server. Size 128K.
3.) Remove last image. Build fine, deploy breaks: Connection reset. Size 96K.
4.) No changes. Build and deploy fine. Size 96K.
Some additional information:
* I experience this problem using both Maven 2.0.9 and 2.2.1.
* Our repository is managed by Nexus (deployed to Tomcat with SSL from
apache). Nexus might be part of the problem, but I've checked some of
the logs, but I can't find any indication of errors on that side of
things.
* Our network uses a socks proxy (v5).
Lastly, here is the stack trace (and a bit of the Maven output):
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-deploy-plugin:2.4:deploy' --
[DEBUG] (f) artifact = com.cdmtech.icodes.ciw:test:jar:0.0.1-SNAPSHOT
[DEBUG] (f) attachedArtifacts = []
[DEBUG] (f) deploymentRepository =
Repository[snapshots|https://hudson149/nexus/content/repositories/snapshots]
[DEBUG] (s) localRepository = Repository[local|file://C:\Documents
and Settings\kj\.m2\repository]
[DEBUG] (f) packaging = jar
[DEBUG] (f) pomFile =
C:\eclipse\eclipse-workspaces\eclipse-jee-ganymede-3.4.2\m2eclipse\ciw\test\pom.xml
[DEBUG] (f) skip = false
[DEBUG] (f) updateReleaseInfo = false
[DEBUG] -- end configuration --
[INFO] [deploy:deploy {execution: default-deploy}]
[INFO] Retrieving previous build number from snapshots
[DEBUG] Using Wagon implementation lightweight from default mapping
for protocol https
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
[DEBUG] Connecting to repository: 'snapshots' with url:
'https://hudson149/nexus/content/repositories/snapshots'.
[DEBUG] Using Wagon implementation lightweight from default mapping
for protocol https
[DEBUG] Using Wagon implementation lightweight from default mapping
for protocol https
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
[DEBUG] not adding permissions to wagon connection
Uploading:
https://hudson149/nexus/content/repositories/snapshots/ciw/test/0.0.1-SNAPSHOT/test-0.0.1-20091210.183044-14.jar
4/128K
...
128/128K
[DEBUG] Error writing to server
java.io.IOException: Error writing to server
at
sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:438)
at
sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:450)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1002)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:373)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at
org.apache.maven.wagon.providers.http.LightweightHttpWagon.finishPutTransfer(LightweightHttpWagon.java:185)
at
org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:413)
at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:392)
at
org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:365)
at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:163)
at
org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317)
at
org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227)
at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107)
at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:173)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
Re: What is the 'Maven way' to handle multi-artifact code generation from a single model source?
Thanks for the input everyone. On Thu, Dec 3, 2009 at 10:41 AM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: I wouldn't worry *too much* about the true and righteous way. While I agree that the more modular approach is more proper and allows for more flexibility, as with anything else, you need to strike a balance with building for future and practicality. With multiple modules, there comes additional complexity (that Maven arguably handles well) but if you never need the additional flexibility, then it's unnecessary. Regarding classifiers, I think they are fine if you always use them together (say same swf always goes with the same jar). I do completely agree with Maven's one primary artifact per module but depending on your case, the swf could be seen and treated as a secondary artifact, especially if you couldn't even test them separately. If you need to mix and match, perhaps have different release cycles for the swf and the jar, multiple modules is certainly better. Kalle On Wed, Dec 2, 2009 at 11:42 PM, Anders Hammar and...@hammar.net wrote: I'd like to stress that Jesse explains the true Maven way. This is how this should be done if you want to enjoy simple and correct dependency management through Maven. Using classifiers will make your two (for instance) artifacts have the same dependencies. As I've stated before, classifiers are most often NOT the way to go IMO. /Anders On Wed, Dec 2, 2009 at 22:40, Jesse Farinacci jie...@gmail.com wrote: Hi KJ, On Wed, Dec 2, 2009 at 3:19 PM, K J gomm...@gmail.com wrote: Does anyone have any examples or tips about how to handle the generation of multiple artifacts based on a shared model? For example, I have a project which needs to produce both Java and ActionScript code based on a shared UML model. I'm having trouble figuring out how to best setup and manage these types of projects, so that a change to the source project can easily result in the build of all the various generated outputs. Thanks in advance for the help. To go the real Maven way, I think that I'd probably put the shared model data (perhaps some sort of XML?) into a Maven module. Then I'd have more Maven modules for Java and ActionScript, each, that would depend on the model data module. They would use it as a dependency and then generate their source codes accordingly. -jesse - 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
What is the 'Maven way' to handle multi-artifact code generation from a single model source?
Does anyone have any examples or tips about how to handle the generation of multiple artifacts based on a shared model? For example, I have a project which needs to produce both Java and ActionScript code based on a shared UML model. I'm having trouble figuring out how to best setup and manage these types of projects, so that a change to the source project can easily result in the build of all the various generated outputs. Thanks in advance for the help. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
