Re: Maven 3.0.3 hanging / having timeouts often??
FYI: The situation described in this thread reminds me of my problem in the thread Initial Maven Install - repository download fails on large fileshttp://mail-archives.apache.org/mod_mbox/maven-users/201204.mbox/%3cCAGQXBeOOrzfe+Tw7H4zrBLXERD0Sx_or2NJ-8E6nAzMSxML=w...@mail.gmail.com%3e. It seems Windows firewall and proxies have been blamed in the past, however after I submitted my problem I have found that running in a VMWare Virtual Machine can have the same effect :). Using the same computer maven seem to handle repo download fine outside the VM, but inside VM downloads of larger files usually hangs, even if the environments are not very different: Both are Win7x64, same Java, maven and network connection. --arneT
Re: Maven 3.0.3 hanging / having timeouts often?
Thanks for the suggestion, but unfortunately the same behavior when running Maven in a Windows command-line (cmd.exe). Running mvn -X does not provide much useful information, as far as I can tell, just a timeout after around 30 minutes: [DEBUG] Using connector WagonRepositoryConnector with priority 0 for http://repo.maven.apache.org/maven2 Downloading: http://repo.maven.apache.org/maven2/org/codehaus/groovy/groovy/1.8.3/groovy-1.8.3.jar [DEBUG] Writing resolution tracking file C:\Users\Henrik Arro\.m2\repository\org\codehaus\groovy\groovy\1.8.3\groovy-1.8.3.jar.lastUpdated [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 30:02.959s [INFO] Finished at: Wed Apr 25 09:35:49 CEST 2012 [INFO] Final Memory: 10M/105M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.2:generate (default-cli) on project standalone-pom: Execution default-cli of goal org.apache.maven.plugins:maven-archetype-plugin:2.2:generate failed: Plugin o rg.apache.maven.plugins:maven-archetype-plugin:2.2 or one of its dependencies could not be resolved: Could not transfer artifact org.codehaus.groovy:groovy:jar:1.8.3 from/to central (http://repo.maven.apache.org/maven2): GET request of: org/codehaus/groovy/groovy/1.8.3/groovy-1.8.3.jar from central failed: Read timed out - [Help 1] ... Caused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:150) at java.net.SocketInputStream.read(SocketInputStream.java:121) at org.apache.maven.wagon.providers.http.httpclient.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:149) at org.apache.maven.wagon.providers.http.httpclient.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:110) at org.apache.maven.wagon.providers.http.httpclient.impl.io.AbstractSessionInputBuffer.read(AbstractSessionInputBuffer.java:195) at org.apache.maven.wagon.providers.http.httpclient.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:173) at org.apache.maven.wagon.providers.http.httpclient.conn.EofSensorInputStream.read(EofSensorInputStream.java:138) at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:238) at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158) at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:116) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:493) at org.apache.maven.wagon.AbstractWagon.getTransfer(AbstractWagon.java:339) ... 9 more Wayne Fay wrote Can you try building your projects with Maven 3.0.4 in Windows (not in the Cygwin environment) to see if there is any difference? -- View this message in context: http://maven.40175.n5.nabble.com/Maven-3-0-3-hanging-having-timeouts-often-tp4388958p5664251.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
Interesting. Do you have an example of another Java application that has network connectivity problems? Then I could try it to see if it is the combination Java / network hardware that is the culprit. Just for the record, my JAVA_HOME is C:\Program Files\Java\jdk1.7.0_03, but when I run java -version, I get java version 1.6.0_31. The computer in question is a Sony Vaio laptop, with an Atheros AR9285 wireless network adapter. /Henrik Arro martin.eisengardt wrote I got some similar problems. https://bugs.eclipse.org/bugs/show_bug.cgi?id=362418 Seems that java itself or maven or any other thing is not liking my aviara firewall or my network device. There are some other java apps that sometime have the same connection problems resulting in timeouts. Are there any hints what maven is doing (activate debug option) or can you simply wait to see if it is the same network timeout issue? -- View this message in context: http://maven.40175.n5.nabble.com/Maven-3-0-3-hanging-having-timeouts-often-tp4388958p5664491.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
Just for the record, my JAVA_HOME is C:\Program Files\Java\jdk1.7.0_03, but when I run java -version, I get java version 1.6.0_31. The computer in That simply means you have another java in your path before the jdk1.7.0_03. Perhaps there is a java.exe file in c:\windows or something like that. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven 3.0.3 hanging / having timeouts often?
Hi, You can use where java in the command line to check where your java is. -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Wednesday, April 25, 2012 9:45 PM To: Maven Users List Subject: Re: Maven 3.0.3 hanging / having timeouts often? Just for the record, my JAVA_HOME is C:\Program Files\Java\jdk1.7.0_03, but when I run java -version, I get java version 1.6.0_31. The computer in That simply means you have another java in your path before the jdk1.7.0_03. Perhaps there is a java.exe file in c:\windows or something like that. Wayne - 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
Re: Maven 3.0.3 hanging / having timeouts often?
Interesting. Do you have an example of another Java application that has network connectivity problems? Then I could try it to see if it is the combination Java / network hardware that is the culprit. Problems like this on Windows are frequently related to some antivirus or firewall (Windows or another). Try disabling your antivirus and any firewalls you may be running (including the built-in Windows firewall). If you are running this on a computer at work there can also be transparent Internet proxies (Squid) or antivirus appliances etc between your machine and the download site. This is less common at home but I know some ISPs are caching hits etc. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
Sorry for resurrecting an old thread, but I'm having the exact same problem with Maven 3.0.4 timing out while trying to download artifacts. Right now I'm running Maven from home, with no proxy. The problem also occured when I tried to use the same laptop at work, with a Nexus repository manager. I then assumed it was some kind of temporary network problem, but since I'm seeing the same thing again, I guess it must have something to do with the computer setup. I'm on Windows 7 and cygwin (CYGWIN_NT-6.1-WOW64). I have removed my ~/.m2/settings.xml to see if that made any difference -- it did not. There does not appear to be any network problem, I can download the artifacts manually (in Firefox) just fine. Anyone else seen this problem? /Henrik Arro Andrew Robinson wrote I have been using maven 2.2.1 for a while at my company and we just switched to maven 3. I have rebuilt my computer (ubuntu maverick 10.04 32-bit == ubuntu natty 11.04 64-bit) and installed maven 3. In maven 3.0.3, (I have not seen it with maven 2.2.1), it stops downloading after a few to several downloads. If I ^C the build, and keep re-running it, it will eventually built. It only dies when maven is trying to download file. It may happen before any progress is display, partial progress or full progress. -- View this message in context: http://maven.40175.n5.nabble.com/Maven-3-0-3-hanging-having-timeouts-often-tp4388958p5658520.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
I'm on Windows 7 and cygwin (CYGWIN_NT-6.1-WOW64). I have removed my ~/.m2/settings.xml to see if that made any difference -- it did not. There does not appear to be any network problem, I can download the artifacts manually (in Firefox) just fine. Can you try building your projects with Maven 3.0.4 in Windows (not in the Cygwin environment) to see if there is any difference? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
I got some similar problems. https://bugs.eclipse.org/bugs/show_bug.cgi?id=362418 Seems that java itself or maven or any other thing is not liking my aviara firewall or my network device. There are some other java apps that sometime have the same connection problems resulting in timeouts. Are there any hints what maven is doing (activate debug option) or can you simply wait to see if it is the same network timeout issue? On Mon, Apr 23, 2012 at 4:26 PM, Wayne Fay wayne...@gmail.com wrote: I'm on Windows 7 and cygwin (CYGWIN_NT-6.1-WOW64). I have removed my ~/.m2/settings.xml to see if that made any difference -- it did not. There does not appear to be any network problem, I can download the artifacts manually (in Firefox) just fine. Can you try building your projects with Maven 3.0.4 in Windows (not in the Cygwin environment) to see if there is any difference? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 Not Allowing Different Versions for Compile/Test
put the tests in a separate module and that way the module can have the alternative dependency On 21 February 2012 09:44, Daniel Jones dan...@mendeley.com wrote: Hi all, Apologies in advance if this isn't the right list to post to. Using Maven 3.0.3 and Dependency plug-in 2.4, I've encountered a strange issue whereby if I specify different versions of a dependency, one in compile scope and one in test, only one of them gets 'noticed'. I've detailed the problem on Stack Overflow (http://stackoverflow.com/questions/9364511/maven-different-dependency-version-in-test), but I'll repeat the explanation here. In my project I need to depend on a Cloudera distribution of Hadoop and a 'vanilla' version for JUnit testing, as the former only works on *nix. When I try and execute my application, I get Exception in thread main java.lang.NoClassDefFoundError: org/apache/hadoop/conf/Configuration. When I run JUnit tests from Maven or Eclipse, everything works fine. If I comment out the test dependencies, the application runs successfully, but then the tests fail because they're using the wrong version. Why is the compile dependency getting ignored when the test dependency is uncommented? dependency groupIdorg.apache.hadoop/groupId artifactIdhadoop-core/artifactId version0.20.2-cdh3u2/version scopecompile/scope /dependency dependency groupIdorg.apache.hadoop/groupId artifactIdhadoop-core/artifactId version1.0.0/version scopetest/scope /dependency dependency groupIdorg.apache.hadoop/groupId artifactIdhadoop-test/artifactId version1.0.0/version scopetest/scope /dependency mvn dependency:list shows the following, which does not show the compile scoped version at all: [INFO] The following files have been resolved: [INFO] ant:ant:jar:1.6.5:test [INFO] aopalliance:aopalliance:jar:1.0:compile [INFO] asm:asm:jar:3.3.1:compile [INFO] cglib:cglib:jar:2.2.2:compile [INFO] ch.qos.logback:logback-classic:jar:1.0.0:compile [INFO] ch.qos.logback:logback-core:jar:1.0.0:compile [INFO] com.google.guava:guava:jar:r08:compile [INFO] com.h2database:h2:jar:1.3.164:test [INFO] com.jolbox:bonecp:jar:0.7.1.RELEASE:compile [INFO] com.sun.jersey:jersey-core:jar:1.11:test [INFO] commons-beanutils:commons-beanutils:jar:1.7.0:test [INFO] commons-beanutils:commons-beanutils-core:jar:1.8.0:test [INFO] commons-cli:commons-cli:jar:1.2:test [INFO] commons-codec:commons-codec:jar:1.4:test [INFO] commons-collections:commons-collections:jar:3.2.1:test [INFO] commons-configuration:commons-configuration:jar:1.6:test [INFO] commons-digester:commons-digester:jar:1.8:test [INFO] commons-el:commons-el:jar:1.0:test [INFO] commons-httpclient:commons-httpclient:jar:3.0.1:test [INFO] commons-lang:commons-lang:jar:2.4:test [INFO] commons-logging:commons-logging:jar:1.1.1:compile [INFO] commons-net:commons-net:jar:1.4.1:test [INFO] hsqldb:hsqldb:jar:1.8.0.10:test [INFO] junit:junit:jar:4.10:test [INFO] mysql:mysql-connector-java:jar:5.1.18:compile [INFO] net.java.dev.jets3t:jets3t:jar:0.7.1:test [INFO] net.sf.kosmosfs:kfs:jar:0.3:test [INFO] org.apache.commons:commons-math:jar:2.1:test [INFO] org.apache.ftpserver:ftplet-api:jar:1.0.0:test [INFO] org.apache.ftpserver:ftpserver-core:jar:1.0.0:test [INFO] org.apache.ftpserver:ftpserver-deprecated:jar:1.0.0-M2:test [INFO] org.apache.hadoop:hadoop-core:jar:1.0.0:test [INFO] org.apache.hadoop:hadoop-test:jar:1.0.0:test [INFO] org.apache.mina:mina-core:jar:2.0.0-M5:test [INFO] org.codehaus.jackson:jackson-core-asl:jar:1.0.1:test [INFO] org.codehaus.jackson:jackson-mapper-asl:jar:1.0.1:test [INFO] org.eclipse.jdt:core:jar:3.1.1:test [INFO] org.hamcrest:hamcrest-core:jar:1.1:test [INFO] org.liquibase:liquibase-core:jar:2.0.3:test [INFO] org.liquibase.ext:liquibase-slf4j:jar:0.0.1:test [INFO] org.mortbay.jetty:jetty:jar:6.1.26:test [INFO] org.mortbay.jetty:jetty-util:jar:6.1.26:test [INFO] org.mortbay.jetty:jsp-2.1:jar:6.1.14:test [INFO] org.mortbay.jetty:jsp-api-2.1:jar:6.1.14:test [INFO] org.mortbay.jetty:servlet-api:jar:2.5-20081211:test [INFO] org.mortbay.jetty:servlet-api-2.5:jar:6.1.14:test [INFO] org.slf4j:jcl-over-slf4j:jar:1.6.4:compile [INFO] org.slf4j:log4j-over-slf4j:jar:1.6.4:compile [INFO] org.slf4j:slf4j-api:jar:1.6.4:compile [INFO] org.springframework:spring-aop:jar:3.1.1.RELEASE:compile [INFO] org.springframework:spring-asm:jar:3.1.1.RELEASE:compile [INFO] org.springframework:spring-beans:jar:3.1.1.RELEASE:compile [INFO] org.springframework:spring-context:jar:3.1.1.RELEASE:compile [INFO] org.springframework:spring-context-support:jar:3.1.1.RELEASE:compile [INFO] org.springframework:spring-core:jar:3.1.1.RELEASE:compile [INFO
Maven 3.0.3 Not Allowing Different Versions for Compile/Test
Hi all, Apologies in advance if this isn't the right list to post to. Using Maven 3.0.3 and Dependency plug-in 2.4, I've encountered a strange issue whereby if I specify different versions of a dependency, one in compile scope and one in test, only one of them gets 'noticed'. I've detailed the problem on Stack Overflow (http://stackoverflow.com/questions/9364511/maven-different-dependency-version-in-test), but I'll repeat the explanation here. In my project I need to depend on a Cloudera distribution of Hadoop and a 'vanilla' version for JUnit testing, as the former only works on *nix. When I try and execute my application, I get Exception in thread main java.lang.NoClassDefFoundError: org/apache/hadoop/conf/Configuration. When I run JUnit tests from Maven or Eclipse, everything works fine. If I comment out the test dependencies, the application runs successfully, but then the tests fail because they're using the wrong version. Why is the compile dependency getting ignored when the test dependency is uncommented? dependency groupIdorg.apache.hadoop/groupId artifactIdhadoop-core/artifactId version0.20.2-cdh3u2/version scopecompile/scope /dependency dependency groupIdorg.apache.hadoop/groupId artifactIdhadoop-core/artifactId version1.0.0/version scopetest/scope /dependency dependency groupIdorg.apache.hadoop/groupId artifactIdhadoop-test/artifactId version1.0.0/version scopetest/scope /dependency mvn dependency:list shows the following, which does not show the compile scoped version at all: [INFO] The following files have been resolved: [INFO]ant:ant:jar:1.6.5:test [INFO]aopalliance:aopalliance:jar:1.0:compile [INFO]asm:asm:jar:3.3.1:compile [INFO]cglib:cglib:jar:2.2.2:compile [INFO]ch.qos.logback:logback-classic:jar:1.0.0:compile [INFO]ch.qos.logback:logback-core:jar:1.0.0:compile [INFO]com.google.guava:guava:jar:r08:compile [INFO]com.h2database:h2:jar:1.3.164:test [INFO]com.jolbox:bonecp:jar:0.7.1.RELEASE:compile [INFO]com.sun.jersey:jersey-core:jar:1.11:test [INFO]commons-beanutils:commons-beanutils:jar:1.7.0:test [INFO]commons-beanutils:commons-beanutils-core:jar:1.8.0:test [INFO]commons-cli:commons-cli:jar:1.2:test [INFO]commons-codec:commons-codec:jar:1.4:test [INFO]commons-collections:commons-collections:jar:3.2.1:test [INFO]commons-configuration:commons-configuration:jar:1.6:test [INFO]commons-digester:commons-digester:jar:1.8:test [INFO]commons-el:commons-el:jar:1.0:test [INFO]commons-httpclient:commons-httpclient:jar:3.0.1:test [INFO]commons-lang:commons-lang:jar:2.4:test [INFO]commons-logging:commons-logging:jar:1.1.1:compile [INFO]commons-net:commons-net:jar:1.4.1:test [INFO]hsqldb:hsqldb:jar:1.8.0.10:test [INFO]junit:junit:jar:4.10:test [INFO]mysql:mysql-connector-java:jar:5.1.18:compile [INFO]net.java.dev.jets3t:jets3t:jar:0.7.1:test [INFO]net.sf.kosmosfs:kfs:jar:0.3:test [INFO]org.apache.commons:commons-math:jar:2.1:test [INFO]org.apache.ftpserver:ftplet-api:jar:1.0.0:test [INFO]org.apache.ftpserver:ftpserver-core:jar:1.0.0:test [INFO]org.apache.ftpserver:ftpserver-deprecated:jar:1.0.0-M2:test [INFO]org.apache.hadoop:hadoop-core:jar:1.0.0:test [INFO]org.apache.hadoop:hadoop-test:jar:1.0.0:test [INFO]org.apache.mina:mina-core:jar:2.0.0-M5:test [INFO]org.codehaus.jackson:jackson-core-asl:jar:1.0.1:test [INFO]org.codehaus.jackson:jackson-mapper-asl:jar:1.0.1:test [INFO]org.eclipse.jdt:core:jar:3.1.1:test [INFO]org.hamcrest:hamcrest-core:jar:1.1:test [INFO]org.liquibase:liquibase-core:jar:2.0.3:test [INFO]org.liquibase.ext:liquibase-slf4j:jar:0.0.1:test [INFO]org.mortbay.jetty:jetty:jar:6.1.26:test [INFO]org.mortbay.jetty:jetty-util:jar:6.1.26:test [INFO]org.mortbay.jetty:jsp-2.1:jar:6.1.14:test [INFO]org.mortbay.jetty:jsp-api-2.1:jar:6.1.14:test [INFO]org.mortbay.jetty:servlet-api:jar:2.5-20081211:test [INFO]org.mortbay.jetty:servlet-api-2.5:jar:6.1.14:test [INFO]org.slf4j:jcl-over-slf4j:jar:1.6.4:compile [INFO]org.slf4j:log4j-over-slf4j:jar:1.6.4:compile [INFO]org.slf4j:slf4j-api:jar:1.6.4:compile [INFO]org.springframework:spring-aop:jar:3.1.1.RELEASE:compile [INFO]org.springframework:spring-asm:jar:3.1.1.RELEASE:compile [INFO]org.springframework:spring-beans:jar:3.1.1.RELEASE:compile [INFO]org.springframework:spring-context:jar:3.1.1.RELEASE:compile [INFO]org.springframework:spring-context-support:jar:3.1.1.RELEASE:compile [INFO]org.springframework:spring-core:jar:3.1.1.RELEASE:compile [INFO]org.springframework:spring-expression:jar:3.1.1.RELEASE:compile [INFO]org.springframework:spring-jdbc:jar:3.1.1.RELEASE:compile [INFO]org.springframework:spring-test:jar:3.1.1.RELEASE:test [INFO]org.springframework:spring-tx:jar:3.1.1
Re: Maven 3.0.3 Not Allowing Different Versions for Compile/Test
Hi Daniel, Daniel Jones wrote: Hi all, Apologies in advance if this isn't the right list to post to. Using Maven 3.0.3 and Dependency plug-in 2.4, I've encountered a strange issue whereby if I specify different versions of a dependency, one in compile scope and one in test, only one of them gets 'noticed'. I've detailed the problem on Stack Overflow (http://stackoverflow.com/questions/9364511/maven-different-dependency- version-in-test), but I'll repeat the explanation here. In my project I need to depend on a Cloudera distribution of Hadoop and a 'vanilla' version for JUnit testing, as the former only works on *nix. When I try and execute my application, I get Exception in thread main java.lang.NoClassDefFoundError: org/apache/hadoop/conf/Configuration. When I run JUnit tests from Maven or Eclipse, everything works fine. If I comment out the test dependencies, the application runs successfully, but then the tests fail because they're using the wrong version. Why is the compile dependency getting ignored when the test dependency is uncommented? dependency groupIdorg.apache.hadoop/groupId artifactIdhadoop-core/artifactId version0.20.2-cdh3u2/version scopecompile/scope /dependency dependency groupIdorg.apache.hadoop/groupId artifactIdhadoop-core/artifactId version1.0.0/version scopetest/scope /dependency dependency groupIdorg.apache.hadoop/groupId artifactIdhadoop-test/artifactId version1.0.0/version scopetest/scope /dependency mvn dependency:list shows the following, which does not show the compile scoped version at all: [INFO] The following files have been resolved: [INFO]ant:ant:jar:1.6.5:test [INFO]aopalliance:aopalliance:jar:1.0:compile [INFO]asm:asm:jar:3.3.1:compile [INFO]cglib:cglib:jar:2.2.2:compile [INFO]ch.qos.logback:logback-classic:jar:1.0.0:compile [INFO]ch.qos.logback:logback-core:jar:1.0.0:compile [INFO]com.google.guava:guava:jar:r08:compile [INFO]com.h2database:h2:jar:1.3.164:test [INFO]com.jolbox:bonecp:jar:0.7.1.RELEASE:compile [INFO]com.sun.jersey:jersey-core:jar:1.11:test [INFO]commons-beanutils:commons-beanutils:jar:1.7.0:test [INFO]commons-beanutils:commons-beanutils-core:jar:1.8.0:test [INFO]commons-cli:commons-cli:jar:1.2:test [INFO]commons-codec:commons-codec:jar:1.4:test [INFO]commons-collections:commons-collections:jar:3.2.1:test [INFO]commons-configuration:commons-configuration:jar:1.6:test [INFO]commons-digester:commons-digester:jar:1.8:test [INFO]commons-el:commons-el:jar:1.0:test [INFO]commons-httpclient:commons-httpclient:jar:3.0.1:test [INFO]commons-lang:commons-lang:jar:2.4:test [INFO]commons-logging:commons-logging:jar:1.1.1:compile [INFO]commons-net:commons-net:jar:1.4.1:test [INFO]hsqldb:hsqldb:jar:1.8.0.10:test [INFO]junit:junit:jar:4.10:test [INFO]mysql:mysql-connector-java:jar:5.1.18:compile [INFO]net.java.dev.jets3t:jets3t:jar:0.7.1:test [INFO]net.sf.kosmosfs:kfs:jar:0.3:test [INFO]org.apache.commons:commons-math:jar:2.1:test [INFO]org.apache.ftpserver:ftplet-api:jar:1.0.0:test [INFO]org.apache.ftpserver:ftpserver-core:jar:1.0.0:test [INFO]org.apache.ftpserver:ftpserver-deprecated:jar:1.0.0-M2:test [INFO]org.apache.hadoop:hadoop-core:jar:1.0.0:test [INFO]org.apache.hadoop:hadoop-test:jar:1.0.0:test [INFO]org.apache.mina:mina-core:jar:2.0.0-M5:test [INFO]org.codehaus.jackson:jackson-core-asl:jar:1.0.1:test [INFO]org.codehaus.jackson:jackson-mapper-asl:jar:1.0.1:test [INFO]org.eclipse.jdt:core:jar:3.1.1:test [INFO]org.hamcrest:hamcrest-core:jar:1.1:test [INFO]org.liquibase:liquibase-core:jar:2.0.3:test [INFO]org.liquibase.ext:liquibase-slf4j:jar:0.0.1:test [INFO]org.mortbay.jetty:jetty:jar:6.1.26:test [INFO]org.mortbay.jetty:jetty-util:jar:6.1.26:test [INFO]org.mortbay.jetty:jsp-2.1:jar:6.1.14:test [INFO]org.mortbay.jetty:jsp-api-2.1:jar:6.1.14:test [INFO]org.mortbay.jetty:servlet-api:jar:2.5-20081211:test [INFO]org.mortbay.jetty:servlet-api-2.5:jar:6.1.14:test [INFO]org.slf4j:jcl-over-slf4j:jar:1.6.4:compile [INFO]org.slf4j:log4j-over-slf4j:jar:1.6.4:compile [INFO]org.slf4j:slf4j-api:jar:1.6.4:compile [INFO]org.springframework:spring-aop:jar:3.1.1.RELEASE:compile [INFO]org.springframework:spring-asm:jar:3.1.1.RELEASE:compile [INFO]org.springframework:spring-beans:jar:3.1.1.RELEASE:compile [INFO]org.springframework:spring-context:jar:3.1.1.RELEASE:compile [INFO] [org.springframework:spring-context-support:jar:3.1.1.RELEASE:compile [INFO]org.springframework:spring-core:jar:3.1.1.RELEASE:compile [INFO]org.springframework:spring-expression:jar:3.1.1.RELEASE:compile [INFO]org.springframework:spring-jdbc:jar:3.1.1
Re: Maven 3.0.3, Classifier, maven-metadata.xml, versioningSnapshot, and TeamCity
artifactIdE/artifactId version4.0-SNAPSHOT/version versioning snapshot buildNumber325/buildNumber timestamp20111205.181820/timestamp /snapshot lastUpdated20111205181820/lastUpdated /versioning /metadata Good maven-metadata.xml: metadata modelVersion=1.1.0 groupIdcom.foo/groupId artifactIdD/artifactId version4.0-SNAPSHOT/version versioning snapshot timestamp20111205.200259/timestamp buildNumber328/buildNumber /snapshot lastUpdated20111205200259/lastUpdated snapshotVersions snapshotVersion extensionpom/extension value4.0-20111205.200259-328/value updated20111205200259/updated /snapshotVersion snapshotVersion classifierlinux/classifier extensionjar/extension value4.0-20111205.200259-328/value updated20111205200259/updated /snapshotVersion snapshotVersion classifiertests/classifier extensionjar/extension value4.0-20111205.200259-328/value updated20111205200259/updated /snapshotVersion /snapshotVersions /versioning /metadata I have tried giving each TeamCity build agent their own private maven repository and even private apache mvn executable. Any help, guidance, or advice is greatly appreciated. We are using maven 3.0.3, CentOS for linux and Win2003 both 64-bit and JDK 1.6_30. We deploy from all our build agents with mvn clean deploy. With the C project we specify the pom to be C's pom file since TeamCity cannot checkout the A directory and cd into the C directory and then issue the deploy command. Cheers from Florida, Jason - 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
Maven 3.0.3, Classifier, maven-metadata.xml, versioningSnapshot, and TeamCity
classifiertests/classifier extensionjar/extension value4.0-20111205.200259-328/value updated20111205200259/updated /snapshotVersion /snapshotVersions /versioning /metadata I have tried giving each TeamCity build agent their own private maven repository and even private apache mvn executable. Any help, guidance, or advice is greatly appreciated. We are using maven 3.0.3, CentOS for linux and Win2003 both 64-bit and JDK 1.6_30. We deploy from all our build agents with mvn clean deploy. With the C project we specify the pom to be C's pom file since TeamCity cannot checkout the A directory and cd into the C directory and then issue the deploy command. Cheers from Florida, Jason - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven 3.0.3 generated different runtime classpath with the same POM
I'm upgrading Maven from 2.2.1 to 3.0.3, it BUILD SUCCESS. However the runtime classpath(xxx.war \WEB-INF\lib) are generated differently. Ex. We defined version 3.2.1.ga for hibernate-annotations, Maven2.2.1 generates version as it's defined 3.2.1.ga.jar. However Maven 3.0.3 generated version 3.3.1.ga.jar and also a lot of more jars like titles-*.jar, spring-ldap-*.jar, ojdbc-14.jar Those are not generated by Maven 2.2.1 . I'm using the same POM , means the same version( 2.1.1) for maven-war-plugin. -Julie
Re: Maven 3.0.3 generated different runtime classpath with the same POM
You can try doing 'mvn dependency:tree' to look at the artifact resolution tree with both versions. On Tue, Jan 31, 2012 at 10:57 AM, Julie Chi julie@so.mnscu.edu wrote: I'm upgrading Maven from 2.2.1 to 3.0.3, it BUILD SUCCESS. However the runtime classpath(xxx.war \WEB-INF\lib) are generated differently. Ex. We defined version 3.2.1.ga for hibernate-annotations, Maven2.2.1 generates version as it's defined 3.2.1.ga.jar. However Maven 3.0.3 generated version 3.3.1.ga.jar and also a lot of more jars like titles-*.jar, spring-ldap-*.jar, ojdbc-14.jar Those are not generated by Maven 2.2.1 . I'm using the same POM , means the same version( 2.1.1) for maven-war-plugin. -Julie -- Those who do not understand Unix are condemned to reinvent it, poorly. Any sufficiently recent Microsoft OS contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Unix.
Re: Maven 3.0.3 generated different runtime classpath with the same POM
Sebastian Otaegui wrote: You can try doing 'mvn dependency:tree' to look at the artifact resolution tree with both versions. This does not help, since the plugin uses a dependency resolution algorithm similar to M2. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 generated different runtime classpath with the same POM
Can you post your pom? On Feb 1, 2012 1:15 AM, Jörg Schaible joerg.schai...@scalaris.com wrote: Sebastian Otaegui wrote: You can try doing 'mvn dependency:tree' to look at the artifact resolution tree with both versions. This does not help, since the plugin uses a dependency resolution algorithm similar to M2. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
Gaah! I just managed to waste an hour hunting down an issue with a suddenly failing release after a parent of a parent was changed to use version 2.2.2 of the release plugin. The worst is that I now recall I saw this thread a week ago. Kalle On Tue, Jan 3, 2012 at 1:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: that is because you are using maven-release-plugin 2.2.1 switch to 2.2.2 and see how you feel - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 3 Jan 2012 20:58, Jesse Farinacci jie...@gmail.com wrote: Greetings, On Tue, Jan 3, 2012 at 3:45 PM, Mark Derricutt m...@talios.com wrote: Surely something as egregious as allowing releases to break should block 3.0.4 from being released tho. As someone who uses GPG in that manner for some of his releases I'd certainly want 3.0.4 to be able to release... It didn't stop the 3.0.3 release, what's the difference with 3.0.4? It's getting rather frustrating at seeing all these relatively solitary or edge-case problems derail the entire release process. I have performed many releases with 3.0.3 and 3.0.4-rcX both, so this is not a problem for me, and I dare say it's a very large majority of users that it is also not a problem for. Stop stopping the presses, please!! It's just a stupid point release! It doesn't have to solve every existing MNG-* out there! This kind of localized Chicken Little behavior is making it harder and harder to get small releases out the door. You're making it worse for all users. *sigh* (the same goes for all the bike shedding whiners about the dependency fetch timeout - you know who you are) -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
Hi, I just found a regression: http://jira.codehaus.org/browse/MNG-5224 I think it is serious enough to recommend users avoid using the above combination if you rely on properties in a settings.xml profile to GPG sign your releases. (i.e. anyone pushing to Central) -Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
Is this still broken under the 3.0.4-RC4 builds, or just 3.0.3? -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Wed, Jan 4, 2012 at 4:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Hi, I just found a regression: http://jira.codehaus.org/browse/MNG-5224 I think it is serious enough to recommend users avoid using the above combination if you rely on properties in a settings.xml profile to GPG sign your releases. (i.e. anyone pushing to Central) -Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
I have checked in a fix towards 3.0.5... Pester olamy to backport... though he may want to wait for me to write the tests of the fix (manual testing confirms the fix... just have to figure out how to get automated testing!) On 3 January 2012 16:03, Mark Derricutt m...@talios.com wrote: Is this still broken under the 3.0.4-RC4 builds, or just 3.0.3? -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Wed, Jan 4, 2012 at 4:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Hi, I just found a regression: http://jira.codehaus.org/browse/MNG-5224 I think it is serious enough to recommend users avoid using the above combination if you rely on properties in a settings.xml profile to GPG sign your releases. (i.e. anyone pushing to Central) -Stephen - 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
Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
Surely something as egregious as allowing releases to break should block 3.0.4 from being released tho. As someone who uses GPG in that manner for some of his releases I'd certainly want 3.0.4 to be able to release... -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Wed, Jan 4, 2012 at 5:23 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have checked in a fix towards 3.0.5... Pester olamy to backport... though he may want to wait for me to write the tests of the fix (manual testing confirms the fix... just have to figure out how to get automated testing!) On 3 January 2012 16:03, Mark Derricutt m...@talios.com wrote: Is this still broken under the 3.0.4-RC4 builds, or just 3.0.3? -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Wed, Jan 4, 2012 at 4:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Hi, I just found a regression: http://jira.codehaus.org/browse/MNG-5224 I think it is serious enough to recommend users avoid using the above combination if you rely on properties in a settings.xml profile to GPG sign your releases. (i.e. anyone pushing to Central) -Stephen - 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
Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
it all depends on whether olamy decides as RM to backport or not. he is RM for the 3.0.4 release by virtue of action. On Tuesday, 3 January 2012, Mark Derricutt m...@talios.com wrote: Surely something as egregious as allowing releases to break should block 3.0.4 from being released tho. As someone who uses GPG in that manner for some of his releases I'd certainly want 3.0.4 to be able to release... -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Wed, Jan 4, 2012 at 5:23 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have checked in a fix towards 3.0.5... Pester olamy to backport... though he may want to wait for me to write the tests of the fix (manual testing confirms the fix... just have to figure out how to get automated testing!) On 3 January 2012 16:03, Mark Derricutt m...@talios.com wrote: Is this still broken under the 3.0.4-RC4 builds, or just 3.0.3? -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Wed, Jan 4, 2012 at 4:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Hi, I just found a regression: http://jira.codehaus.org/browse/MNG-5224 I think it is serious enough to recommend users avoid using the above combination if you rely on properties in a settings.xml profile to GPG sign your releases. (i.e. anyone pushing to Central) -Stephen - 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
Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
Greetings, On Tue, Jan 3, 2012 at 3:45 PM, Mark Derricutt m...@talios.com wrote: Surely something as egregious as allowing releases to break should block 3.0.4 from being released tho. As someone who uses GPG in that manner for some of his releases I'd certainly want 3.0.4 to be able to release... It didn't stop the 3.0.3 release, what's the difference with 3.0.4? It's getting rather frustrating at seeing all these relatively solitary or edge-case problems derail the entire release process. I have performed many releases with 3.0.3 and 3.0.4-rcX both, so this is not a problem for me, and I dare say it's a very large majority of users that it is also not a problem for. Stop stopping the presses, please!! It's just a stupid point release! It doesn't have to solve every existing MNG-* out there! This kind of localized Chicken Little behavior is making it harder and harder to get small releases out the door. You're making it worse for all users. *sigh* (the same goes for all the bike shedding whiners about the dependency fetch timeout - you know who you are) -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not.
Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
Not only properties like I explained it here : http://jira.codehaus.org/browse/MRELEASE-724 Arnaud On Tue, Jan 3, 2012 at 4:18 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Hi, I just found a regression: http://jira.codehaus.org/browse/MNG-5224 I think it is serious enough to recommend users avoid using the above combination if you rely on properties in a settings.xml profile to GPG sign your releases. (i.e. anyone pushing to Central) -Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
that is because you are using maven-release-plugin 2.2.1 switch to 2.2.2 and see how you feel - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 3 Jan 2012 20:58, Jesse Farinacci jie...@gmail.com wrote: Greetings, On Tue, Jan 3, 2012 at 3:45 PM, Mark Derricutt m...@talios.com wrote: Surely something as egregious as allowing releases to break should block 3.0.4 from being released tho. As someone who uses GPG in that manner for some of his releases I'd certainly want 3.0.4 to be able to release... It didn't stop the 3.0.3 release, what's the difference with 3.0.4? It's getting rather frustrating at seeing all these relatively solitary or edge-case problems derail the entire release process. I have performed many releases with 3.0.3 and 3.0.4-rcX both, so this is not a problem for me, and I dare say it's a very large majority of users that it is also not a problem for. Stop stopping the presses, please!! It's just a stupid point release! It doesn't have to solve every existing MNG-* out there! This kind of localized Chicken Little behavior is making it harder and harder to get small releases out the door. You're making it worse for all users. *sigh* (the same goes for all the bike shedding whiners about the dependency fetch timeout - you know who you are) -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not.
Is there a way to specify the local repo in command line for Maven 3.0.3?
I used to use -Dmaven.repo.local option, but seems it does not work for maven 3.0.3, is it still supported or replaced by something else? Appreciate any help! -- Thanks! Regards, Forrest
Re: Is there a way to specify the local repo in command line for Maven 3.0.3?
Hi, I used to use -Dmaven.repo.local option, but seems it does not work for maven 3.0.3, is it still supported or replaced by something else? Appreciate any help! What exactly does not work ? Error messages ? This is the option or better the property to define a different local repository instead the default $HOME/.m2/repository ... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there a way to specify the local repo in command line for Maven 3.0.3?
It works for me with Maven 3.0.3. /Anders On Fri, Dec 23, 2011 at 17:11, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, I used to use -Dmaven.repo.local option, but seems it does not work for maven 3.0.3, is it still supported or replaced by something else? Appreciate any help! What exactly does not work ? Error messages ? This is the option or better the property to define a different local repository instead the default $HOME/.m2/repository ... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - 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
RE: Maven 3.0.3: Problems with SNAPSHOT updates
Hello! Thanks everyone, I'll try this Artifactory change as soon as our Artifactory guru is back from vacation! Regards, Ruediger -Original Message- From: Patrick Sansoucy [mailto:patrick.sanso...@gmail.com] Sent: Friday, 21 October, 2011 12:37 To: Maven Users List Subject: Re: Maven 3.0.3: Problems with SNAPSHOT updates I always refer people to this Jira ... http://jira.codehaus.org/browse/MNG- 5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel But Brian's post explains it very well. Patrick Sansoucy In theory, there is no difference between theory and practice, but in practice, there is ... On Fri, Oct 21, 2011 at 6:29 AM, Brian Parker onebrianpar...@gmail.com wrote: I ran in to this. See http://stackoverflow.com/questions/5249342/maven-3-0-2-u-option- does-n ot-update-snapshot/7081166#7081166 Brian On Fri, Oct 21, 2011 at 5:13 AM, Dreier Ruediger ruediger.dre...@bdal.dewrote: Hello! Thanks for your answer, but both solutions do not work for me with Maven 3 - both work perfectly with Maven 2.2.1. With Maven 3 only a metadata file is updated, not the artifact itself. Regards, Ruediger -Original Message- From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com] Sent: Thursday, 20 October, 2011 17:09 To: Maven Users List Subject: RE: Maven 3.0.3: Problems with SNAPSHOT updates There are two ways. You can force maven to update snapshot by using the - U option. Ie: mvn -U install Or you can change when maven updates snapshots by default by changing the updatePolicy in your settings.xml file. http://maven.apache.org/ref/3.0.3/maven-settings/settings.html -Original Message- From: Dreier Ruediger [mailto:ruediger.dre...@bdal.de] Sent: Thursday, October 20, 2011 11:02 AM To: 'users@maven.apache.org' Subject: Maven 3.0.3: Problems with SNAPSHOT updates Hello! We are currently using Maven 2.2.1 and Artifactory 2.3.4 (rev. 13017) as repository server and I am now evaluating if we can migrate to Maven 3. I am testing Maven 3 in the following environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Java version: 1.6.0_26, vendor: Sun Microsystems Inc. Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: x86, family: windows I used a very simple POM file for this check: dependencies dependency groupIdde.bdal.common.bcl/groupId artifactIdsettings/artifactId version0.0.0.1-SNAPSHOT/version classifierbinaries/classifier typezip/type /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.2/version executions execution phaseprocess-resources/phase goals goalunpack-dependencies/goal /goals configuration copyPomtrue/copyPom outputDirectory./target/references/outputDirectory /configuration /execution /executions /plugin /plugins /build On a second PC (our Jenkins build system, still using Maven 2.2.1) the project de.bdal.common.bcl:settings can be build. With an empty local repository, everything works well: 'mvn install' downloads the newest version of de.bdal.common.bcl:settings to my local repository and the dependency plugin extracts it. Then I use Jenkins on the build system to create a new SNAPSHOT build of de.bdal.common.bcl:settings. Now I try to use this new version: 'mvn -U install' only downloads metadata: Downloading: http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1- SNAPSHOT/maven-metadata.xml Downloaded: http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1- SNAPSHOT/maven-metadata.xml (319 B at 4.0 KB/sec) and my local repository contains updated files maven-metadata- inhouse.xml, maven-metadata-inhouse.xml.sha1 and resolver- status.properties. But all other files are not changed (especially settings-0.0.0.1-SNAPSHOT-binaries.zip is not updated). However maven- metadata-inhouse.xml contains the correct value for lastUpdate (build time on the server). What am I doing wrong? How do I get updates of snapshot dependencies without deleting my local repository? Thanks for any help, i.A. Rüdiger Dreier Project Manager Bruker Daltonik GmbH Fahrenheitstr. 4 28359 Bremen, Germany Phone: +49 421 2205-393 Fax: +49 421 2205-3005 ruediger.dre...@bdal.demailto:ruediger.dre
RE: Maven 3.0.3: Problems with SNAPSHOT updates
Hello! Thanks for your answer, but both solutions do not work for me with Maven 3 - both work perfectly with Maven 2.2.1. With Maven 3 only a metadata file is updated, not the artifact itself. Regards, Ruediger -Original Message- From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com] Sent: Thursday, 20 October, 2011 17:09 To: Maven Users List Subject: RE: Maven 3.0.3: Problems with SNAPSHOT updates There are two ways. You can force maven to update snapshot by using the - U option. Ie: mvn -U install Or you can change when maven updates snapshots by default by changing the updatePolicy in your settings.xml file. http://maven.apache.org/ref/3.0.3/maven-settings/settings.html -Original Message- From: Dreier Ruediger [mailto:ruediger.dre...@bdal.de] Sent: Thursday, October 20, 2011 11:02 AM To: 'users@maven.apache.org' Subject: Maven 3.0.3: Problems with SNAPSHOT updates Hello! We are currently using Maven 2.2.1 and Artifactory 2.3.4 (rev. 13017) as repository server and I am now evaluating if we can migrate to Maven 3. I am testing Maven 3 in the following environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Java version: 1.6.0_26, vendor: Sun Microsystems Inc. Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: x86, family: windows I used a very simple POM file for this check: dependencies dependency groupIdde.bdal.common.bcl/groupId artifactIdsettings/artifactId version0.0.0.1-SNAPSHOT/version classifierbinaries/classifier typezip/type /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.2/version executions execution phaseprocess-resources/phase goals goalunpack-dependencies/goal /goals configuration copyPomtrue/copyPom outputDirectory./target/references/outputDirectory /configuration /execution /executions /plugin /plugins /build On a second PC (our Jenkins build system, still using Maven 2.2.1) the project de.bdal.common.bcl:settings can be build. With an empty local repository, everything works well: 'mvn install' downloads the newest version of de.bdal.common.bcl:settings to my local repository and the dependency plugin extracts it. Then I use Jenkins on the build system to create a new SNAPSHOT build of de.bdal.common.bcl:settings. Now I try to use this new version: 'mvn -U install' only downloads metadata: Downloading: http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1- SNAPSHOT/maven-metadata.xml Downloaded: http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1- SNAPSHOT/maven-metadata.xml (319 B at 4.0 KB/sec) and my local repository contains updated files maven-metadata- inhouse.xml, maven-metadata-inhouse.xml.sha1 and resolver- status.properties. But all other files are not changed (especially settings-0.0.0.1-SNAPSHOT-binaries.zip is not updated). However maven- metadata-inhouse.xml contains the correct value for lastUpdate (build time on the server). What am I doing wrong? How do I get updates of snapshot dependencies without deleting my local repository? Thanks for any help, i.A. Rüdiger Dreier Project Manager Bruker Daltonik GmbH Fahrenheitstr. 4 28359 Bremen, Germany Phone: +49 421 2205-393 Fax: +49 421 2205-3005 ruediger.dre...@bdal.demailto:ruediger.dre...@bdal.de www.bruker.comhttp://www.bruker.com/ Sitz der Gesellschaft / Registered Office Bremen; Handelsregister Amtsgericht Bremen HRB 8150 / Commercial Register District Court Bremen HRB 8150; Geschäftsführer / Managing Directors: Frank Laukien, Ph. D., Gerd Hülso, Sebastian Meyer-Plath, Stefan Ruge, Ian Sanders, Ph. D., Dr. Michael Schubert Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich für die ordnungsgemäße, vollständige und verzögerungsfreie Übertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend bestätigt wird. Disclaimer: Bruker Daltonik GmbH is not responsible for correct, complete and timely transmission of this message. The content of this e-mail, including any attachments, is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax
Re: Maven 3.0.3: Problems with SNAPSHOT updates
I ran in to this. See http://stackoverflow.com/questions/5249342/maven-3-0-2-u-option-does-not-update-snapshot/7081166#7081166 Brian On Fri, Oct 21, 2011 at 5:13 AM, Dreier Ruediger ruediger.dre...@bdal.dewrote: Hello! Thanks for your answer, but both solutions do not work for me with Maven 3 - both work perfectly with Maven 2.2.1. With Maven 3 only a metadata file is updated, not the artifact itself. Regards, Ruediger -Original Message- From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com] Sent: Thursday, 20 October, 2011 17:09 To: Maven Users List Subject: RE: Maven 3.0.3: Problems with SNAPSHOT updates There are two ways. You can force maven to update snapshot by using the - U option. Ie: mvn -U install Or you can change when maven updates snapshots by default by changing the updatePolicy in your settings.xml file. http://maven.apache.org/ref/3.0.3/maven-settings/settings.html -Original Message- From: Dreier Ruediger [mailto:ruediger.dre...@bdal.de] Sent: Thursday, October 20, 2011 11:02 AM To: 'users@maven.apache.org' Subject: Maven 3.0.3: Problems with SNAPSHOT updates Hello! We are currently using Maven 2.2.1 and Artifactory 2.3.4 (rev. 13017) as repository server and I am now evaluating if we can migrate to Maven 3. I am testing Maven 3 in the following environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Java version: 1.6.0_26, vendor: Sun Microsystems Inc. Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: x86, family: windows I used a very simple POM file for this check: dependencies dependency groupIdde.bdal.common.bcl/groupId artifactIdsettings/artifactId version0.0.0.1-SNAPSHOT/version classifierbinaries/classifier typezip/type /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.2/version executions execution phaseprocess-resources/phase goals goalunpack-dependencies/goal /goals configuration copyPomtrue/copyPom outputDirectory./target/references/outputDirectory /configuration /execution /executions /plugin /plugins /build On a second PC (our Jenkins build system, still using Maven 2.2.1) the project de.bdal.common.bcl:settings can be build. With an empty local repository, everything works well: 'mvn install' downloads the newest version of de.bdal.common.bcl:settings to my local repository and the dependency plugin extracts it. Then I use Jenkins on the build system to create a new SNAPSHOT build of de.bdal.common.bcl:settings. Now I try to use this new version: 'mvn -U install' only downloads metadata: Downloading: http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1- SNAPSHOT/maven-metadata.xml Downloaded: http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1- SNAPSHOT/maven-metadata.xml (319 B at 4.0 KB/sec) and my local repository contains updated files maven-metadata- inhouse.xml, maven-metadata-inhouse.xml.sha1 and resolver- status.properties. But all other files are not changed (especially settings-0.0.0.1-SNAPSHOT-binaries.zip is not updated). However maven- metadata-inhouse.xml contains the correct value for lastUpdate (build time on the server). What am I doing wrong? How do I get updates of snapshot dependencies without deleting my local repository? Thanks for any help, i.A. Rüdiger Dreier Project Manager Bruker Daltonik GmbH Fahrenheitstr. 4 28359 Bremen, Germany Phone: +49 421 2205-393 Fax: +49 421 2205-3005 ruediger.dre...@bdal.demailto:ruediger.dre...@bdal.de www.bruker.comhttp://www.bruker.com/ Sitz der Gesellschaft / Registered Office Bremen; Handelsregister Amtsgericht Bremen HRB 8150 / Commercial Register District Court Bremen HRB 8150; Geschäftsführer / Managing Directors: Frank Laukien, Ph. D., Gerd Hülso, Sebastian Meyer-Plath, Stefan Ruge, Ian Sanders, Ph. D., Dr. Michael Schubert Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich für die ordnungsgemäße, vollständige und verzögerungsfreie Übertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend bestätigt wird. Disclaimer: Bruker Daltonik GmbH is not responsible for correct, complete and timely transmission of this message. The content of this e-mail, including any
Re: Maven 3.0.3: Problems with SNAPSHOT updates
I always refer people to this Jira ... http://jira.codehaus.org/browse/MNG-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel But Brian's post explains it very well. Patrick Sansoucy In theory, there is no difference between theory and practice, but in practice, there is ... On Fri, Oct 21, 2011 at 6:29 AM, Brian Parker onebrianpar...@gmail.com wrote: I ran in to this. See http://stackoverflow.com/questions/5249342/maven-3-0-2-u-option-does-not-update-snapshot/7081166#7081166 Brian On Fri, Oct 21, 2011 at 5:13 AM, Dreier Ruediger ruediger.dre...@bdal.dewrote: Hello! Thanks for your answer, but both solutions do not work for me with Maven 3 - both work perfectly with Maven 2.2.1. With Maven 3 only a metadata file is updated, not the artifact itself. Regards, Ruediger -Original Message- From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com] Sent: Thursday, 20 October, 2011 17:09 To: Maven Users List Subject: RE: Maven 3.0.3: Problems with SNAPSHOT updates There are two ways. You can force maven to update snapshot by using the - U option. Ie: mvn -U install Or you can change when maven updates snapshots by default by changing the updatePolicy in your settings.xml file. http://maven.apache.org/ref/3.0.3/maven-settings/settings.html -Original Message- From: Dreier Ruediger [mailto:ruediger.dre...@bdal.de] Sent: Thursday, October 20, 2011 11:02 AM To: 'users@maven.apache.org' Subject: Maven 3.0.3: Problems with SNAPSHOT updates Hello! We are currently using Maven 2.2.1 and Artifactory 2.3.4 (rev. 13017) as repository server and I am now evaluating if we can migrate to Maven 3. I am testing Maven 3 in the following environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Java version: 1.6.0_26, vendor: Sun Microsystems Inc. Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: x86, family: windows I used a very simple POM file for this check: dependencies dependency groupIdde.bdal.common.bcl/groupId artifactIdsettings/artifactId version0.0.0.1-SNAPSHOT/version classifierbinaries/classifier typezip/type /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.2/version executions execution phaseprocess-resources/phase goals goalunpack-dependencies/goal /goals configuration copyPomtrue/copyPom outputDirectory./target/references/outputDirectory /configuration /execution /executions /plugin /plugins /build On a second PC (our Jenkins build system, still using Maven 2.2.1) the project de.bdal.common.bcl:settings can be build. With an empty local repository, everything works well: 'mvn install' downloads the newest version of de.bdal.common.bcl:settings to my local repository and the dependency plugin extracts it. Then I use Jenkins on the build system to create a new SNAPSHOT build of de.bdal.common.bcl:settings. Now I try to use this new version: 'mvn -U install' only downloads metadata: Downloading: http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1- SNAPSHOT/maven-metadata.xml Downloaded: http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1- SNAPSHOT/maven-metadata.xml (319 B at 4.0 KB/sec) and my local repository contains updated files maven-metadata- inhouse.xml, maven-metadata-inhouse.xml.sha1 and resolver- status.properties. But all other files are not changed (especially settings-0.0.0.1-SNAPSHOT-binaries.zip is not updated). However maven- metadata-inhouse.xml contains the correct value for lastUpdate (build time on the server). What am I doing wrong? How do I get updates of snapshot dependencies without deleting my local repository? Thanks for any help, i.A. Rüdiger Dreier Project Manager Bruker Daltonik GmbH Fahrenheitstr. 4 28359 Bremen, Germany Phone: +49 421 2205-393 Fax: +49 421 2205-3005 ruediger.dre...@bdal.demailto:ruediger.dre...@bdal.de www.bruker.comhttp://www.bruker.com/ Sitz der Gesellschaft / Registered Office Bremen; Handelsregister Amtsgericht Bremen HRB 8150 / Commercial Register District Court Bremen HRB 8150; Geschäftsführer / Managing Directors: Frank Laukien, Ph. D., Gerd Hülso, Sebastian Meyer-Plath, Stefan Ruge, Ian Sanders, Ph. D., Dr. Michael Schubert Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich für die
Maven 3.0.3: Problems with SNAPSHOT updates
Hello! We are currently using Maven 2.2.1 and Artifactory 2.3.4 (rev. 13017) as repository server and I am now evaluating if we can migrate to Maven 3. I am testing Maven 3 in the following environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Java version: 1.6.0_26, vendor: Sun Microsystems Inc. Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: x86, family: windows I used a very simple POM file for this check: dependencies dependency groupIdde.bdal.common.bcl/groupId artifactIdsettings/artifactId version0.0.0.1-SNAPSHOT/version classifierbinaries/classifier typezip/type /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.2/version executions execution phaseprocess-resources/phase goals goalunpack-dependencies/goal /goals configuration copyPomtrue/copyPom outputDirectory./target/references/outputDirectory /configuration /execution /executions /plugin /plugins /build On a second PC (our Jenkins build system, still using Maven 2.2.1) the project de.bdal.common.bcl:settings can be build. With an empty local repository, everything works well: 'mvn install' downloads the newest version of de.bdal.common.bcl:settings to my local repository and the dependency plugin extracts it. Then I use Jenkins on the build system to create a new SNAPSHOT build of de.bdal.common.bcl:settings. Now I try to use this new version: 'mvn -U install' only downloads metadata: Downloading: http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1-SNAPSHOT/maven-metadata.xml Downloaded: http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1-SNAPSHOT/maven-metadata.xml (319 B at 4.0 KB/sec) and my local repository contains updated files maven-metadata-inhouse.xml, maven-metadata-inhouse.xml.sha1 and resolver-status.properties. But all other files are not changed (especially settings-0.0.0.1-SNAPSHOT-binaries.zip is not updated). However maven-metadata-inhouse.xml contains the correct value for lastUpdate (build time on the server). What am I doing wrong? How do I get updates of snapshot dependencies without deleting my local repository? Thanks for any help, i.A. Rüdiger Dreier Project Manager Bruker Daltonik GmbH Fahrenheitstr. 4 28359 Bremen, Germany Phone: +49 421 2205-393 Fax: +49 421 2205-3005 ruediger.dre...@bdal.demailto:ruediger.dre...@bdal.de www.bruker.comhttp://www.bruker.com/ Sitz der Gesellschaft / Registered Office Bremen; Handelsregister Amtsgericht Bremen HRB 8150 / Commercial Register District Court Bremen HRB 8150; Geschäftsführer / Managing Directors: Frank Laukien, Ph. D., Gerd Hülso, Sebastian Meyer-Plath, Stefan Ruge, Ian Sanders, Ph. D., Dr. Michael Schubert Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich für die ordnungsgemäße, vollständige und verzögerungsfreie Übertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend bestätigt wird. Disclaimer: Bruker Daltonik GmbH is not responsible for correct, complete and timely transmission of this message. The content of this e-mail, including any attachments, is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax
RE: Maven 3.0.3: Problems with SNAPSHOT updates
There are two ways. You can force maven to update snapshot by using the -U option. Ie: mvn -U install Or you can change when maven updates snapshots by default by changing the updatePolicy in your settings.xml file. http://maven.apache.org/ref/3.0.3/maven-settings/settings.html -Original Message- From: Dreier Ruediger [mailto:ruediger.dre...@bdal.de] Sent: Thursday, October 20, 2011 11:02 AM To: 'users@maven.apache.org' Subject: Maven 3.0.3: Problems with SNAPSHOT updates Hello! We are currently using Maven 2.2.1 and Artifactory 2.3.4 (rev. 13017) as repository server and I am now evaluating if we can migrate to Maven 3. I am testing Maven 3 in the following environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Java version: 1.6.0_26, vendor: Sun Microsystems Inc. Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: x86, family: windows I used a very simple POM file for this check: dependencies dependency groupIdde.bdal.common.bcl/groupId artifactIdsettings/artifactId version0.0.0.1-SNAPSHOT/version classifierbinaries/classifier typezip/type /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.2/version executions execution phaseprocess-resources/phase goals goalunpack-dependencies/goal /goals configuration copyPomtrue/copyPom outputDirectory./target/references/outputDirectory /configuration /execution /executions /plugin /plugins /build On a second PC (our Jenkins build system, still using Maven 2.2.1) the project de.bdal.common.bcl:settings can be build. With an empty local repository, everything works well: 'mvn install' downloads the newest version of de.bdal.common.bcl:settings to my local repository and the dependency plugin extracts it. Then I use Jenkins on the build system to create a new SNAPSHOT build of de.bdal.common.bcl:settings. Now I try to use this new version: 'mvn -U install' only downloads metadata: Downloading: http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1- SNAPSHOT/maven-metadata.xml Downloaded: http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1- SNAPSHOT/maven-metadata.xml (319 B at 4.0 KB/sec) and my local repository contains updated files maven-metadata- inhouse.xml, maven-metadata-inhouse.xml.sha1 and resolver- status.properties. But all other files are not changed (especially settings-0.0.0.1-SNAPSHOT-binaries.zip is not updated). However maven- metadata-inhouse.xml contains the correct value for lastUpdate (build time on the server). What am I doing wrong? How do I get updates of snapshot dependencies without deleting my local repository? Thanks for any help, i.A. Rüdiger Dreier Project Manager Bruker Daltonik GmbH Fahrenheitstr. 4 28359 Bremen, Germany Phone: +49 421 2205-393 Fax: +49 421 2205-3005 ruediger.dre...@bdal.demailto:ruediger.dre...@bdal.de www.bruker.comhttp://www.bruker.com/ Sitz der Gesellschaft / Registered Office Bremen; Handelsregister Amtsgericht Bremen HRB 8150 / Commercial Register District Court Bremen HRB 8150; Geschäftsführer / Managing Directors: Frank Laukien, Ph. D., Gerd Hülso, Sebastian Meyer-Plath, Stefan Ruge, Ian Sanders, Ph. D., Dr. Michael Schubert Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich für die ordnungsgemäße, vollständige und verzögerungsfreie Übertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend bestätigt wird. Disclaimer: Bruker Daltonik GmbH is not responsible for correct, complete and timely transmission of this message. The content of this e-mail, including any attachments, is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax
maven 3.0.3 - performance with version ranges
maven 3.0.3 has terrible performance and memory usage when using version ranges. This has a knock on effect using m2e It takes maven ages to update the maven dependencies. I have a main project with a some version ranged dependencies which in turn have versioned ranged dependencies. Outside of eclipse it takes many minutes and considerable memory to get a successful build. Most time is spent resolving the dependencies. I have also run maven offline when I know I have all dependencies in my local repo and it is still very, very slow. In m2e (and workspace resolution on), you can check out a dependency that is very simple and this triggers a re-build of the main project. The same happens when you delete the dependent project or make pom version changes to it. So in eclipse this becomes really tedious especially if you have 4 or 5 related projects checked out. You end up sitting and waiting for your workspace to be re-built all the time. I understand what maven is doing but I do believe it could be done a lot better when resolving version ranges. I also know maven 3.0.3 uses aether 1.11 to so its dependency management. I'm really keen to try and find a solution. aether 1.12 has been released. Is there anyway I can hook this into maven 3.0.3 Does aether 1.12 solve Is there a pre-release of maven 3.0.4 out there yet that I can try and does it use aether 1.12 ? Thanks Paul - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven 3.0.3 - performance with version ranges
Take a peek at this thread (especially 1st mail): http://maven.40175.n5.nabble.com/Apache-Maven-distribution-with-fixes-td4639045.html Thanks, ~t~ On Fri, Sep 30, 2011 at 12:22 PM, Paul French paul.fre...@kirona.com wrote: maven 3.0.3 has terrible performance and memory usage when using version ranges. This has a knock on effect using m2e It takes maven ages to update the maven dependencies. I have a main project with a some version ranged dependencies which in turn have versioned ranged dependencies. Outside of eclipse it takes many minutes and considerable memory to get a successful build. Most time is spent resolving the dependencies. I have also run maven offline when I know I have all dependencies in my local repo and it is still very, very slow. In m2e (and workspace resolution on), you can check out a dependency that is very simple and this triggers a re-build of the main project. The same happens when you delete the dependent project or make pom version changes to it. So in eclipse this becomes really tedious especially if you have 4 or 5 related projects checked out. You end up sitting and waiting for your workspace to be re-built all the time. I understand what maven is doing but I do believe it could be done a lot better when resolving version ranges. I also know maven 3.0.3 uses aether 1.11 to so its dependency management. I'm really keen to try and find a solution. aether 1.12 has been released. Is there anyway I can hook this into maven 3.0.3 Does aether 1.12 solve Is there a pre-release of maven 3.0.4 out there yet that I can try and does it use aether 1.12 ? Thanks Paul - 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
RE: maven 3.0.3 - performance with version ranges
FYI, You can tell maven 3.0.3 to work with aether 1.13 (I think this is the latest release) just by dropping aether jars in $MAVEN_HOME/lib/ext. They should take precedence over the aether 1.11 bundled with maven in $MAVEN_HOME/lib. I did that with aether 1.12 and there was no issue, at least for my projects. Christophe -Original Message- From: Paul French [mailto:paul.fre...@kirona.com] Sent: Freitag, 30. September 2011 12:22 To: Maven Users List; Maven Integration for Eclipse users mailing list Subject: maven 3.0.3 - performance with version ranges maven 3.0.3 has terrible performance and memory usage when using version ranges. This has a knock on effect using m2e It takes maven ages to update the maven dependencies. I have a main project with a some version ranged dependencies which in turn have versioned ranged dependencies. Outside of eclipse it takes many minutes and considerable memory to get a successful build. Most time is spent resolving the dependencies. I have also run maven offline when I know I have all dependencies in my local repo and it is still very, very slow. In m2e (and workspace resolution on), you can check out a dependency that is very simple and this triggers a re-build of the main project. The same happens when you delete the dependent project or make pom version changes to it. So in eclipse this becomes really tedious especially if you have 4 or 5 related projects checked out. You end up sitting and waiting for your workspace to be re-built all the time. I understand what maven is doing but I do believe it could be done a lot better when resolving version ranges. I also know maven 3.0.3 uses aether 1.11 to so its dependency management. I'm really keen to try and find a solution. aether 1.12 has been released. Is there anyway I can hook this into maven 3.0.3 Does aether 1.12 solve Is there a pre-release of maven 3.0.4 out there yet that I can try and does it use aether 1.12 ? Thanks Paul - 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
Re: [m2e-users] maven 3.0.3 - performance with version ranges
wow! Dropped in aether 1.13 into apache maven lib/ext (so patched applied external to eclipse) and also updated the m2e embedded runtime plugin org.eclipse.m2e.maven.runtime_1.0.1.201106291304 (as a quick test) and now as an example a build that took 1 minute 43 secs now only takes 5 seconds. Will build our own embedded runtime as instructed below now. Thanks for everyone's help. Any ideas when an official maven 3.0.4 release will happen as well as an official maven 3.0.4 embedded runtime m2e connector ? Paul French Kirona Solutions Ltd Tel: 07803 122 058 E-Mail: paul.fre...@kirona.com Web: www.kirona.com http://www.kirona.com This email and any attachments are confidential and should only be read by those to whom they are addressed. If you are not the intended recipient, please contact us on 01625 585511, delete the email (including any attachment) from your computer and destroy any copies. Any distribution or copying without our prior permission is prohibited. Internet communications are not always secure and may be subject to delays, non-delivery and unauthorised alterations. Therefore, information expressed in this message is not given or endorsed by Kirona Solutions Limited (Kirona) unless otherwise notified by our duly authorised representative independent of this message. No warranty is given that this email (including any attachment) is virus free. Any views or opinions presented are solely those of the author and do not necessarily represent those of Kirona. Registered addresses: Kirona Solutions Limited, Barrington House, Heyes Lane, Alderley Edge, Cheshire. SK9 7LA Registered in England and Wales No: 04678711 On 30/09/2011 12:28, Igor Fedorenko wrote: I do not know if the underlying problem has been solved with aether and/or maven. You need to talk to aether and/or maven developers to find out. As far updating m2e embedded maven runtime, it is relatively easy now -- setup development environment as explain in [1], then change m2e-maven-runtime/org.eclipse.m2e.maven.runtime/pom.xml to use whatever version of dependencies you want to try. [1] http://wiki.eclipse.org/M2E_Development_Environment -- Regards, Igor On 11-09-30 6:22 AM, Paul French wrote: maven 3.0.3 has terrible performance and memory usage when using version ranges. This has a knock on effect using m2e It takes maven ages to update the maven dependencies. I have a main project with a some version ranged dependencies which in turn have versioned ranged dependencies. Outside of eclipse it takes many minutes and considerable memory to get a successful build. Most time is spent resolving the dependencies. I have also run maven offline when I know I have all dependencies in my local repo and it is still very, very slow. In m2e (and workspace resolution on), you can check out a dependency that is very simple and this triggers a re-build of the main project. The same happens when you delete the dependent project or make pom version changes to it. So in eclipse this becomes really tedious especially if you have 4 or 5 related projects checked out. You end up sitting and waiting for your workspace to be re-built all the time. I understand what maven is doing but I do believe it could be done a lot better when resolving version ranges. I also know maven 3.0.3 uses aether 1.11 to so its dependency management. I'm really keen to try and find a solution. aether 1.12 has been released. Is there anyway I can hook this into maven 3.0.3 Does aether 1.12 solve Is there a pre-release of maven 3.0.4 out there yet that I can try and does it use aether 1.12 ? Thanks Paul ___ m2e-users mailing list m2e-us...@eclipse.org https://dev.eclipse.org/mailman/listinfo/m2e-users ___ m2e-users mailing list m2e-us...@eclipse.org https://dev.eclipse.org/mailman/listinfo/m2e-users
Re: maven 3.0.3 - performance with version ranges
+1 for using aether 1.12, this reduced 2:00 compile time to ~45 seconds. 2011/9/30 Tamás Cservenák ta...@cservenak.net Take a peek at this thread (especially 1st mail): http://maven.40175.n5.nabble.com/Apache-Maven-distribution-with-fixes-td4639045.html Thanks, ~t~ On Fri, Sep 30, 2011 at 12:22 PM, Paul French paul.fre...@kirona.com wrote: maven 3.0.3 has terrible performance and memory usage when using version ranges. This has a knock on effect using m2e It takes maven ages to update the maven dependencies. I have a main project with a some version ranged dependencies which in turn have versioned ranged dependencies. Outside of eclipse it takes many minutes and considerable memory to get a successful build. Most time is spent resolving the dependencies. I have also run maven offline when I know I have all dependencies in my local repo and it is still very, very slow. In m2e (and workspace resolution on), you can check out a dependency that is very simple and this triggers a re-build of the main project. The same happens when you delete the dependent project or make pom version changes to it. So in eclipse this becomes really tedious especially if you have 4 or 5 related projects checked out. You end up sitting and waiting for your workspace to be re-built all the time. I understand what maven is doing but I do believe it could be done a lot better when resolving version ranges. I also know maven 3.0.3 uses aether 1.11 to so its dependency management. I'm really keen to try and find a solution. aether 1.12 has been released. Is there anyway I can hook this into maven 3.0.3 Does aether 1.12 solve Is there a pre-release of maven 3.0.4 out there yet that I can try and does it use aether 1.12 ? Thanks Paul - 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 -- @tommychheng http://tommy.chheng.com
Antwort: Re: Incorrect assembly created with Maven 3.0.3
Hi, Thorsten Heit wrote: ...snip ... But what puzzles me is that the archives created by Maven 2.2.1 and Maven 3.0.3 are different, and I don't see a reason why... ...snip... Hi there, Did you ever get anywhere with this? I'm seeing the same problem: Maven 3.0.3 adds batik-js-1.7.jar and omits serializer-2.7.1.jar. Though I am not positive, I believe this is the cause of an exception I see at runtime, the stack trace of which starts like this: java.lang.IllegalAccessError: org/apache/xml/serializer/ExtendedContentHandler at org.apache.xalan.transformer.TransformerImpl.createSerializationHandler (TransformerImpl.java:1233) ... I get a ClassNotFoundException at runtime. I don't know exactly which class, but it was one from the serializer jar... Unfortunately the only solution I have so far is to directly add a dependency to the serializer jar in the pom although no class in the project uses it - it is used transitively by xerces or xalan I guess... Regards Thorsten
Re: Re: Incorrect assembly created with Maven 3.0.3
Hi, Just a wild guess, do you have a dependencyManagament handling these artifacts where the scope is defined? I've seen different behavior between Maven 2.x and 3.0.x due to this (MJBOSSPACK-40 [1]). No, I haven't used dependency management. I simply referenced xerces and/or xalan (don't remember it exactly because I changed the project in the meantime...) Regards Thorsten
Re: Incorrect assembly created with Maven 3.0.3
Just a wild guess, do you have a dependencyManagament handling these artifacts where the scope is defined? I've seen different behavior between Maven 2.x and 3.0.x due to this (MJBOSSPACK-40 [1]). /Anders [1] http://jira.codehaus.org/browse/MJBOSSPACK-40 On Fri, Sep 16, 2011 at 22:43, WhiteMarlin wes_mun...@cytoanalytics.com wrote: Thorsten Heit wrote: ...snip ... But what puzzles me is that the archives created by Maven 2.2.1 and Maven 3.0.3 are different, and I don't see a reason why... ...snip... Hi there, Did you ever get anywhere with this? I'm seeing the same problem: Maven 3.0.3 adds batik-js-1.7.jar and omits serializer-2.7.1.jar. Though I am not positive, I believe this is the cause of an exception I see at runtime, the stack trace of which starts like this: java.lang.IllegalAccessError: org/apache/xml/serializer/ExtendedContentHandler at org.apache.xalan.transformer.TransformerImpl.createSerializationHandler(TransformerImpl.java:1233) ... Thanks! -- View this message in context: http://maven.40175.n5.nabble.com/Incorrect-assembly-created-with-Maven-3-0-3-tp4393328p4811951.html Sent from the Maven - Users mailing list archive at Nabble.com. - 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
Re: Incorrect assembly created with Maven 3.0.3
Thorsten Heit wrote: ...snip ... But what puzzles me is that the archives created by Maven 2.2.1 and Maven 3.0.3 are different, and I don't see a reason why... ...snip... Hi there, Did you ever get anywhere with this? I'm seeing the same problem: Maven 3.0.3 adds batik-js-1.7.jar and omits serializer-2.7.1.jar. Though I am not positive, I believe this is the cause of an exception I see at runtime, the stack trace of which starts like this: java.lang.IllegalAccessError: org/apache/xml/serializer/ExtendedContentHandler at org.apache.xalan.transformer.TransformerImpl.createSerializationHandler(TransformerImpl.java:1233) ... Thanks! -- View this message in context: http://maven.40175.n5.nabble.com/Incorrect-assembly-created-with-Maven-3-0-3-tp4393328p4811951.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven 3.0.3 installation help
Hey guys, I'm pretty new to Maven and I am attempting to install it on our server here. Here is a quick overview of where I am at: *$ java -version* java version 1.6.0_26 Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode) *$ type java* java is hashed (/usr/java/jdk1.6.0_26/bin/java) *$ echo $JAVA_HOME/bin* /usr/java/jdk1.6.0_26/bin So as you can see I have updated to the newest version of JDK 1.6. When I try to do mvn --version I get this error : Exception in thread main java.lang.UnsupportedClassVersionError: org/apache/mav en/cli/MavenCli (Unsupported major.minor version 49.0) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123 ) at java.net.URLClassLoader.defineClass(URLClassLoader.java:251) at java.net.URLClassLoader.access$100(URLClassLoader.java:55) at java.net.URLClassLoader$1.run(URLClassLoader.java:194) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(Cla ssRealm.java:386) at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(S elfFirstStrategy.java:42) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm. java:244) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm. java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.getMainClass(Launche r.java:145) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launc her.java:267) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java :230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Lau ncher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:3 52) Any Ideas? Thanks -- *Patrick Lind Produce Pro Software* __ mailto:patrick.l...@producepro.com
Re: Maven 3.0.3 installation help
sh -v /wherever/bin/mvn and see what it's actually running? On Tue, Jun 28, 2011 at 12:21 PM, Patrick Lind patrick.l...@producepro.com wrote: Hey guys, I'm pretty new to Maven and I am attempting to install it on our server here. Here is a quick overview of where I am at: *$ java -version* java version 1.6.0_26 Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode) *$ type java* java is hashed (/usr/java/jdk1.6.0_26/bin/java) *$ echo $JAVA_HOME/bin* /usr/java/jdk1.6.0_26/bin So as you can see I have updated to the newest version of JDK 1.6. When I try to do mvn --version I get this error : Exception in thread main java.lang.UnsupportedClassVersionError: org/apache/mav en/cli/MavenCli (Unsupported major.minor version 49.0) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123 ) at java.net.URLClassLoader.defineClass(URLClassLoader.java:251) at java.net.URLClassLoader.access$100(URLClassLoader.java:55) at java.net.URLClassLoader$1.run(URLClassLoader.java:194) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(Cla ssRealm.java:386) at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(S elfFirstStrategy.java:42) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm. java:244) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm. java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.getMainClass(Launche r.java:145) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launc her.java:267) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java :230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Lau ncher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:3 52) Any Ideas? Thanks -- *Patrick Lind Produce Pro Software* __ mailto:patrick.l...@producepro.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
Thanks for that. Out of interest if I remove the snapshot repository and change my version ranges to [8.0.0,9.0.0) instead of [8.0.0.SNAPSHOT,9.0.0.SNAPSHOT) all works fine again even in eclipse. For now we will live without snapshots. On 22/06/2011 06:21, Kristian Rosenvold wrote: From what I can understand this issue is almost certainly some kind of combinatorial explosion caused in the calculation of the dependencies. Sample project/and or heap dumps will be required here as far as I can understand. As for the embedded building, you might want to take note that plexus-utils 2.1 fixes a memory leak wrt embedding. This has been released in surefire 2.9. maven-scm and the xAR plugins also have the same problem and can be fixed by upgrading the plexus-utils dependency to 2.1 in these plugins. Kristian - 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
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
humm, maybe the resolution mechanism sniffs _all_ snapshot timeshot versions and not only the last one? Could you please re-add the snapshot repo and set the version ranges to [8.0.0,9.0.0)? The question is if this is related to the fact that the snapshot repo just has lots of artifacts (due to the timestamping) or if it's related to the -SNAPSHOT in the version range. txs and LieGrue, strub --- On Wed, 6/22/11, Paul French paul.fre...@kirona.com wrote: From: Paul French paul.fre...@kirona.com Subject: Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads To: users@maven.apache.org Cc: Ian Jones ian.jo...@kirona.com Date: Wednesday, June 22, 2011, 8:26 AM Thanks for that. Out of interest if I remove the snapshot repository and change my version ranges to [8.0.0,9.0.0) instead of [8.0.0.SNAPSHOT,9.0.0.SNAPSHOT) all works fine again even in eclipse. For now we will live without snapshots. On 22/06/2011 06:21, Kristian Rosenvold wrote: From what I can understand this issue is almost certainly some kind of combinatorial explosion caused in the calculation of the dependencies. Sample project/and or heap dumps will be required here as far as I can understand. As for the embedded building, you might want to take note that plexus-utils 2.1 fixes a memory leak wrt embedding. This has been released in surefire 2.9. maven-scm and the xAR plugins also have the same problem and can be fixed by upgrading the plexus-utils dependency to 2.1 in these plugins. Kristian - 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
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
Added the snapshot repo back in and it now has major problems. A build that was fine before now fails with out of memory. - all version ranges set to [8.0.0,9.0.0) On 22/06/2011 09:39, Mark Struberg wrote: humm, maybe the resolution mechanism sniffs _all_ snapshot timeshot versions and not only the last one? Could you please re-add the snapshot repo and set the version ranges to [8.0.0,9.0.0)? The question is if this is related to the fact that the snapshot repo just has lots of artifacts (due to the timestamping) or if it's related to the -SNAPSHOT in the version range. txs and LieGrue, strub --- On Wed, 6/22/11, Paul Frenchpaul.fre...@kirona.com wrote: From: Paul Frenchpaul.fre...@kirona.com Subject: Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads To: users@maven.apache.org Cc: Ian Jonesian.jo...@kirona.com Date: Wednesday, June 22, 2011, 8:26 AM Thanks for that. Out of interest if I remove the snapshot repository and change my version ranges to [8.0.0,9.0.0) instead of [8.0.0.SNAPSHOT,9.0.0.SNAPSHOT) all works fine again even in eclipse. For now we will live without snapshots. On 22/06/2011 06:21, Kristian Rosenvold wrote: From what I can understand this issue is almost certainly some kind of combinatorial explosion caused in the calculation of the dependencies. Sample project/and or heap dumps will be required here as far as I can understand. As for the embedded building, you might want to take note that plexus-utils 2.1 fixes a memory leak wrt embedding. This has been released in surefire 2.9. maven-scm and the xAR plugins also have the same problem and can be fixed by upgrading the plexus-utils dependency to 2.1 in these plugins. Kristian - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Fwd: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
Can someone confirm on the maven users list that they have received this email? I did not but it does appear in the mail archive Thanks P Original Message Subject: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads Date: Mon, 20 Jun 2011 18:54:41 +0100 From: Paul French paul.fre...@kirona.com Organisation: Kirona To: users@maven.apache.org CC: Ian Jones ian.jo...@kirona.com Below is some filtered output from a maven build (showing maven meta data being downloaded for one artifact). All my dependencies use version ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT) In general the build fails with out of memory. I can increase the heap size and the build is successful, but a relatively simple build is now requiring 500MB heap size. First question is why is maven re-checking and downloading the same meta data over and over again? If I add additional version ranged dependencies to my pom then the problem seems to get exponentially worse. For a larger build so many requests are made so quickly to the nexus remote repository that I start to see Error transferring file: Address already in use: connect. I can circumvent this problem by setting my repos to have an updatePolicy of interval:10 so during a build maven does not re-download the same maven meta data file. However not very complicated builds are still failing with out of memory even with 1024M of heap space. So this workaround just speeds up the inevitable out of memory error appearing. Any ideas how to reduce the memory usage? Do not say do not use version ranges. We use semantic versioning enforced by API analysis tools for each of our modules (OSGi bundles) so we require version ranges. If I change all version range dependencies to an exact dependency (a serious amount of pom editing) then all is fine. As you can tell below we have 3 main internal remote repos setup (kirona, kirona-snapshot and third.party.libraries). We do not specify version ranges on libraries that are not in our control e.g. log4j etc etc Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 21.6 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 6.6 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 10.0 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 11.2 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 9.7 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 10.8 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/serve... The above problems renders eclipse useless with m2e, it causes eclipse to hang on start up (build automatically set to true) and eventually die!! I'm starting to come to the conclusion that between maven and m2e version ranges just do not work very well. I hope I am wrong!! Thanks Ian
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
Hello, Your problem is with m2e or Apache Maven tru the cli ? If m2e, you probably have to post it in a m2e mailing list [1]. Thanks -- Olivier Lamy http://twitter.com/olamy | http://www.linkedin.com/in/olamy [1] http://www.eclipse.org/m2e/support/ 2011/6/21 Paul French paul.fre...@kirona.com: Can someone confirm on the maven users list that they have received this email? I did not but it does appear in the mail archive Thanks P Original Message Subject: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads Date: Mon, 20 Jun 2011 18:54:41 +0100 From: Paul French paul.fre...@kirona.com Organisation: Kirona To: users@maven.apache.org CC: Ian Jones ian.jo...@kirona.com Below is some filtered output from a maven build (showing maven meta data being downloaded for one artifact). All my dependencies use version ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT) In general the build fails with out of memory. I can increase the heap size and the build is successful, but a relatively simple build is now requiring 500MB heap size. First question is why is maven re-checking and downloading the same meta data over and over again? If I add additional version ranged dependencies to my pom then the problem seems to get exponentially worse. For a larger build so many requests are made so quickly to the nexus remote repository that I start to see Error transferring file: Address already in use: connect. I can circumvent this problem by setting my repos to have an updatePolicy of interval:10 so during a build maven does not re-download the same maven meta data file. However not very complicated builds are still failing with out of memory even with 1024M of heap space. So this workaround just speeds up the inevitable out of memory error appearing. Any ideas how to reduce the memory usage? Do not say do not use version ranges. We use semantic versioning enforced by API analysis tools for each of our modules (OSGi bundles) so we require version ranges. If I change all version range dependencies to an exact dependency (a serious amount of pom editing) then all is fine. As you can tell below we have 3 main internal remote repos setup (kirona, kirona-snapshot and third.party.libraries). We do not specify version ranges on libraries that are not in our control e.g. log4j etc etc Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 21.6 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 6.6 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 10.0 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 11.2 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 9.7 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 10.8 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/serve... The above problems renders eclipse useless with m2e, it causes eclipse to hang on start up (build automatically set to true) and eventually die!! I'm starting to come to the conclusion that between maven and m2e version ranges just do not work very well. I
Re: Fwd: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
To be clear the problem is in maven. I am running maven from the command line. Thanks P On 21/06/2011 11:16, Paul French wrote: Can someone confirm on the maven users list that they have received this email? I did not but it does appear in the mail archive Thanks P Original Message Subject: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads Date: Mon, 20 Jun 2011 18:54:41 +0100 From: Paul French paul.fre...@kirona.com Organisation: Kirona To: users@maven.apache.org CC: Ian Jones ian.jo...@kirona.com Below is some filtered output from a maven build (showing maven meta data being downloaded for one artifact). All my dependencies use version ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT) In general the build fails with out of memory. I can increase the heap size and the build is successful, but a relatively simple build is now requiring 500MB heap size. First question is why is maven re-checking and downloading the same meta data over and over again? If I add additional version ranged dependencies to my pom then the problem seems to get exponentially worse. For a larger build so many requests are made so quickly to the nexus remote repository that I start to see Error transferring file: Address already in use: connect. I can circumvent this problem by setting my repos to have an updatePolicy of interval:10 so during a build maven does not re-download the same maven meta data file. However not very complicated builds are still failing with out of memory even with 1024M of heap space. So this workaround just speeds up the inevitable out of memory error appearing. Any ideas how to reduce the memory usage? Do not say do not use version ranges. We use semantic versioning enforced by API analysis tools for each of our modules (OSGi bundles) so we require version ranges. If I change all version range dependencies to an exact dependency (a serious amount of pom editing) then all is fine. As you can tell below we have 3 main internal remote repos setup (kirona, kirona-snapshot and third.party.libraries). We do not specify version ranges on libraries that are not in our control e.g. log4j etc etc Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 21.6 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 6.6 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 10.0 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 11.2 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 9.7 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 10.8 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/serve... The above problems renders eclipse useless with m2e, it causes eclipse to hang on start up (build automatically set to true) and eventually die!! I'm starting to come to the conclusion that between maven and m2e version ranges just do not work very well. I hope I am wrong!! Thanks Ian
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
On Mon, Jun 20, 2011 at 19:54, Paul French paul.fre...@kirona.com wrote: Below is some filtered output from a maven build (showing maven meta data being downloaded for one artifact). All my dependencies use version ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT) In general the build fails with out of memory. I can increase the heap size and the build is successful, but a relatively simple build is now requiring 500MB heap size. First question is why is maven re-checking and downloading the same meta data over and over again? If I add additional version ranged dependencies to my pom then the problem seems to get exponentially worse. For a larger build so many requests are made so quickly to the nexus remote repository that I start to see Error transferring file: Address already in use: connect. Any ideas how to reduce the memory usage? Do not say do not use version ranges. We use semantic versioning enforced by API analysis tools for each of our modules (OSGi bundles) so we require version ranges. If I change all version range dependencies to an exact dependency (a serious amount of pom editing) then all is fine. As you can tell below we have 3 main internal remote repos setup (kirona, kirona-snapshot and third.party.libraries). We do not specify version ranges on libraries that are not in our control e.g. log4j etc etc Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 21.6 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 6.6 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 10.0 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 11.2 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 9.7 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 10.8 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/serve... The above problems renders eclipse useless with m2e, it causes eclipse to hang on start up (build automatically set to true) and eventually die!! I'm starting to come to the conclusion that between maven and m2e version ranges just do not work very well. I hope I am wrong!! Thanks Paul In my a case I found Maven slurping metadata on every build was related to how I had configured updatePolicyalways/updatePolicy in repositories profile defined in my settings.xml (It had been a temporary change which got forgotten...) I got burned twice by version ranges. (It's at least a few years ago, so I don't remember the specifics.) I haven't touched them since. Also, their meaning hinges on how Maven chooses to sort versions, and I've not yet seen a sufficiently unambiguous definition of that. Consider that Maven will accept aNyOld3.2Crap-X1r as a version number. Even if you stick to the 'parse-able' versions of the form 1.2.3-mumble. 1.2.3-SNAPSHOT 1.2.3 1.2.3-beta10 1.2.3-beta2 1.2.3-beta1-SNAPSHOT 1.2.3-beta1 1.2.3-beta1 ? 1.2.3? 1.2.3-beta1-SNAPSHOT ? 1.2.3-SNAPSHOT Take your best guess. Sticking to using only SNAPSHOTs and single concrete versions is more work if you have a large number of interdependent projects. It does have the advantage of recording in your version
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
Thanks for reply - see inline On 21/06/2011 11:27, B Smith-Mannschott wrote: On Mon, Jun 20, 2011 at 19:54, Paul Frenchpaul.fre...@kirona.com wrote: Below is some filtered output from a maven build (showing maven meta data being downloaded for one artifact). All my dependencies use version ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT) In general the build fails with out of memory. I can increase the heap size and the build is successful, but a relatively simple build is now requiring 500MB heap size. First question is why is maven re-checking and downloading the same meta data over and over again? If I add additional version ranged dependencies to my pom then the problem seems to get exponentially worse. For a larger build so many requests are made so quickly to the nexus remote repository that I start to see Error transferring file: Address already in use: connect. Any ideas how to reduce the memory usage? Do not say do not use version ranges. We use semantic versioning enforced by API analysis tools for each of our modules (OSGi bundles) so we require version ranges. If I change all version range dependencies to an exact dependency (a serious amount of pom editing) then all is fine. As you can tell below we have 3 main internal remote repos setup (kirona, kirona-snapshot and third.party.libraries). We do not specify version ranges on libraries that are not in our control e.g. log4j etc etc Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 21.6 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 6.6 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 10.0 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 11.2 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 9.7 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 10.8 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/serve... The above problems renders eclipse useless with m2e, it causes eclipse to hang on start up (build automatically set to true) and eventually die!! I'm starting to come to the conclusion that between maven and m2e version ranges just do not work very well. I hope I am wrong!! Thanks Paul In my a case I found Maven slurping metadata on every build was related to how I had configuredupdatePolicyalways/updatePolicy in repositories profile defined in my settings.xml (It had been a temporary change which got forgotten...) I did circumvent the problem as you suggest by setting my repos to have an updatePolicy of interval:10 so during a build, maven does not re-download the same maven meta data file. However not very complicated builds are still failing with out of memory even with 1024M of heap space. So this workaround just speeds up the inevitable out of memory error appearing. I got burned twice by version ranges. (It's at least a few years ago, so I don't remember the specifics.) I haven't touched them since. Also, their meaning hinges on how Maven chooses to sort versions, and I've not yet seen a sufficiently unambiguous definition of that. Consider that Maven will accept aNyOld3.2Crap-X1r as a version number. Even if you stick to the 'parse-able' versions
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
Yes this came to the list. *someone* is going to have to run yourkit or jprofiler on a real version of your problem. Of course, the person best positioned to do that would be, ahem, you. Unless you could give access to, well, me. It would be a giant public service for there to be a sufficiently complex example of this sort of thing available for development and testing, and it would pay your organization off in the long run in terms of maven working better for you. On Tue, Jun 21, 2011 at 6:42 AM, Paul French paul.fre...@kirona.com wrote: Thanks for reply - see inline On 21/06/2011 11:27, B Smith-Mannschott wrote: On Mon, Jun 20, 2011 at 19:54, Paul Frenchpaul.fre...@kirona.com wrote: Below is some filtered output from a maven build (showing maven meta data being downloaded for one artifact). All my dependencies use version ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT) In general the build fails with out of memory. I can increase the heap size and the build is successful, but a relatively simple build is now requiring 500MB heap size. First question is why is maven re-checking and downloading the same meta data over and over again? If I add additional version ranged dependencies to my pom then the problem seems to get exponentially worse. For a larger build so many requests are made so quickly to the nexus remote repository that I start to see Error transferring file: Address already in use: connect. Any ideas how to reduce the memory usage? Do not say do not use version ranges. We use semantic versioning enforced by API analysis tools for each of our modules (OSGi bundles) so we require version ranges. If I change all version range dependencies to an exact dependency (a serious amount of pom editing) then all is fine. As you can tell below we have 3 main internal remote repos setup (kirona, kirona-snapshot and third.party.libraries). We do not specify version ranges on libraries that are not in our control e.g. log4j etc etc Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 21.6 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 6.6 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 10.0 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 11.2 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 9.7 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 10.8 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/serve... The above problems renders eclipse useless with m2e, it causes eclipse to hang on start up (build automatically set to true) and eventually die!! I'm starting to come to the conclusion that between maven and m2e version ranges just do not work very well. I hope I am wrong!! Thanks Paul In my a case I found Maven slurping metadata on every build was related to how I had configuredupdatePolicyalways/updatePolicy in repositories profile defined in my settings.xml (It had been a temporary change which got forgotten...) I did circumvent the problem as you suggest by setting my repos to have an updatePolicy of interval:10 so
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
500Mb is not a lot of memory for a Java program. We have noticed that some libraries such as Apache's CXF webservices will require additional memory to be added to Maven if you are building applications that include it. Since virtual memory is virtually free, you might as well just accept reality and increase the VM. I can not imagine anyone doing software development with a modern IDE that would have trouble finding 1Gb of VM. We build under Eclipse STS but I don't think that it makes any difference since Maven is running in its own VM. I would not use version ranges since I like to know what I am putting into production. Once you initially set the versions of what you are supporting, it is not difficult to maintain that list as you work your way through new versions of third party code. We do it at the start of each of our release cycles. We usually stick with the existing set from the last release unless there is a reason to move. The version configuration for a new release is setup and managed by the entire team (small part of the release startup) and unless something catches fire, we stick with our set throughout the life of our release. Ron On 21/06/2011 8:59 AM, Benson Margulies wrote: Yes this came to the list. *someone* is going to have to run yourkit or jprofiler on a real version of your problem. Of course, the person best positioned to do that would be, ahem, you. Unless you could give access to, well, me. It would be a giant public service for there to be a sufficiently complex example of this sort of thing available for development and testing, and it would pay your organization off in the long run in terms of maven working better for you. On Tue, Jun 21, 2011 at 6:42 AM, Paul Frenchpaul.fre...@kirona.com wrote: Thanks for reply - see inline On 21/06/2011 11:27, B Smith-Mannschott wrote: On Mon, Jun 20, 2011 at 19:54, Paul Frenchpaul.fre...@kirona.comwrote: Below is some filtered output from a maven build (showing maven meta data being downloaded for one artifact). All my dependencies use version ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT) In general the build fails with out of memory. I can increase the heap size and the build is successful, but a relatively simple build is now requiring 500MB heap size. First question is why is maven re-checking and downloading the same meta data over and over again? If I add additional version ranged dependencies to my pom then the problem seems to get exponentially worse. For a larger build so many requests are made so quickly to the nexus remote repository that I start to see Error transferring file: Address already in use: connect. Any ideas how to reduce the memory usage? Do not say do not use version ranges. We use semantic versioning enforced by API analysis tools for each of our modules (OSGi bundles) so we require version ranges. If I change all version range dependencies to an exact dependency (a serious amount of pom editing) then all is fine. As you can tell below we have 3 main internal remote repos setup (kirona, kirona-snapshot and third.party.libraries). We do not specify version ranges on libraries that are not in our control e.g. log4j etc etc Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 21.6 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 6.6 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 10.0 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 11.2 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
On 21/06/2011 14:25, Ron Wheeler wrote: 500Mb is not a lot of memory for a Java program. It is when all I can give eclipse is 900MB. Beyond that the JVM fails to start. M2E as far as I know does not start a new JVM when building. We have noticed that some libraries such as Apache's CXF webservices will require additional memory to be added to Maven if you are building applications that include it. Since virtual memory is virtually free, you might as well just accept reality and increase the VM. I can not imagine anyone doing software development with a modern IDE that would have trouble finding 1Gb of VM. On my 2GB laptop all I can give eclipse is 900MB We build under Eclipse STS but I don't think that it makes any difference since Maven is running in its own VM. I would not use version ranges since I like to know what I am putting into production. Once you initially set the versions of what you are supporting, it is not difficult to maintain that list as you work your way through new versions of third party code. We do it at the start of each of our release cycles. We usually stick with the existing set from the last release unless there is a reason to move. The version configuration for a new release is setup and managed by the entire team (small part of the release startup) and unless something catches fire, we stick with our set throughout the life of our release. We have 100's of bundles and usually most in flux. Someone put's a bug fix in a bundle, I do not want to have to *know*, as long as it is compatible with what I require which we automatically enforce via PDE API analysis tooling. At release time we know what is delivered and can re-produce the build since an exact version POM is built for us and packaged in the artifact with the version range one backed up. I can understand people being resistant to version ranges but with OSGi more and more jars are broken down into smaller components (and so projects) and version ranging really helps if you enforce semantic versioning between bundles. Nevertheless there is a problem with maven 3.0.3 when using version ranges. Ron On 21/06/2011 8:59 AM, Benson Margulies wrote: Yes this came to the list. *someone* is going to have to run yourkit or jprofiler on a real version of your problem. Of course, the person best positioned to do that would be, ahem, you. Unless you could give access to, well, me. It would be a giant public service for there to be a sufficiently complex example of this sort of thing available for development and testing, and it would pay your organization off in the long run in terms of maven working better for you. On Tue, Jun 21, 2011 at 6:42 AM, Paul Frenchpaul.fre...@kirona.com wrote: Thanks for reply - see inline On 21/06/2011 11:27, B Smith-Mannschott wrote: On Mon, Jun 20, 2011 at 19:54, Paul Frenchpaul.fre...@kirona.comwrote: Below is some filtered output from a maven build (showing maven meta data being downloaded for one artifact). All my dependencies use version ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT) In general the build fails with out of memory. I can increase the heap size and the build is successful, but a relatively simple build is now requiring 500MB heap size. First question is why is maven re-checking and downloading the same meta data over and over again? If I add additional version ranged dependencies to my pom then the problem seems to get exponentially worse. For a larger build so many requests are made so quickly to the nexus remote repository that I start to see Error transferring file: Address already in use: connect. Any ideas how to reduce the memory usage? Do not say do not use version ranges. We use semantic versioning enforced by API analysis tools for each of our modules (OSGi bundles) so we require version ranges. If I change all version range dependencies to an exact dependency (a serious amount of pom editing) then all is fine. As you can tell below we have 3 main internal remote repos setup (kirona, kirona-snapshot and third.party.libraries). We do not specify version ranges on libraries that are not in our control e.g. log4j etc etc Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 21.6 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 6.6 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
I forgot to mention that maven 3.0.3 is using more then 1024MB of heap before it even gets to the compile stage. We will look into profiling it later today. On 21/06/2011 14:45, Paul French wrote: On 21/06/2011 14:25, Ron Wheeler wrote: 500Mb is not a lot of memory for a Java program. It is when all I can give eclipse is 900MB. Beyond that the JVM fails to start. M2E as far as I know does not start a new JVM when building. We have noticed that some libraries such as Apache's CXF webservices will require additional memory to be added to Maven if you are building applications that include it. Since virtual memory is virtually free, you might as well just accept reality and increase the VM. I can not imagine anyone doing software development with a modern IDE that would have trouble finding 1Gb of VM. On my 2GB laptop all I can give eclipse is 900MB We build under Eclipse STS but I don't think that it makes any difference since Maven is running in its own VM. I would not use version ranges since I like to know what I am putting into production. Once you initially set the versions of what you are supporting, it is not difficult to maintain that list as you work your way through new versions of third party code. We do it at the start of each of our release cycles. We usually stick with the existing set from the last release unless there is a reason to move. The version configuration for a new release is setup and managed by the entire team (small part of the release startup) and unless something catches fire, we stick with our set throughout the life of our release. We have 100's of bundles and usually most in flux. Someone put's a bug fix in a bundle, I do not want to have to *know*, as long as it is compatible with what I require which we automatically enforce via PDE API analysis tooling. At release time we know what is delivered and can re-produce the build since an exact version POM is built for us and packaged in the artifact with the version range one backed up. I can understand people being resistant to version ranges but with OSGi more and more jars are broken down into smaller components (and so projects) and version ranging really helps if you enforce semantic versioning between bundles. Nevertheless there is a problem with maven 3.0.3 when using version ranges. Ron On 21/06/2011 8:59 AM, Benson Margulies wrote: Yes this came to the list. *someone* is going to have to run yourkit or jprofiler on a real version of your problem. Of course, the person best positioned to do that would be, ahem, you. Unless you could give access to, well, me. It would be a giant public service for there to be a sufficiently complex example of this sort of thing available for development and testing, and it would pay your organization off in the long run in terms of maven working better for you. On Tue, Jun 21, 2011 at 6:42 AM, Paul Frenchpaul.fre...@kirona.com wrote: Thanks for reply - see inline On 21/06/2011 11:27, B Smith-Mannschott wrote: On Mon, Jun 20, 2011 at 19:54, Paul Frenchpaul.fre...@kirona.comwrote: Below is some filtered output from a maven build (showing maven meta data being downloaded for one artifact). All my dependencies use version ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT) In general the build fails with out of memory. I can increase the heap size and the build is successful, but a relatively simple build is now requiring 500MB heap size. First question is why is maven re-checking and downloading the same meta data over and over again? If I add additional version ranged dependencies to my pom then the problem seems to get exponentially worse. For a larger build so many requests are made so quickly to the nexus remote repository that I start to see Error transferring file: Address already in use: connect. Any ideas how to reduce the memory usage? Do not say do not use version ranges. We use semantic versioning enforced by API analysis tools for each of our modules (OSGi bundles) so we require version ranges. If I change all version range dependencies to an exact dependency (a serious amount of pom editing) then all is fine. As you can tell below we have 3 main internal remote repos setup (kirona, kirona-snapshot and third.party.libraries). We do not specify version ranges on libraries that are not in our control e.g. log4j etc etc Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 21.6 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 6.6 KB/sec) Downloading
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
On 21/06/2011 9:45 AM, Paul French wrote: On 21/06/2011 14:25, Ron Wheeler wrote: 500Mb is not a lot of memory for a Java program. It is when all I can give eclipse is 900MB. Beyond that the JVM fails to start. M2E as far as I know does not start a new JVM when building. Perhaps someone else can settle this. http://maven.40175.n5.nabble.com/setting-java-memory-options-for-m2-plugin-td138828.html seems to indicate that Maven runs in its own JVM with its own memory configuration. We have noticed that some libraries such as Apache's CXF webservices will require additional memory to be added to Maven if you are building applications that include it. Since virtual memory is virtually free, you might as well just accept reality and increase the VM. I can not imagine anyone doing software development with a modern IDE that would have trouble finding 1Gb of VM. On my 2GB laptop all I can give eclipse is 900MB You are mixing real and virtual. You can give it as much virtual as you need and it will find the real memory (usually a lot less) that it can use. You should have your Windows VM set to at least 4Gb on a 2Gb RAM laptop doing software development. All our guys have 2Gb laptops and can set virtual memory to 1 Gb for Eclipse and 1 Gb for the JVMs that it spawns. It is only for a short time anyway and what else are you trying to do while it builds? You want it to use every bit of real RAM that it needs to finish quickly. Anyway, there is nothing that you can do to make it use less memory unless you want to break your builds down and even then, you may need libraries like CXF that just take a lot VM to build. Ron We build under Eclipse STS but I don't think that it makes any difference since Maven is running in its own VM. I would not use version ranges since I like to know what I am putting into production. Once you initially set the versions of what you are supporting, it is not difficult to maintain that list as you work your way through new versions of third party code. We do it at the start of each of our release cycles. We usually stick with the existing set from the last release unless there is a reason to move. The version configuration for a new release is setup and managed by the entire team (small part of the release startup) and unless something catches fire, we stick with our set throughout the life of our release. We have 100's of bundles and usually most in flux. Someone put's a bug fix in a bundle, I do not want to have to *know*, as long as it is compatible with what I require which we automatically enforce via PDE API analysis tooling. At release time we know what is delivered and can re-produce the build since an exact version POM is built for us and packaged in the artifact with the version range one backed up. I can understand people being resistant to version ranges but with OSGi more and more jars are broken down into smaller components (and so projects) and version ranging really helps if you enforce semantic versioning between bundles. Nevertheless there is a problem with maven 3.0.3 when using version ranges. Ron On 21/06/2011 8:59 AM, Benson Margulies wrote: Yes this came to the list. *someone* is going to have to run yourkit or jprofiler on a real version of your problem. Of course, the person best positioned to do that would be, ahem, you. Unless you could give access to, well, me. It would be a giant public service for there to be a sufficiently complex example of this sort of thing available for development and testing, and it would pay your organization off in the long run in terms of maven working better for you. On Tue, Jun 21, 2011 at 6:42 AM, Paul Frenchpaul.fre...@kirona.com wrote: Thanks for reply - see inline On 21/06/2011 11:27, B Smith-Mannschott wrote: On Mon, Jun 20, 2011 at 19:54, Paul Frenchpaul.fre...@kirona.comwrote: Below is some filtered output from a maven build (showing maven meta data being downloaded for one artifact). All my dependencies use version ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT) In general the build fails with out of memory. I can increase the heap size and the build is successful, but a relatively simple build is now requiring 500MB heap size. First question is why is maven re-checking and downloading the same meta data over and over again? If I add additional version ranged dependencies to my pom then the problem seems to get exponentially worse. For a larger build so many requests are made so quickly to the nexus remote repository that I start to see Error transferring file: Address already in use: connect. Any ideas how to reduce the memory usage? Do not say do not use version ranges. We use semantic versioning enforced by API analysis tools for each of our modules (OSGi bundles) so we require version ranges. If I change all version range dependencies to an exact dependency (a serious amount of pom editing) then all is fine
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
Hello Ron, thanks for your comments. See inline comments. Cheers On 21/06/2011 15:38, Ron Wheeler wrote: On 21/06/2011 9:45 AM, Paul French wrote: On 21/06/2011 14:25, Ron Wheeler wrote: 500Mb is not a lot of memory for a Java program. It is when all I can give eclipse is 900MB. Beyond that the JVM fails to start. M2E as far as I know does not start a new JVM when building. Perhaps someone else can settle this. http://maven.40175.n5.nabble.com/setting-java-memory-options-for-m2-plugin-td138828.html seems to indicate that Maven runs in its own JVM with its own memory configuration. I hope you are right. But that particular post is for launching maven externally to eclipse. The m2e plugin itself uses an embedded maven for dependency management. It is the dependency management that is failing with out of memory. We have noticed that some libraries such as Apache's CXF webservices will require additional memory to be added to Maven if you are building applications that include it. Since virtual memory is virtually free, you might as well just accept reality and increase the VM. I can not imagine anyone doing software development with a modern IDE that would have trouble finding 1Gb of VM. On my 2GB laptop all I can give eclipse is 900MB You are mixing real and virtual. You can give it as much virtual as you need and it will find the real memory (usually a lot less) that it can use. You should have your Windows VM set to at least 4Gb on a 2Gb RAM laptop doing software development. I'm not mixing real and virtual. I was just indicating the maximum amount of memory I could give eclipse on my laptop. I don't care whether it is real or virtual I let windows handle that. If someone can tell me how I can give eclipse more then a 1G of memory (windows XP) then that would be great. At the moment I use a shortcut: eclipse.exe -vmargs -Xmx900M If I set to 1000M then the JVM fails to start. All our guys have 2Gb laptops and can set virtual memory to 1 Gb for Eclipse and 1 Gb for the JVMs that it spawns. It is only for a short time anyway and what else are you trying to do while it builds? You want it to use every bit of real RAM that it needs to finish quickly. Anyway, there is nothing that you can do to make it use less memory unless you want to break your builds down and even then, you may need libraries like CXF that just take a lot VM to build. Ron We build under Eclipse STS but I don't think that it makes any difference since Maven is running in its own VM. I would not use version ranges since I like to know what I am putting into production. Once you initially set the versions of what you are supporting, it is not difficult to maintain that list as you work your way through new versions of third party code. We do it at the start of each of our release cycles. We usually stick with the existing set from the last release unless there is a reason to move. The version configuration for a new release is setup and managed by the entire team (small part of the release startup) and unless something catches fire, we stick with our set throughout the life of our release. We have 100's of bundles and usually most in flux. Someone put's a bug fix in a bundle, I do not want to have to *know*, as long as it is compatible with what I require which we automatically enforce via PDE API analysis tooling. At release time we know what is delivered and can re-produce the build since an exact version POM is built for us and packaged in the artifact with the version range one backed up. I can understand people being resistant to version ranges but with OSGi more and more jars are broken down into smaller components (and so projects) and version ranging really helps if you enforce semantic versioning between bundles. Nevertheless there is a problem with maven 3.0.3 when using version ranges. Ron On 21/06/2011 8:59 AM, Benson Margulies wrote: Yes this came to the list. *someone* is going to have to run yourkit or jprofiler on a real version of your problem. Of course, the person best positioned to do that would be, ahem, you. Unless you could give access to, well, me. It would be a giant public service for there to be a sufficiently complex example of this sort of thing available for development and testing, and it would pay your organization off in the long run in terms of maven working better for you. On Tue, Jun 21, 2011 at 6:42 AM, Paul Frenchpaul.fre...@kirona.com wrote: Thanks for reply - see inline On 21/06/2011 11:27, B Smith-Mannschott wrote: On Mon, Jun 20, 2011 at 19:54, Paul Frenchpaul.fre...@kirona.comwrote: Below is some filtered output from a maven build (showing maven meta data being downloaded for one artifact). All my dependencies use version ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT) In general the build fails with out of memory. I can increase the heap size and the build is successful
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
On 21/06/2011 10:55 AM, Paul French wrote: Hello Ron, thanks for your comments. See inline comments. Cheers On 21/06/2011 15:38, Ron Wheeler wrote: On 21/06/2011 9:45 AM, Paul French wrote: On 21/06/2011 14:25, Ron Wheeler wrote: 500Mb is not a lot of memory for a Java program. It is when all I can give eclipse is 900MB. Beyond that the JVM fails to start. M2E as far as I know does not start a new JVM when building. Perhaps someone else can settle this. http://maven.40175.n5.nabble.com/setting-java-memory-options-for-m2-plugin-td138828.html seems to indicate that Maven runs in its own JVM with its own memory configuration. I hope you are right. But that particular post is for launching maven externally to eclipse. The m2e plugin itself uses an embedded maven for dependency management. It is the dependency management that is failing with out of memory. That is something that I have never seen but we have broken our portal application into over 70 separately-built modules and have built aggregation projects to create libraries of third party dependencies. For example, we have a single jar for Spring, Hibernate and MySQL since almost every one of our projects need these. This is referenced as single provided dependency since we only install 1 copy in the Tomcat shared library. When combined with proper exclusions in the creation of the library (no need for 70 copies of commons-logging) , our dependency graphs are very small and our builds very fast even if the module requires 70 or more third party libraries to compile and run. We have noticed that some libraries such as Apache's CXF webservices will require additional memory to be added to Maven if you are building applications that include it. Since virtual memory is virtually free, you might as well just accept reality and increase the VM. I can not imagine anyone doing software development with a modern IDE that would have trouble finding 1Gb of VM. On my 2GB laptop all I can give eclipse is 900MB You are mixing real and virtual. You can give it as much virtual as you need and it will find the real memory (usually a lot less) that it can use. You should have your Windows VM set to at least 4Gb on a 2Gb RAM laptop doing software development. I'm not mixing real and virtual. I was just indicating the maximum amount of memory I could give eclipse on my laptop. I don't care whether it is real or virtual I let windows handle that. If someone can tell me how I can give eclipse more then a 1G of memory (windows XP) then that would be great. At the moment I use a shortcut: eclipse.exe -vmargs -Xmx900M If I set to 1000M then the JVM fails to start. All our guys have 2Gb laptops and can set virtual memory to 1 Gb for Eclipse and 1 Gb for the JVMs that it spawns. It is only for a short time anyway and what else are you trying to do while it builds? You want it to use every bit of real RAM that it needs to finish quickly. Anyway, there is nothing that you can do to make it use less memory unless you want to break your builds down and even then, you may need libraries like CXF that just take a lot VM to build. Ron We build under Eclipse STS but I don't think that it makes any difference since Maven is running in its own VM. I would not use version ranges since I like to know what I am putting into production. Once you initially set the versions of what you are supporting, it is not difficult to maintain that list as you work your way through new versions of third party code. We do it at the start of each of our release cycles. We usually stick with the existing set from the last release unless there is a reason to move. The version configuration for a new release is setup and managed by the entire team (small part of the release startup) and unless something catches fire, we stick with our set throughout the life of our release. We have 100's of bundles and usually most in flux. Someone put's a bug fix in a bundle, I do not want to have to *know*, as long as it is compatible with what I require which we automatically enforce via PDE API analysis tooling. At release time we know what is delivered and can re-produce the build since an exact version POM is built for us and packaged in the artifact with the version range one backed up. I can understand people being resistant to version ranges but with OSGi more and more jars are broken down into smaller components (and so projects) and version ranging really helps if you enforce semantic versioning between bundles. Nevertheless there is a problem with maven 3.0.3 when using version ranges. Ron On 21/06/2011 8:59 AM, Benson Margulies wrote: Yes this came to the list. *someone* is going to have to run yourkit or jprofiler on a real version of your problem. Of course, the person best positioned to do that would be, ahem, you. Unless you could give access to, well, me. It would be a giant public service
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
in the artifact with the version range one backed up. I can understand people being resistant to version ranges but with OSGi more and more jars are broken down into smaller components (and so projects) and version ranging really helps if you enforce semantic versioning between bundles. Nevertheless there is a problem with maven 3.0.3 when using version ranges. Ron On 21/06/2011 8:59 AM, Benson Margulies wrote: Yes this came to the list. *someone* is going to have to run yourkit or jprofiler on a real version of your problem. Of course, the person best positioned to do that would be, ahem, you. Unless you could give access to, well, me. It would be a giant public service for there to be a sufficiently complex example of this sort of thing available for development and testing, and it would pay your organization off in the long run in terms of maven working better for you. On Tue, Jun 21, 2011 at 6:42 AM, Paul Frenchpaul.fre...@kirona.com wrote: Thanks for reply - see inline On 21/06/2011 11:27, B Smith-Mannschott wrote: On Mon, Jun 20, 2011 at 19:54, Paul Frenchpaul.fre...@kirona.com wrote: Below is some filtered output from a maven build (showing maven meta data being downloaded for one artifact). All my dependencies use version ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT) In general the build fails with out of memory. I can increase the heap size and the build is successful, but a relatively simple build is now requiring 500MB heap size. First question is why is maven re-checking and downloading the same meta data over and over again? If I add additional version ranged dependencies to my pom then the problem seems to get exponentially worse. For a larger build so many requests are made so quickly to the nexus remote repository that I start to see Error transferring file: Address already in use: connect. Any ideas how to reduce the memory usage? Do not say do not use version ranges. We use semantic versioning enforced by API analysis tools for each of our modules (OSGi bundles) so we require version ranges. If I change all version range dependencies to an exact dependency (a serious amount of pom editing) then all is fine. As you can tell below we have 3 main internal remote repos setup (kirona, kirona-snapshot and third.party.libraries). We do not specify version ranges on libraries that are not in our control e.g. log4j etc etc Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 21.6 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 6.6 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 10.0 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 11.2 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 9.7 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 10.8 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/serve... The above problems renders eclipse useless with m2e, it causes eclipse to hang on start up (build automatically set to true) and eventually die!! I'm starting to come
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
On Wed, Jun 22, 2011 at 1:02 AM, Benson Margulies bimargul...@gmail.com wrote: The current version of m2e runs mvn embeded inside the eclipse jvm. Because eclipse has one classloader isolation system, and maven has another, the sum total is a wildly effective recipe for running out of VM. And while you are getting some answers here about your problem, you really need to ask on the m2e mailing list. (m2e != maven) You are missing access to the most experienced audience by asking here. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
From what I can understand this issue is almost certainly some kind of combinatorial explosion caused in the calculation of the dependencies. Sample project/and or heap dumps will be required here as far as I can understand. As for the embedded building, you might want to take note that plexus-utils 2.1 fixes a memory leak wrt embedding. This has been released in surefire 2.9. maven-scm and the xAR plugins also have the same problem and can be fixed by upgrading the plexus-utils dependency to 2.1 in these plugins. Kristian - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads
Below is some filtered output from a maven build (showing maven meta data being downloaded for one artifact). All my dependencies use version ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT) In general the build fails with out of memory. I can increase the heap size and the build is successful, but a relatively simple build is now requiring 500MB heap size. First question is why is maven re-checking and downloading the same meta data over and over again? If I add additional version ranged dependencies to my pom then the problem seems to get exponentially worse. For a larger build so many requests are made so quickly to the nexus remote repository that I start to see Error transferring file: Address already in use: connect. Any ideas how to reduce the memory usage? Do not say do not use version ranges. We use semantic versioning enforced by API analysis tools for each of our modules (OSGi bundles) so we require version ranges. If I change all version range dependencies to an exact dependency (a serious amount of pom editing) then all is fine. As you can tell below we have 3 main internal remote repos setup (kirona, kirona-snapshot and third.party.libraries). We do not specify version ranges on libraries that are not in our control e.g. log4j etc etc Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 21.6 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 6.6 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 10.0 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 11.2 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml Downloading: http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml Downloaded: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml (318 B at 9.7 KB/sec) Downloaded: http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml (354 B at 10.8 KB/sec) Downloading: http://fuji:8081/nexus/content/repositories/kirona/com/kirona/serve... The above problems renders eclipse useless with m2e, it causes eclipse to hang on start up (build automatically set to true) and eventually die!! I'm starting to come to the conclusion that between maven and m2e version ranges just do not work very well. I hope I am wrong!! Thanks Paul - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 doesn't copy metadata xml *.jdo to target during install
Thankyou Mathew and Wayne it did copy from resources directory my point was to have it within the src so that evry package has its corresponding jdo files in the same place. Thanks, -Viv On Tue, Jun 7, 2011 at 3:00 AM, Wayne Fay wayne...@gmail.com wrote: maven install doesn't copy the metadata xml files to target ?? Do we need to place the *.jdo files in the resources directory ?? By default, Maven will compile .java files under src/main/java and put the compiled class files in the proper directory under target. And Maven will copy files from src/main/resources directly into those same directories under target. So the easiest fix is to just move those .jdo files to s/m/resources. You can also configure things in your pom file so the files are copied from under s/m/java but this only complicates things and is unnecessary in most situations. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 doesn't copy metadata xml *.jdo to target during install
not the maven way... if you don't like the maven way then there is always ant - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 7 Jun 2011 07:34, Vivek Ganesh V.T vyv...@gmail.com wrote:
Re: Maven 3.0.3 doesn't copy metadata xml *.jdo to target during install
Thankyou Mathew and Wayne it did copy from resources directory my point was to have it within the src so that evry package has its corresponding jdo files in the same place. As I stated before: You can also configure things in your pom file so the files are copied from under s/m/java but this only complicates things and is I am sure you can find what you are looking for with a little help from Google. What you want is possible but its not the recommended approach. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 doesn't copy metadata xml *.jdo to target during install
While this is more a Maven question than a JDO one, I'd say that, yes, placing the *.jdo files in src/main/resources will guarantee that they'll be copied to the target directory properly. -matthew On Sat, Jun 4, 2011 at 2:57 PM, Vivek Ganesh V.T vyv...@gmail.com wrote: Using Maven-datanuclues-plugin maven install doesn't copy the metadata xml files to target ?? Do we need to place the *.jdo files in the resources directory ?? Current Directory Structure - Project - src- main- java- *.java , *.jdo Thanks, -Viv -- @matthewadams12 mailto:matt...@matthewadams.me skype:matthewadams12 yahoo:matthewadams aol:matthewadams12 google-talk:matthewadam...@gmail.com msn:matt...@matthewadams.me http://matthewadams.me http://www.linkedin.com/in/matthewadams - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 doesn't copy metadata xml *.jdo to target during install
maven install doesn't copy the metadata xml files to target ?? Do we need to place the *.jdo files in the resources directory ?? By default, Maven will compile .java files under src/main/java and put the compiled class files in the proper directory under target. And Maven will copy files from src/main/resources directly into those same directories under target. So the easiest fix is to just move those .jdo files to s/m/resources. You can also configure things in your pom file so the files are copied from under s/m/java but this only complicates things and is unnecessary in most situations. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven 3.0.3 doesn't copy metadata xml *.jdo to target during install
Using Maven-datanuclues-plugin maven install doesn't copy the metadata xml files to target ?? Do we need to place the *.jdo files in the resources directory ?? Current Directory Structure - Project - src- main- java- *.java , *.jdo Thanks, -Viv
RE: Issue running mvn deploy using Maven 3.0.3
Thanks Anders. I will take this to nexus. -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Wednesday, June 01, 2011 1:52 AM To: Maven Users List Subject: Re: Issue running mvn deploy using Maven 3.0.3 I think you should move this discussion to the Nexus users list. The nexus people should be able to give you a quick answer if it's a Nexus issue or something else. /Anders On Tue, May 31, 2011 at 17:47, Henika Tekwani htekw...@adobe.com wrote: Thanks Anders for the updates. Not sure if I found the particular link that you were referring to. Was it https://issues.sonatype.org/browse/NEXUS-3573 ? Are you trying to say that the issue is at Sonatype's end? Is there a way to increase the timeout? Thanks Henika -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Monday, May 30, 2011 11:22 PM To: Maven Users List Subject: Re: Issue running mvn deploy using Maven 3.0.3 I don't have the answer for you, but I recall seeing a similar question before. I think it was on the Nexus users list. You can find info about the archive at [1]. /Anders [1] http://nexus.sonatype.org/project-information.html On Mon, May 30, 2011 at 17:35, Henika Tekwani htekw...@adobe.com wrote: Any updates on this? From: Henika Tekwani Sent: Monday, May 30, 2011 10:26 AM To: Maven Users List Cc: Henika Tekwani Subject: Issue running mvn deploy using Maven 3.0.3 Hi, I have a maven project that generates a 363 MB jar artifact. I am getting following error while deploying the artifact to our nexus repository: Could not transfer artifact test:test:jar:10.0.0 from/to releases ( http://localhost.corp.adobe.com/nexus/content/repositories/releases): No response received after 6 - [Help 1] The above error is observed when I run my project using MAVEN 3.0.3. But when I run the same project using MAVEN 2.2.1, the artifact deploys successfully. Has anything changed from Maven 2.2.1 to Maven 3.0.3? Do I need to make any additional configuration settings? I tried using Webdav based wagon but that also doesn't solve the issue. Any clue what could be the issue? Thanks Henika - 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
RE: Issue running mvn deploy using Maven 3.0.3
Thanks Anders for the updates. Not sure if I found the particular link that you were referring to. Was it https://issues.sonatype.org/browse/NEXUS-3573 ? Are you trying to say that the issue is at Sonatype's end? Is there a way to increase the timeout? Thanks Henika -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Monday, May 30, 2011 11:22 PM To: Maven Users List Subject: Re: Issue running mvn deploy using Maven 3.0.3 I don't have the answer for you, but I recall seeing a similar question before. I think it was on the Nexus users list. You can find info about the archive at [1]. /Anders [1] http://nexus.sonatype.org/project-information.html On Mon, May 30, 2011 at 17:35, Henika Tekwani htekw...@adobe.com wrote: Any updates on this? From: Henika Tekwani Sent: Monday, May 30, 2011 10:26 AM To: Maven Users List Cc: Henika Tekwani Subject: Issue running mvn deploy using Maven 3.0.3 Hi, I have a maven project that generates a 363 MB jar artifact. I am getting following error while deploying the artifact to our nexus repository: Could not transfer artifact test:test:jar:10.0.0 from/to releases ( http://localhost.corp.adobe.com/nexus/content/repositories/releases): No response received after 6 - [Help 1] The above error is observed when I run my project using MAVEN 3.0.3. But when I run the same project using MAVEN 2.2.1, the artifact deploys successfully. Has anything changed from Maven 2.2.1 to Maven 3.0.3? Do I need to make any additional configuration settings? I tried using Webdav based wagon but that also doesn't solve the issue. Any clue what could be the issue? Thanks Henika - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Issue running mvn deploy using Maven 3.0.3
I think you should move this discussion to the Nexus users list. The nexus people should be able to give you a quick answer if it's a Nexus issue or something else. /Anders On Tue, May 31, 2011 at 17:47, Henika Tekwani htekw...@adobe.com wrote: Thanks Anders for the updates. Not sure if I found the particular link that you were referring to. Was it https://issues.sonatype.org/browse/NEXUS-3573 ? Are you trying to say that the issue is at Sonatype's end? Is there a way to increase the timeout? Thanks Henika -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Monday, May 30, 2011 11:22 PM To: Maven Users List Subject: Re: Issue running mvn deploy using Maven 3.0.3 I don't have the answer for you, but I recall seeing a similar question before. I think it was on the Nexus users list. You can find info about the archive at [1]. /Anders [1] http://nexus.sonatype.org/project-information.html On Mon, May 30, 2011 at 17:35, Henika Tekwani htekw...@adobe.com wrote: Any updates on this? From: Henika Tekwani Sent: Monday, May 30, 2011 10:26 AM To: Maven Users List Cc: Henika Tekwani Subject: Issue running mvn deploy using Maven 3.0.3 Hi, I have a maven project that generates a 363 MB jar artifact. I am getting following error while deploying the artifact to our nexus repository: Could not transfer artifact test:test:jar:10.0.0 from/to releases ( http://localhost.corp.adobe.com/nexus/content/repositories/releases): No response received after 6 - [Help 1] The above error is observed when I run my project using MAVEN 3.0.3. But when I run the same project using MAVEN 2.2.1, the artifact deploys successfully. Has anything changed from Maven 2.2.1 to Maven 3.0.3? Do I need to make any additional configuration settings? I tried using Webdav based wagon but that also doesn't solve the issue. Any clue what could be the issue? Thanks Henika - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Issue running mvn deploy using Maven 3.0.3
Any updates on this? From: Henika Tekwani Sent: Monday, May 30, 2011 10:26 AM To: Maven Users List Cc: Henika Tekwani Subject: Issue running mvn deploy using Maven 3.0.3 Hi, I have a maven project that generates a 363 MB jar artifact. I am getting following error while deploying the artifact to our nexus repository: Could not transfer artifact test:test:jar:10.0.0 from/to releases (http://localhost.corp.adobe.com/nexus/content/repositories/releases): No response received after 6 - [Help 1] The above error is observed when I run my project using MAVEN 3.0.3. But when I run the same project using MAVEN 2.2.1, the artifact deploys successfully. Has anything changed from Maven 2.2.1 to Maven 3.0.3? Do I need to make any additional configuration settings? I tried using Webdav based wagon but that also doesn't solve the issue. Any clue what could be the issue? Thanks Henika
Re: Issue running mvn deploy using Maven 3.0.3
I don't have the answer for you, but I recall seeing a similar question before. I think it was on the Nexus users list. You can find info about the archive at [1]. /Anders [1] http://nexus.sonatype.org/project-information.html On Mon, May 30, 2011 at 17:35, Henika Tekwani htekw...@adobe.com wrote: Any updates on this? From: Henika Tekwani Sent: Monday, May 30, 2011 10:26 AM To: Maven Users List Cc: Henika Tekwani Subject: Issue running mvn deploy using Maven 3.0.3 Hi, I have a maven project that generates a 363 MB jar artifact. I am getting following error while deploying the artifact to our nexus repository: Could not transfer artifact test:test:jar:10.0.0 from/to releases ( http://localhost.corp.adobe.com/nexus/content/repositories/releases): No response received after 6 - [Help 1] The above error is observed when I run my project using MAVEN 3.0.3. But when I run the same project using MAVEN 2.2.1, the artifact deploys successfully. Has anything changed from Maven 2.2.1 to Maven 3.0.3? Do I need to make any additional configuration settings? I tried using Webdav based wagon but that also doesn't solve the issue. Any clue what could be the issue? Thanks Henika
Issue running mvn deploy using Maven 3.0.3
Hi, I have a maven project that generates a 363 MB jar artifact. I am getting following error while deploying the artifact to our nexus repository: Could not transfer artifact test:test:jar:10.0.0 from/to releases (http://localhost.corp.adobe.com/nexus/content/repositories/releases): No response received after 6 - [Help 1] The above error is observed when I run my project using MAVEN 3.0.3. But when I run the same project using MAVEN 2.2.1, the artifact deploys successfully. Has anything changed from Maven 2.2.1 to Maven 3.0.3? Do I need to make any additional configuration settings? I tried using Webdav based wagon but that also doesn't solve the issue. Any clue what could be the issue? Thanks Henika
maven 3.0.3
Hi to all, I am working with maven 3.0.3, windows 7. I need to install plugin's maven, any idea? Thanks, Yos
Re: maven 3.0.3
Your request doesn't make any sense to me. Could you please describe what you want to accomplish? With regards, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Tue, May 24, 2011 at 1:42 PM, Brosh, Yossi yossi.br...@sap.com wrote: Hi to all, I am working with maven 3.0.3, windows 7. I need to install plugin's maven, any idea? Thanks, Yos - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: maven 3.0.3
I need to install : maven-deploy-plugin , in order to run maven deploy Best regards, Yossi -Original Message- From: Nick Stolwijk [mailto:nick.stolw...@gmail.com] Sent: Tuesday, May 24, 2011 2:59 PM To: Maven Users List Subject: Re: maven 3.0.3 Your request doesn't make any sense to me. Could you please describe what you want to accomplish? With regards, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Tue, May 24, 2011 at 1:42 PM, Brosh, Yossi yossi.br...@sap.com wrote: Hi to all, I am working with maven 3.0.3, windows 7. I need to install plugin's maven, any idea? Thanks, Yos - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven 3.0.3
Maven will get its plugins and dependencies from the configured repositories. The default repository is central. You'll need an internet connection to let Maven retrieve the plugins from there. If you use a proxy, you need to configure Maven to use that too. This can be done in ~/.m2/settings.xml for your own user or globally on your PC in MAVEN_HOME/conf/settings.xml. I would suggest you start with the documentation and the various books[2], especially [3] [1] http://maven.apache.org/users/index.html [2] http://maven.apache.org/articles.html [3] http://www.sonatype.com/books/maven-book/ Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Tue, May 24, 2011 at 2:23 PM, Brosh, Yossi yossi.br...@sap.com wrote: I need to install : maven-deploy-plugin , in order to run maven deploy Best regards, Yossi -Original Message- From: Nick Stolwijk [mailto:nick.stolw...@gmail.com] Sent: Tuesday, May 24, 2011 2:59 PM To: Maven Users List Subject: Re: maven 3.0.3 Your request doesn't make any sense to me. Could you please describe what you want to accomplish? With regards, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Tue, May 24, 2011 at 1:42 PM, Brosh, Yossi yossi.br...@sap.com wrote: Hi to all, I am working with maven 3.0.3, windows 7. I need to install plugin's maven, any idea? Thanks, Yos - 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
Re: Maven 3.0.3 hanging / having timeouts often?
Any advice on this? Should I be opening a maven bug? It is really killing my productivity as I have to babysit every build and keep aborting it and restarting it several times until all updates (mostly snapshots per day) are downloaded. Thanks, Andrew On Thu, May 12, 2011 at 5:39 AM, Alex Lopez alo...@flordeutopia.pt wrote: Em 12-05-2011 12:02, Tim Pizey escreveu: On 12 May 2011 11:50, Alex Lopez wrote: Em 12-05-2011 01:22, Andrew Robinson escreveu: I have been using maven 2.2.1 for a while at my company and we just switched to maven 3. I have rebuilt my computer (ubuntu maverick 10.04 32-bit == ubuntu natty 11.04 64-bit) and installed maven 3. In maven 3.0.3, (I have not seen it with maven 2.2.1), it stops downloading after a few to several downloads. If I ^C the build, and keep re-running it, +1, I've been having this kind of 'hangs', using maven 3.0.2 and artifactory 2.3.1 (sometimes when running maven site, sometimes performing a build), then ^C seems to get maven to continue doing what it was doing and eventually end with success... Me too, on win7/cygwin. I thought it was a cygwin problem. +1 now that I think about that it seems definitely like a cygwin problem, since I'm never getting this through m2eclipse... could it be related with the warning cygwin gives me complaining about bad ms-dos style paths? $ mvn site site:stage cygwin warning: MS-DOS style path detected: C:\Program Files\Apache Software Foundation\apache-maven-3.0.2/boot/ Preferred POSIX equivalent is: /cygdrive/c/Program Files/Apache Software Foundation/apache-maven-3.0.2/boot/ ... cheers - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
Any advice on this? Should I be opening a maven bug? It is really killing my productivity as I have to babysit every build and keep aborting it and restarting it several times until all updates (mostly snapshots per day) are downloaded. If this was typical then we would see similar complaints from lots of people. Clearly something is special about the way you have things configured or something else in your environment. I'm not sure how you expect anyone here to diagnose this class of problem. Did you reconfigure your proxy and settings.xml so all requests are going through Archiva? I see that as a pre-requisite before talking about anything else. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
Archiva is being used to serve our internal packages of our company, it is not being used to serve dependencies from internet repositories. So no I cannot send all requests through Archiva. It may be as simple as a linux kernel issue with e1000e driver (dell latitude E6410). It has caused me issues in Ubuntu in 10.10 and could be still some issues in 11.04. It is hard to say as there is not much to debug with at this point and I am not seeing any obvious system errors or anything to troubleshoot with. On Mon, May 16, 2011 at 10:34 AM, Wayne Fay wayne...@gmail.com wrote: Any advice on this? Should I be opening a maven bug? It is really killing my productivity as I have to babysit every build and keep aborting it and restarting it several times until all updates (mostly snapshots per day) are downloaded. If this was typical then we would see similar complaints from lots of people. Clearly something is special about the way you have things configured or something else in your environment. I'm not sure how you expect anyone here to diagnose this class of problem. Did you reconfigure your proxy and settings.xml so all requests are going through Archiva? I see that as a pre-requisite before talking about anything else. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
Unless you can post a project to github that demonstrates differential behavior everywhere, or use mvn -X or wireshark to deliver an analysis of *how* 3.0.3 is hitting the network differently than 2.2.1, you're unlikely to get much succor here. It would really help you if you could convince your corporate Archiva-ists to configure it to work as a cache for the internet. Or if you quietly put a copy of Archiva or Nexus for those purposes on your own machine :-) On Mon, May 16, 2011 at 12:54 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: Archiva is being used to serve our internal packages of our company, it is not being used to serve dependencies from internet repositories. So no I cannot send all requests through Archiva. It may be as simple as a linux kernel issue with e1000e driver (dell latitude E6410). It has caused me issues in Ubuntu in 10.10 and could be still some issues in 11.04. It is hard to say as there is not much to debug with at this point and I am not seeing any obvious system errors or anything to troubleshoot with. On Mon, May 16, 2011 at 10:34 AM, Wayne Fay wayne...@gmail.com wrote: Any advice on this? Should I be opening a maven bug? It is really killing my productivity as I have to babysit every build and keep aborting it and restarting it several times until all updates (mostly snapshots per day) are downloaded. If this was typical then we would see similar complaints from lots of people. Clearly something is special about the way you have things configured or something else in your environment. I'm not sure how you expect anyone here to diagnose this class of problem. Did you reconfigure your proxy and settings.xml so all requests are going through Archiva? I see that as a pre-requisite before talking about anything else. Wayne - 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
Re: Maven 3.0.3 hanging / having timeouts often?
On Tue, May 17, 2011 at 3:04 AM, Benson Margulies bimargul...@gmail.com wrote: Or if you quietly put a copy of Archiva or Nexus for those purposes on your own machine :-) Running a repository manager locally is a smart idea if you are on a laptop. Saves you the pain of reconfiguring maven when you unplug from the network. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
Running a local nexus means never having to say --offline On Mon, May 16, 2011 at 7:43 PM, Barrie Treloar baerr...@gmail.com wrote: On Tue, May 17, 2011 at 3:04 AM, Benson Margulies bimargul...@gmail.com wrote: Or if you quietly put a copy of Archiva or Nexus for those purposes on your own machine :-) Running a repository manager locally is a smart idea if you are on a laptop. Saves you the pain of reconfiguring maven when you unplug from the network. - 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
Re: Incorrect assembly created with Maven 3.0.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, finally got ClassNotFoundException because of a missing dependency Jar in the lib folder; more precisely xalan:serializer:2.7.1 PS: I tested it with Maven 3.0.3 using Java 1.6.0_24, first on Solaris 11 Express and then on Mac OS X 10.6.7. Xalan and Xerces are special since they have been absorbed into the JVM as of 1.4. In 1.5 they were basically shaded so now they are under com.sun.* instead of directly under org.apache.* which was causing problems. Xalan and Xerces are actually included because the versions in 1.4 / 1.5 are older than those available at apache.org. As far as I know they are needed by some legacy code for (de-)serialization of objects. I don't know if it is feasible to replace that code in short or mid term to make (better) usage of the capabilities provided directly by Java 6. What class specifically is giving you the CNFE? I'm at home so I can't tell what class was causing this error. I'll see Monday when I'm at work, but I guess it was something like org/apache/xml/serializer/Serializer Are you building and then running your code with the same version etc of the JVM? Yes. But what puzzles me is that the archives created by Maven 2.2.1 and Maven 3.0.3 are different, and I don't see a reason why... This may be a situation where a jdk-specific profile is kicking in and including (or not) a dependency during your build... or something else of course. I don't use any profile, and the in-house dependencies I'm using also don't make usage of profiles. Thorsten -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNzlPbAAoJEFpUu7h4Il4IQ+cP/0Hg0YYDc4Uu3eVTGMqPYWd9 GeKmiUNw/mZHcR56aAUG1xgCjxfvtX1Ub3SGGNn8TKF4fNMboQv+YE41Ze8ALVC7 uX1TBu8LeWO3gq3qP7McsTxZ/+aVjYqv3RigEWEs/gOv9Z+oei3hYl8/c+9sr/sq c1TU+A6dZqjsBeEnp0/lNoGvPV6fe/Dg+GuO9XVBZsPf7f8trL16vUPmAuyFaEoy awN0+ZneWbMi3Ye/bTw6cCqePXIJW9UasP4uN/+QuEHokNbLixyXjd5AQ9dQhOKm Ov3Nf2xaFa99XGi8lIqiX0ds548hC/Ub8B04/5yyv2bKcyxKcuoIa9oxYb1LlyBB PV8VOQuVhz++mjdYVe7g70NklXI4uLo7kCxnOsfd8XgFnoxUjjj646AKpbiOwzHH ACn1DVN2ijBDfmGmfracJo7nwkdbuEKGNIqivTg87S3EzZNATErTbSlBM4Y1Fj7+ tJb0J7SUcQBxWt4jiJBqOva0/S7l+tveQGezpIrdsv4/OglTy3vLvGNL9+J+GQlm nlBRxsFcCVJkmhViBhNjuFAx1M6+g7pEjjxETl7OaZKtWJ0lDcoxUxQ/POfC5RKS grhykOtrW1xU4qAJCzI4OJ72Qv9z9p/ORwGy5DAFaGAvTUK8ClzzZJRwznkilcBo kV7bX6nN+bDhTzp//8P9 =Yfmg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Incorrect assembly created with Maven 3.0.3
Hi, I have a strange problem when building an assembly with Maven 3.0.3, and I don't know where to debug...: My project uses a combination of the appassembler mojo (1.1.1) and assembly plugin (2.2.1), both attached to the package phase, to create a tar.gz archive that basically has the following structure: my-prg/ my-prg/bin/ my-prg/bin/my-prg.cmd my-prg/bin/my-prg.sh my-prg/bin/local-log4j.xml my-prg/bin/log4j.dtd my-prg/lib/ (lots of Jar files) my-prg/log/ my-prg/log/readme.txt An end user unzips the archive and starts the program by one of the shell scripts (.cmd for Windows, .sh for Unix). Today I released a new version of my program, and just before informing my colleages that it's available I tested it by myself from a Windows box and finally got ClassNotFoundException because of a missing dependency Jar in the lib folder; more precisely xalan:serializer:2.7.1 Looking into the tar.gz archive I couldn't see that jar although it is used as a transitive compile-time dependency somewhere in the dependency tree of my program. The latter is verifiable by for example mvn dependency:tree: thorsten$ mvn dependency:tree [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building my-prg 0.4.6 [INFO] [INFO] [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ my-prg --- [INFO] prg:my-prg:jar:0.4.6 ... [INFO] | +- lib:v-base:jar:1.8:compile [INFO] | | +- org.apache.axis:axis-saaj:jar:1.4:compile [INFO] | | +- commons-logging:commons-logging:jar:1.1.1:compile (version managed from 1.0.4) [INFO] | | +- commons-validator:commons-validator:jar:1.0.2:compile [INFO] | | | +- commons-beanutils:commons-beanutils:jar:1.5:compile [INFO] | | | \- commons-collections:commons-collections:jar:2.1:compile [INFO] | | +- commons-digester:commons-digester:jar:1.8:compile [INFO] | | +- oro:oro:jar:2.0.8:compile [INFO] | | +- commons-discovery:commons-discovery:jar:0.4:compile [INFO] | | +- wsdl4j:wsdl4j:jar:1.6.1:compile [INFO] | | +- xerces:xercesImpl:jar:2.9.1:compile [INFO] | | \- xalan:xalan:jar:2.7.1:compile [INFO] | | \- xalan:serializer:jar:2.7.1:compile ... For curiosity I did a mvn package on my project by using Maven 2.2.1 and exactly the same code base. Comparing the resulting archives shows an interesting phenomenon: * The archive created by Maven 3.0.3 contains a dependency to org.apache.xmlgraphics:batik-js:1.7 (not shown by dependency:tree) and is missing one to xalan:serializer:jar * The archive created by Maven 2.2.1 contains only those dependencies that are listed in the dependency tree with scope compile. From my pom.xml: (...) build resources resource directorysrc/main/resources/directory /resource resource targetPath../my-prg/targetPath /resource /resources plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.3.2/version configuration source1.6/source target1.6/target /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-deploy-plugin/artifactId version2.5/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.8/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.1/version!--$NO-MVN-MAN-VER$ -- /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-resources-plugin/artifactId version2.5/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-plugin/artifactId version1.5/version configuration providerImplementations cvscvs_native/cvs /providerImplementations goalsinstall/goals /configuration /plugin !-- plugin groupIdorg.apache.maven.plugins/groupId
Re: Incorrect assembly created with Maven 3.0.3
finally got ClassNotFoundException because of a missing dependency Jar in the lib folder; more precisely xalan:serializer:2.7.1 PS: I tested it with Maven 3.0.3 using Java 1.6.0_24, first on Solaris 11 Express and then on Mac OS X 10.6.7. Xalan and Xerces are special since they have been absorbed into the JVM as of 1.4. In 1.5 they were basically shaded so now they are under com.sun.* instead of directly under org.apache.* which was causing problems. What class specifically is giving you the CNFE? Are you building and then running your code with the same version etc of the JVM? This may be a situation where a jdk-specific profile is kicking in and including (or not) a dependency during your build... or something else of course. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
Em 12-05-2011 01:22, Andrew Robinson escreveu: I have been using maven 2.2.1 for a while at my company and we just switched to maven 3. I have rebuilt my computer (ubuntu maverick 10.04 32-bit == ubuntu natty 11.04 64-bit) and installed maven 3. In maven 3.0.3, (I have not seen it with maven 2.2.1), it stops downloading after a few to several downloads. If I ^C the build, and keep re-running it, +1, I've been having this kind of 'hangs', using maven 3.0.2 and artifactory 2.3.1 (sometimes when running maven site, sometimes performing a build), then ^C seems to get maven to continue doing what it was doing and eventually end with success... it will eventually built. It only dies when maven is trying to download file. It may happen before any progress is display, partial progress or full progress. Example: Downloading: http://internalserver.ouritranet.com:8086/archiva/repository/internal/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http:// internalserver.ouritranet.com:8086/archiva/repository/snapshots-corporate/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo2.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://www.ibiblio.org/maven/org/apache/maven/skins/maven-default-skin/maven-metadata.xml 341 B 341 B If I let it go for a while it then prints: Downloading: http://internalserver.ouritranet.com:8086/archiva/repository/internal/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://internalserver.ouritranet.com:8086/archiva/repository/snapshots-corporate/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo2.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://www.ibiblio.org/maven/org/apache/maven/skins/maven-default-skin/maven-metadata.xml [WARNING] Checksum validation failed, could not read expected checksum: Error transferring file: Connection timed out for http://repo1.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml [WARNING] Checksum validation failed, could not read expected checksum: Error transferring file: Connection timed out for http://repo2.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml My other co-workers have not reported seeing this issue yet. Any ideas on why maven 3.0.3 is having this problem when maven 2.2.1 does not? FYI, we have a corporate proxy, not sure if that could be part of the problem. -Andrew - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
Now this got me thinking, my intuition is that this might be a network related problem... maybe maven 2 had shorter timeouts, hence not appearing to hang, does Maven 3 download more than one dependency at the same time? Does this behavior differ from version 2? Why hitting ^C under such circumstances wouldn't end mvn process, instead forcing it to continue? Em 12-05-2011 11:50, Alex Lopez escreveu: Em 12-05-2011 01:22, Andrew Robinson escreveu: I have been using maven 2.2.1 for a while at my company and we just switched to maven 3. I have rebuilt my computer (ubuntu maverick 10.04 32-bit == ubuntu natty 11.04 64-bit) and installed maven 3. In maven 3.0.3, (I have not seen it with maven 2.2.1), it stops downloading after a few to several downloads. If I ^C the build, and keep re-running it, +1, I've been having this kind of 'hangs', using maven 3.0.2 and artifactory 2.3.1 (sometimes when running maven site, sometimes performing a build), then ^C seems to get maven to continue doing what it was doing and eventually end with success... it will eventually built. It only dies when maven is trying to download file. It may happen before any progress is display, partial progress or full progress. Example: Downloading: http://internalserver.ouritranet.com:8086/archiva/repository/internal/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http:// internalserver.ouritranet.com:8086/archiva/repository/snapshots-corporate/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo2.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://www.ibiblio.org/maven/org/apache/maven/skins/maven-default-skin/maven-metadata.xml 341 B 341 B If I let it go for a while it then prints: Downloading: http://internalserver.ouritranet.com:8086/archiva/repository/internal/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://internalserver.ouritranet.com:8086/archiva/repository/snapshots-corporate/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo2.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://www.ibiblio.org/maven/org/apache/maven/skins/maven-default-skin/maven-metadata.xml [WARNING] Checksum validation failed, could not read expected checksum: Error transferring file: Connection timed out for http://repo1.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml [WARNING] Checksum validation failed, could not read expected checksum: Error transferring file: Connection timed out for http://repo2.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml My other co-workers have not reported seeing this issue yet. Any ideas on why maven 3.0.3 is having this problem when maven 2.2.1 does not? FYI, we have a corporate proxy, not sure if that could be part of the problem. -Andrew - 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
Re: Maven 3.0.3 hanging / having timeouts often?
On 12 May 2011 11:50, Alex Lopez wrote: Em 12-05-2011 01:22, Andrew Robinson escreveu: I have been using maven 2.2.1 for a while at my company and we just switched to maven 3. I have rebuilt my computer (ubuntu maverick 10.04 32-bit == ubuntu natty 11.04 64-bit) and installed maven 3. In maven 3.0.3, (I have not seen it with maven 2.2.1), it stops downloading after a few to several downloads. If I ^C the build, and keep re-running it, +1, I've been having this kind of 'hangs', using maven 3.0.2 and artifactory 2.3.1 (sometimes when running maven site, sometimes performing a build), then ^C seems to get maven to continue doing what it was doing and eventually end with success... Me too, on win7/cygwin. I thought it was a cygwin problem. cheers -- Tim Pizey - http://pizey.net/~timp Centre for Genomics and Global Health - http://cggh.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
Yes, Maven 3 should download artifacts in parallell. But Maven 2.2.1 also does that (this feature was introduced in 2.1.0 IIRC). But it is likely two different implementations. /Anders On Thu, May 12, 2011 at 13:01, Alex Lopez alo...@flordeutopia.pt wrote: Now this got me thinking, my intuition is that this might be a network related problem... maybe maven 2 had shorter timeouts, hence not appearing to hang, does Maven 3 download more than one dependency at the same time? Does this behavior differ from version 2? Why hitting ^C under such circumstances wouldn't end mvn process, instead forcing it to continue? Em 12-05-2011 11:50, Alex Lopez escreveu: Em 12-05-2011 01:22, Andrew Robinson escreveu: I have been using maven 2.2.1 for a while at my company and we just switched to maven 3. I have rebuilt my computer (ubuntu maverick 10.04 32-bit == ubuntu natty 11.04 64-bit) and installed maven 3. In maven 3.0.3, (I have not seen it with maven 2.2.1), it stops downloading after a few to several downloads. If I ^C the build, and keep re-running it, +1, I've been having this kind of 'hangs', using maven 3.0.2 and artifactory 2.3.1 (sometimes when running maven site, sometimes performing a build), then ^C seems to get maven to continue doing what it was doing and eventually end with success... it will eventually built. It only dies when maven is trying to download file. It may happen before any progress is display, partial progress or full progress. Example: Downloading: http://internalserver.ouritranet.com:8086/archiva/repository/internal/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http:// internalserver.ouritranet.com:8086/archiva/repository/snapshots-corporate/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo2.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://www.ibiblio.org/maven/org/apache/maven/skins/maven-default-skin/maven-metadata.xml 341 B 341 B If I let it go for a while it then prints: Downloading: http://internalserver.ouritranet.com:8086/archiva/repository/internal/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://internalserver.ouritranet.com:8086/archiva/repository/snapshots-corporate/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo2.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://www.ibiblio.org/maven/org/apache/maven/skins/maven-default-skin/maven-metadata.xml [WARNING] Checksum validation failed, could not read expected checksum: Error transferring file: Connection timed out for http://repo1.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml [WARNING] Checksum validation failed, could not read expected checksum: Error transferring file: Connection timed out for http://repo2.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml My other co-workers have not reported seeing this issue yet. Any ideas on why maven 3.0.3 is having this problem when maven 2.2.1 does not? FYI, we have a corporate proxy, not sure if that could be part of the problem. -Andrew - 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
Re: Maven 3.0.3 hanging / having timeouts often?
Em 12-05-2011 12:02, Tim Pizey escreveu: On 12 May 2011 11:50, Alex Lopez wrote: Em 12-05-2011 01:22, Andrew Robinson escreveu: I have been using maven 2.2.1 for a while at my company and we just switched to maven 3. I have rebuilt my computer (ubuntu maverick 10.04 32-bit == ubuntu natty 11.04 64-bit) and installed maven 3. In maven 3.0.3, (I have not seen it with maven 2.2.1), it stops downloading after a few to several downloads. If I ^C the build, and keep re-running it, +1, I've been having this kind of 'hangs', using maven 3.0.2 and artifactory 2.3.1 (sometimes when running maven site, sometimes performing a build), then ^C seems to get maven to continue doing what it was doing and eventually end with success... Me too, on win7/cygwin. I thought it was a cygwin problem. +1 now that I think about that it seems definitely like a cygwin problem, since I'm never getting this through m2eclipse... could it be related with the warning cygwin gives me complaining about bad ms-dos style paths? $ mvn site site:stage cygwin warning: MS-DOS style path detected: C:\Program Files\Apache Software Foundation\apache-maven-3.0.2/boot/ Preferred POSIX equivalent is: /cygdrive/c/Program Files/Apache Software Foundation/apache-maven-3.0.2/boot/ ... cheers - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
They are going through my proxy, why would you think I am hitting them directly? I have my proxy setup in my settings.xml. It is working most of the time, if it were the fact that my proxy was not used, it would fail 100% of the time (all internet traffic must go through our proxy at work). -Andrew On Wed, May 11, 2011 at 9:01 PM, Wayne Fay wayne...@gmail.com wrote: Downloading: http://internalserver.ouritranet.com:8086/archiva/repository/internal/org/apache/maven/skins/maven-default-skin/maven-metadata.xml http://repo2.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml http://repo1.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml http://www.ibiblio.org/maven/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Obviously you have a proxy. Why in the world are you connecting directly to repo2, repo1, ibiblio etc instead of just letting your proxy hit them on your behalf? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
They are going through my proxy, why would you think I am hitting them directly? I'm OK with the proxy. I'm confused about the Archiva repo you have installed. I should not have said proxy when I really meant MRM/Archiva. Your log shows that your build is hitting Archiva and then also hitting repo2, repo1, and ibiblio for a metadata.xml file. For us (and I think a lot of users of MRMs like Nexus, Artifactory, Archiva), a large part of the reason why we are using a Maven Repo Manager is so that we can tell all our Maven instances on all our machines to look for ALL artifacts directly in that repo manager (Archiva in your case). Then our governance functions can determine which artifacts are OK to use (based on licensing and other concerns) and which must be avoided etc. I think the way you have things configured is less than ideal and you may want to reconsider it. IMO all artifact access should be managed by your Archiva instance. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 hanging / having timeouts often?
Okay, good to know, I'll forward that question onto the fellas that configured our settings.xml and pom.xml files for mvn3. On Thu, May 12, 2011 at 10:12 AM, Wayne Fay wayne...@gmail.com wrote: They are going through my proxy, why would you think I am hitting them directly? I'm OK with the proxy. I'm confused about the Archiva repo you have installed. I should not have said proxy when I really meant MRM/Archiva. Your log shows that your build is hitting Archiva and then also hitting repo2, repo1, and ibiblio for a metadata.xml file. For us (and I think a lot of users of MRMs like Nexus, Artifactory, Archiva), a large part of the reason why we are using a Maven Repo Manager is so that we can tell all our Maven instances on all our machines to look for ALL artifacts directly in that repo manager (Archiva in your case). Then our governance functions can determine which artifacts are OK to use (based on licensing and other concerns) and which must be avoided etc. I think the way you have things configured is less than ideal and you may want to reconsider it. IMO all artifact access should be managed by your Archiva instance. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven 3.0.3 hanging / having timeouts often?
I have been using maven 2.2.1 for a while at my company and we just switched to maven 3. I have rebuilt my computer (ubuntu maverick 10.04 32-bit == ubuntu natty 11.04 64-bit) and installed maven 3. In maven 3.0.3, (I have not seen it with maven 2.2.1), it stops downloading after a few to several downloads. If I ^C the build, and keep re-running it, it will eventually built. It only dies when maven is trying to download file. It may happen before any progress is display, partial progress or full progress. Example: Downloading: http://internalserver.ouritranet.com:8086/archiva/repository/internal/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http:// internalserver.ouritranet.com:8086/archiva/repository/snapshots-corporate/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo2.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://www.ibiblio.org/maven/org/apache/maven/skins/maven-default-skin/maven-metadata.xml 341 B 341 B If I let it go for a while it then prints: Downloading: http://internalserver.ouritranet.com:8086/archiva/repository/internal/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://internalserver.ouritranet.com:8086/archiva/repository/snapshots-corporate/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo2.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml Downloading: http://www.ibiblio.org/maven/org/apache/maven/skins/maven-default-skin/maven-metadata.xml [WARNING] Checksum validation failed, could not read expected checksum: Error transferring file: Connection timed out for http://repo1.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml [WARNING] Checksum validation failed, could not read expected checksum: Error transferring file: Connection timed out for http://repo2.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml My other co-workers have not reported seeing this issue yet. Any ideas on why maven 3.0.3 is having this problem when maven 2.2.1 does not? FYI, we have a corporate proxy, not sure if that could be part of the problem. -Andrew
