Re: Maven 3.0.3 hanging / having timeouts often??

[Arne Tøn]

FYI: The situation described in this thread reminds me of my problem in the
thread "Initial Maven Install - repository download fails on large
files".
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?

[Wayne Fay]

> 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?

[Bob Wang]

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?

[Wayne Fay]

> 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?

[Henrik Arro]

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?

[Henrik Arro]

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?

[martin.eisengardt]

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  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 hanging / having timeouts often?

[Wayne Fay]

> 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?

[arro]

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 Not Allowing Different Versions for Compile/Test

[Stephen Connolly]

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  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?
>
>    
>        org.apache.hadoop
>        hadoop-core
>        0.20.2-cdh3u2
>        compile
>    
>
>    
>        org.apache.hadoop
>        hadoop-core
>        1.0.0
>        test
>    
>
>    
>        org.apache.hadoop
>        hadoop-test
>        1.0.0
>        test
>    
>
> 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-conte

Re: Maven 3.0.3 Not Allowing Different Versions for Compile/Test

[Jörg Schaible]

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?
> 
> 
> org.apache.hadoop
> hadoop-core
> 0.20.2-cdh3u2
> compile
> 
> 
> 
> org.apache.hadoop
> hadoop-core
> 1.0.0
> test
> 
> 
> 
> org.apache.hadoop
> hadoop-test
> 1.0.0
> test
> 
> 
> 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-contex

Maven 3.0.3 Not Allowing Different Versions for Compile/Test

[Daniel Jones]

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?


org.apache.hadoop
hadoop-core
0.20.2-cdh3u2
compile



org.apache.hadoop
hadoop-core
1.0.0
test



org.apache.hadoop
hadoop-test
1.0.0
test


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.RELEASE:compile
[INFO]org.springframework.data:spring-data-hadoop:jar:1.0.0.BUILD-SNAPSHOT:c
ompile
[INFO]oro:oro:jar:2.0.8:test
[INFO]tomcat:jasper-compiler:jar:5.5.12:tes

Re: Maven 3.0.3, Classifier, maven-metadata.xml, , and TeamCity

[Tamás Cservenák]

ample below there is only a "linux" classifier.
>
> Hosed maven-metadata.xml:
> 
>     com.foo
>     E
>     4.0-SNAPSHOT
>     
>          
>               325
>               20111205.181820
>          
>          20111205181820
>     
> 
>
> Good maven-metadata.xml:
> 
>     com.foo
>     D
>     4.0-SNAPSHOT
>     
>          
>               20111205.200259
>               328
>          
>          20111205200259
>          
>               
>                    pom
>                    4.0-20111205.200259-328
>                    20111205200259
>               
>               
>                    linux
>                    jar
>                    4.0-20111205.200259-328
>                    20111205200259
>               
>               
>                    tests
>                    jar
>                    4.0-20111205.200259-328
>                    20111205200259
>               
>          
>     
> 
>
> 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, , and TeamCity

[Jason H]

Gents,

Thank you for any assistance in advance. I'm completely out of ideas,
as are the folks at TeamCity. This may be a maven deploy plugin issue,
all opinions/insights are welcome and appreciated. At the very highest
level I need to be able to continuously deploy linux and windows jars
and let a build running on either linux or windows resolve those
deployed jars.

My setup looks like this (mostly because of matlab licensing fun):

pom.xml 
\A 
\B 
\C 
\C\D 
\C\E 

So when I build my root pom.xml file I do a mvn deploy at the root
which deploys A and B. When I do a mvn deploy on C it deploys D and E.
B and C need the jars from D and E. When doing a mvn deploy on C
OS-dependent jar files are deployed to an apache archiva repository
(I've tried sonatype, had the same issue, so I don't think it's an
archiva problem). The OS-dependent specification is done by adding the
classifier tag in the maven-jar-plugin in C's pom.xml:


  
   
maven-jar-plugin
${maven.jar.plugin.version}

 ${envClassifier}

   
  


where envClassifier is defined in the root pom.xml file depending on
the current operating system (we deploy windows and linux jars, only
64-bit).

I've also updated the maven-deploy-plugin version in the root pom.xml
file to version 2.7 (I tried the latest snapshot too, to no avail).
The updated maven-deploy-plugin also references the classifier,
without this the deployed maven-metadata.xml file did not have the
 information needed to resolve dependencies and
only the last deployed OS jars were found.



   
   org.apache.maven.plugins
   maven-deploy-plugin
   2.7
   
${envClassifier}
   
  



