Hi, To whom it may concern I would like to update that I seem to be able to work around this issue:
In the super pom for all of our projects I've defined the following: <dependencyManagement> <dependencies> ... <dependency> <groupId>com.amazonaws</groupId> <artifactId>aws-java-sdk</artifactId> <version>1.1.0</version> </dependency> <dependency> <groupId>commons-httpclient</groupId> <artifactId>commons-httpclient</artifactId> <version>3.1</version> </dependency> <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>1.1</version> </dependency> </dependencies> ... </dependencyManagement> This causes maven to pick version 1.1 of commons-logging even without consulting the metadata file :). I would like to mention that this is a hack to get this thing to work but I would obviously like to work for a proper solution on this problem. Thanks, Maxim. On Thu, Dec 2, 2010 at 8:29 PM, Maxim Veksler <[email protected]> wrote: > Hi, > > // This email is cross posted to maven-users & hudson-users, Maven seems to > be the issue, but it only reproduces under Hudson environment. > > > First, a quick description of the problem before I drill down into the > details: Our maven projects that depend on > com.amazonaws:aws-java-sdk:jar:1.1.0 fail to build on our linux based Hudson > installation (server is sitting on EC2) because of unsatisfied range > dependency coming from aws-java-sdk -> commons-logging [1.1,2.0). This > happens only on the build server, and reproduces after > several successful builds. On the develop machines this does not happen. > > > The full behavior, and debugging steps are as following. > > We have a super pom that defines: > > <dependencyManagement> > <dependencies> > .... > <dependency> > <groupId>com.amazonaws</groupId> > <artifactId>aws-java-sdk</artifactId> > <version>1.1.0</version> > </dependency> > .... > </dependencies> > </dependencyManagement> > > > Then projects (that define the super pom as their parent) define the > dependency on aws-java-sdk in their own pom: > > <dependencies> > .... > <dependency> > <groupId>com.amazonaws</groupId> > <artifactId>aws-java-sdk</artifactId> > </dependency> > </dependencies> > > This setup works great and compiles on the development Ubuntu machines. > > On Hudson OTOH the same setup yields different results, once in a while the > build fails with the following error: > > $ mvn install > [INFO] Scanning for projects... > [INFO] > ------------------------------------------------------------------------ > [INFO] Building mad service online updater > [INFO] task-segment: [install] > > > [INFO] > ------------------------------------------------------------------------ > > > [INFO] [resources:resources {execution: default-resources}] > > > [INFO] Using 'UTF-8' encoding to copy filtered resources. > > > [INFO] Copying 6 resources > > > [INFO] > ------------------------------------------------------------------------ > > > [ERROR] BUILD ERROR > > > [INFO] > ------------------------------------------------------------------------ > > > [INFO] Failed to resolve artifact. > > > > > > No versions are present in the repository for the artifact with a range > [1.1,2.0) > > commons-logging:commons-logging:jar:null > > > > > > from the specified remote repositories: > > > Everything (http://artifactory.eyeviewdigital.com/artifactory/repo), > > > central (http://repo1.maven.org/maven2) > > > > > > Path to dependency: > > > 1) com.eyeview:mad-updater:jar:1.0.0-SNAPSHOT > > > 2) com.amazonaws:aws-java-sdk:jar:1.1.0 > > > After debugging this I came to the conclusion that the reason it fails on > the production build server is because the maven-metadata > for commons-logging get's "emptied" on the build server. > > Here is how the file looks on the build server (I've download it to my > local PC, and was able to successfully reproduce the bug using the .m2 > coming from Hudson): > > ma...@maxim-desktop:~/workspace$ cat > ~/.m2/repository/commons-logging/commons-logging/maven-metadata-Everything.xml > <?xml version="1.0" encoding="UTF-8"?> > <metadata> > <groupId>commons-logging</groupId> > <artifactId>commons-logging</artifactId> > </metadata> > > Here is how it looks on my machine (I've renamed my local .m2 to a > .m2-mine) > ma...@maxim-desktop:~/workspace$ cat > ~/.m2-mine/repository/commons-logging/commons-logging/maven-metadata-Everything.xml > > <?xml version="1.0" encoding="UTF-8"?> > > > <metadata> > > > <groupId>commons-logging</groupId> > > > <artifactId>commons-logging</artifactId> > > > <version>1.1.1</version> > > > <versioning> > > > <release>1.1.1</release> > > > <versions> > > > <version>1.0</version> > <version>1.0.1</version> > <version>1.0.2</version> > <version>1.0.3</version> > <version>1.0.4</version> > <version>1.1</version> > <version>1.1.1</version> > </versions> > <lastUpdated>20071128191817</lastUpdated> > </versioning> > </metadata> > > You can see that the metadata file is empty, which causes maven to fail to > find a correct match for the dependency version range. > > > The question is: How can I work around this / Solve this? > The only solution I currently have is wiping out the .m2 folder on the > hudson server and causing it to redownload the whole .m2 repository from our > local artifactory server... This works for several builds and then starts to > fail again. > > I'm including the mvn -X run of the working & failing executions, If you > diff them you see the environment is different for the users. One > interesting difference is the following: > > On developer > workstation: > java.class.path=/home/maxim/opt/apache-maven-2.2.1/boot/classworlds-1.1.jar, > while on Hudson build > environment > java.class.path=/var/lib/hudson/plugins/maven-plugin/WEB-INF/lib/maven-agent-1.384.jar:/opt/maven2.2.1/apache-maven-2.2.1/boot/classworlds-1.1.jar. > I don't know what in the maven-agent plugin could be causing this but this > sounds like a possible cause of the problem. > > > *== Environment ==* > > *= Build server: =* > > hud...@domu-12-31-38-04-fc-01:~$ */opt/maven2.2.1/apache-maven-2.2.1/bin/mvn > --version* > Warning: JAVA_HOME environment variable is not set. > Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+0000) > Java version: 1.6.0_22 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.35-22-virtual" arch: "amd64" Family: "unix" > > hud...@domu-12-31-38-04-fc-01:~$ *java -version* > java version "1.6.0_22" > Java(TM) SE Runtime Environment (build 1.6.0_22-b04) > Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode) > hud...@domu-12-31-38-04-fc-01:~$ > /opt/maven2.2.1/apache-maven-2.2.1/bin/mvn --version > Warning: JAVA_HOME environment variable is not set. > Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+0000) > Java version: 1.6.0_22 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.35-22-virtual" arch: "amd64" Family: "unix" > > hud...@domu-12-31-38-04-fc-01:~$ *uname -a* > Linux domU-12-31-38-04-FC-01 2.6.35-22-virtual #35-Ubuntu SMP Sat Oct 16 > 23:19:29 UTC 2010 x86_64 GNU/Linux > > hud...@domu-12-31-38-04-fc-01:~$ *cat /etc/issue* > Ubuntu 10.10 \n \l > > *= Developer workstation: =* > > ma...@maxim-desktop:~/workspace$ */home/maxim/opt/apache-maven-2.2.1/bin/mvn > --version* > Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300) > Java version: 1.6.0_22 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.35-23-generic" arch: "amd64" Family: "unix" > > ma...@maxim-desktop:~/workspace$ *java -version* > java version "1.6.0_22" > Java(TM) SE Runtime Environment (build 1.6.0_22-b04) > Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode) > > ma...@maxim-desktop:~/workspace$ *uname -a* > Linux maxim-desktop 2.6.35-23-generic #40-Ubuntu SMP Wed Nov 17 22:14:33 > UTC 2010 x86_64 GNU/Linux > > ma...@maxim-desktop:~/workspace$ *cat /etc/issue* > Ubuntu 10.10 \n \l > > > >