Now we come full force to the issue at hand. I have 4 TeamCity build
configurations, 1 that deploys A on windows, 1 that deploys A on
linux, 1 that deploys C on windows, and 1 that deploys C on linux.
Deploying A is done continuously on every commit (if the build agents
can keep up, A is a fast build). Deploying C on windows and linux is
(currently) done by manually triggering the build on the build server
such that they both start at the same time and therefore are
(hopefully) based on the same svn revision (we average a commit every
~20 minutes, so that seems ok for now). Most of the time the deployed
maven-metadata.xml file seems to eventually get corrupted and loses
all its  information, so I end up with the below
as my maven-metadata.xml. It has been very difficult to ascertain when
the maven-metadata.xml file gets corrupted, it seems somewhat random.
Recently I have seen it get corrupted after a deploy on A, but looking
at that build log it doesn't show any updating of C, D, or E's maven
metadata. So I really don't know why it keeps getting hosed and after
it's hosed dependencies cannot be resolved when building A on either
linux or windows (but not both, whichever OS last deployed, that OS
build for A can still resolve dependencies). Also the "good"
maven-metadata.xml file only seems to have 1 classifier, so maybe
that's not even good enough? i.e. In the "Good maven-metadata.xml"
example below there is only a "linux" classifier.

Hosed maven-metadata.xml:

 com.foo
 E
 4.0-SNAPSHOT
 
  
   325
   20111205.181820
  
  20111205181820
 


Good maven-metadata.xml:

 com.foo
 D
 4.0-SNAPSHOT
 
  
   20111205.200259
   328
  
  20111205200259
  
   
pom
4.0-20111205.200259-328
20111205200259
   
   
linux
jar
4.0-20111205.200259-328
20111205200259
   
   
tests
jar
4.0-20111205.200259-328
20111205200259
   
  
 


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

Re: Maven 3.0.3 generated different runtime classpath with the same POM

[Sebastian Otaegui]

Can you post your pom?

On Feb 1, 2012 1:15 AM, "Jörg Schaible"  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: Maven 3.0.3 generated different runtime classpath with the same POM

[Jörg Schaible]

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

[Sebastian Otaegui]

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  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.

Maven 3.0.3 generated different runtime classpath with the same POM

[Julie Chi]

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: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)

[Kalle Korhonen]

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
 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"  wrote:
>
>> Greetings,
>>
>> On Tue, Jan 3, 2012 at 3:45 PM, Mark Derricutt  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

Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)

[Stephen Connolly]

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"  wrote:

> Greetings,
>
> On Tue, Jan 3, 2012 at 3:45 PM, Mark Derricutt  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)

[Arnaud Héritier]

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)

[Jesse Farinacci]

Greetings,

On Tue, Jan 3, 2012 at 3:45 PM, Mark Derricutt  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)

[Stephen Connolly]

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  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  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)

[Mark Derricutt]

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  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)

[Stephen Connolly]

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  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)

[Mark Derricutt]

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
>
>

WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)

[Stephen Connolly]

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: Is there a way to specify the local repo in command line for Maven 3.0.3?

[Anders Hammar]

It works for me with Maven 3.0.3.

/Anders

On Fri, Dec 23, 2011 at 17:11, Karl Heinz Marbaise  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: Is there a way to specify the local repo in command line for Maven 3.0.3?

[Karl Heinz Marbaise]

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

Is there a way to specify the local repo in command line for Maven 3.0.3?

[Forrest Xia]

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: Maven 3.0.3: Problems with SNAPSHOT updates

[Dreier Ruediger]

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 
> 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
> wrote:
> >
> >> 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:
> >> > >
> >> > >   
> >> > >     
> >> > >       de.bdal.common.bcl
> >> > >       settings
> >> > >       0.0.0.1-SNAPSHOT
> >> > >       binaries
> >> > >       zip
> >> > >     
> >> > >   
> >> > >
> >> > >   
> >> > >     
> >> > >
> >> > >       
> >> > >
> >> > >         org.apache.maven.plugins
> >> > >         maven-dependency-plugin
> >> > >         2.2
> >> > >         
> >> > >           
> >> > >             process-resources
> >> > >             
> >> > >               unpack-dependencies
> >> > >             
> >> > >             
> >> > >               true
> >> > >
> >> > > ./target/references
> >> > >             
> >> > >           
> >> > >         
> >> > >       
> >> > >
> >> > >     
> >> > >   
> >> > >
> >> > >
> >> > > On a second PC (our Jenkins build system, still using Maven
> >> > > 2.2.1) the project de.bdal.common.bcl:se

Re: Maven 3.0.3: Problems with SNAPSHOT updates

[Patrick Sansoucy]

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  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 
> wrote:
>
>> 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:
>> > >
>> > >   
>> > >     
>> > >       de.bdal.common.bcl
>> > >       settings
>> > >       0.0.0.1-SNAPSHOT
>> > >       binaries
>> > >       zip
>> > >     
>> > >   
>> > >
>> > >   
>> > >     
>> > >
>> > >       
>> > >
>> > >         org.apache.maven.plugins
>> > >         maven-dependency-plugin
>> > >         2.2
>> > >         
>> > >           
>> > >             process-resources
>> > >             
>> > >               unpack-dependencies
>> > >             
>> > >             
>> > >               true
>> > >               ./target/references
>> > >             
>> > >           
>> > >         
>> > >       
>> > >
>> > >     
>> > >   
>> > >
>> > >
>> > > 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)
&

Re: Maven 3.0.3: Problems with SNAPSHOT updates

[Brian Parker]

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 wrote:

> 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:
> > >
> > >   
> > > 
> > >   de.bdal.common.bcl
> > >   settings
> > >   0.0.0.1-SNAPSHOT
> > >   binaries
> > >   zip
> > > 
> > >   
> > >
> > >   
> > > 
> > >
> > >   
> > >
> > > org.apache.maven.plugins
> > > maven-dependency-plugin
> > > 2.2
> > > 
> > >   
> > > process-resources
> > > 
> > >   unpack-dependencies
> > > 
> > > 
> > >   true
> > >   ./target/references
> > > 
> > >   
> > > 
> > >   
> > >
> > > 
> > >   
> > >
> > >
> > > 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
> > >
>

RE: Maven 3.0.3: Problems with SNAPSHOT updates

[Dreier Ruediger]

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:
> >
> >   
> > 
> >   de.bdal.common.bcl
> >   settings
> >   0.0.0.1-SNAPSHOT
> >   binaries
> >   zip
> > 
> >   
> >
> >   
> > 
> >
> >   
> >
> > org.apache.maven.plugins
> > maven-dependency-plugin
> > 2.2
> > 
> >   
> > process-resources
> > 
> >   unpack-dependencies
> > 
> > 
> >   true
> >   ./target/references
> > 
> >   
> > 
> >   
> >
> > 
> >   
> >
> >
> > 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.de<mailto:ruediger.dre...@bdal.de>
> > www.bruker.com<http://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

[Thiessen, Todd (Todd)]

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:
> 
>   
> 
>   de.bdal.common.bcl
>   settings
>   0.0.0.1-SNAPSHOT
>   binaries
>   zip
> 
>   
> 
>   
> 
> 
>   
> 
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.2
> 
>   
> process-resources
> 
>   unpack-dependencies
> 
> 
>   true
>   ./target/references
> 
>   
> 
>   
> 
> 
>   
> 
> 
> 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.de<mailto:ruediger.dre...@bdal.de>
> www.bruker.com<http://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: Problems with SNAPSHOT updates

[Dreier Ruediger]

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:

  

  de.bdal.common.bcl
  settings
  0.0.0.1-SNAPSHOT
  binaries
  zip

  

  


  

org.apache.maven.plugins
maven-dependency-plugin
2.2

  
process-resources

  unpack-dependencies


  true
  ./target/references

  

  


  


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.de<mailto:ruediger.dre...@bdal.de>
www.bruker.com<http://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 - performance with version ranges

[Tommy Chheng]

+1 for using aether >1.12, this reduced 2:00 compile time to ~45 seconds.


2011/9/30 Tamás Cservenák 

> 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 
> 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

Re: [m2e-users] maven 3.0.3 - performance with version ranges

[Paul French]

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

[Thiebaud, Christophe]

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: maven 3.0.3 - performance with version ranges

[Tamás Cservenák]

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  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

maven 3.0.3 - performance with version ranges

[Paul French]

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: Re: Incorrect assembly created with Maven 3.0.3

[Thorsten Heit]

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

Antwort: Re: Incorrect assembly created with Maven 3.0.3

[Thorsten Heit]

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: Incorrect assembly created with Maven 3.0.3

[Anders Hammar]

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  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

[WhiteMarlin]

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

Re: Maven 3.0.3 installation help

[Benson Margulies]

sh -v /wherever/bin/mvn

and see what it's actually running?

On Tue, Jun 28, 2011 at 12:21 PM, Patrick Lind
 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*
>
> __ 
>

-
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

[Patrick Lind]

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*

__ 

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

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 French  wrote:


From: Paul French
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"
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

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Mark Struberg]

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  wrote:

> From: Paul French 
> 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" 
> 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

[Paul French]

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

[Kristian Rosenvold]

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

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Barrie Treloar]

On Wed, Jun 22, 2011 at 1:02 AM, Benson Margulies  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

[Benson Margulies]

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 French
>>>>>>  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 French
>>>>>>>>  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
>>>>>>>>> "Err

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Ron Wheeler]

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.

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

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 
French  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 
Frenchwrote:
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

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Ron Wheeler]

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 
French  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 
Frenchwrote:
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

[Paul French]

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 
French  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 
Frenchwrote:
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)
Down

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

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 French  
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 
Frenchwrote:
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/k

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Ron Wheeler]

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 French  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 Frenchwrote:

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/rep

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Benson Margulies]

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  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 French  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

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

Thanks for reply - see inline

On 21/06/2011 11:27, B Smith-Mannschott wrote:

On Mon, Jun 20, 2011 at 19:54, Paul French  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 configuredalways  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 of the form
1.2.3-mumble.

1.2.3-SNAPSHOT< 

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[B Smith-Mannschott]

On Mon, Jun 20, 2011 at 19:54, Paul French  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 always 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 advan

Re: Fwd: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

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 
Organisation:   Kirona
To: users@maven.apache.org
CC: Ian Jones 



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

[Olivier Lamy]

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 :
> 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 
> Organisation:   Kirona
> To:     users@maven.apache.org
> CC:     Ian Jones 
>
>
>
> 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/

Fwd: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

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 
Organisation:   Kirona
To: users@maven.apache.org
CC: Ian Jones 



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

maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

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

[Wayne Fay]

> 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

[Stephen Connolly]

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"  wrote:

Re: Maven 3.0.3 doesn't copy metadata xml *.jdo to target during install

[Vivek Ganesh V.T]

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  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

[Wayne Fay]

> 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

[Matthew Adams]

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  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

Maven 3.0.3 doesn't copy metadata xml *.jdo to target during install

[Vivek Ganesh V.T]

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

[Henika Tekwani]

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  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  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

[Anders Hammar]

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  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  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

[Henika Tekwani]

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  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

[Anders Hammar]

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  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
>
>
>

RE: Issue running mvn deploy using Maven 3.0.3

[Henika Tekwani]

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

[Henika Tekwani]

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: maven 3.0.3

[Nick Stolwijk]

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 /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  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  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

[Brosh, Yossi]

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  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

[Nick Stolwijk]

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  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

maven 3.0.3

[Brosh, Yossi]

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 hanging / having timeouts often?

[Andrew Robinson]

Okay, I removed a bunch of cruft from my settings.xml and odd settings that
our company has asked us to put in there. Once cleaning this up I have not
had the timeout yet. I think I am okay for a while, but will respond again
if the problem comes back and I can provide more useful information.

Thanks

On Mon, May 16, 2011 at 5:52 PM, Benson Margulies wrote:

> "Running a local nexus means never having to say --offline"
>
> On Mon, May 16, 2011 at 7:43 PM, Barrie Treloar 
> wrote:
> > On Tue, May 17, 2011 at 3:04 AM, Benson Margulies 
> 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: Maven 3.0.3 hanging / having timeouts often?

[Benson Margulies]

"Running a local nexus means never having to say --offline"

On Mon, May 16, 2011 at 7:43 PM, Barrie Treloar  wrote:
> On Tue, May 17, 2011 at 3:04 AM, Benson Margulies  
> 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: Maven 3.0.3 hanging / having timeouts often?

[Barrie Treloar]

On Tue, May 17, 2011 at 3:04 AM, Benson Margulies  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?

[Benson Margulies]

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
 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  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?

[Andrew Robinson]

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  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?

[Wayne Fay]

> 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?

[Andrew Robinson]

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  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: Incorrect assembly created with Maven 3.0.3

[Thorsten Heit]

-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

Re: Incorrect assembly created with Maven 3.0.3

[Wayne Fay]

> 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

Incorrect assembly created with Maven 3.0.3

[Thorsten Heit]

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:

(...)



src/main/resources



../my-prg





org.apache.maven.plugins
maven-compiler-plugin
2.3.2

1.6
1.6




org.apache.maven.plugins
maven-deploy-plugin
2.5



org.apache.maven.plugins
maven-javadoc-plugin
2.8



org.apache.maven.plugins
maven-release-plugin
2.1



org.apache.maven.plugins
maven-resources-plugin
2.5



org.apache.maven.plugins
maven-scm-plugin
1.5


cvs_native

install






org.apache.maven.plugins
maven-source-plugin
2.1.2



org.codehaus.mojo
appassembler-maven-plugin
1.1.1


attach-appassembler
package

Re: Maven 3.0.3 hanging / having timeouts often?

[Andrew Robinson]

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  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
>
>

Re: Maven 3.0.3 hanging / having timeouts often?

[Wayne Fay]

> 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?

[Andrew Robinson]

They are going through my proxy, why would you think I am hitting them
directly?

I have my  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  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?

[Alex Lopez]

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?

[Anders Hammar]

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  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?

[Tim Pizey]

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?

[Alex Lopez]

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?

[Alex Lopez]

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