You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Maxim Veksler <ma...@vekslers.org> on 2010/12/02 19:29:26 UTC
Maven build fails because of empty maven-metadata-central.xml under hudson
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):
maxim@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)
maxim@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: =*
hudson@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"
hudson@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)
hudson@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"
hudson@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
hudson@domU-12-31-38-04-FC-01:~$ *cat /etc/issue*
Ubuntu 10.10 \n \l
*= Developer workstation: =*
maxim@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"
maxim@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)
maxim@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
maxim@maxim-desktop:~/workspace$ *cat /etc/issue*
Ubuntu 10.10 \n \l
Re: Maven build fails because of empty maven-metadata-central.xml
under hudson
Posted by Maxim Veksler <ma...@vekslers.org>.
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 <ma...@vekslers.org> 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):
>
> maxim@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)
> maxim@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: =*
>
> hudson@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"
>
> hudson@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)
> hudson@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"
>
> hudson@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
>
> hudson@domU-12-31-38-04-FC-01:~$ *cat /etc/issue*
> Ubuntu 10.10 \n \l
>
> *= Developer workstation: =*
>
> maxim@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"
>
> maxim@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)
>
> maxim@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
>
> maxim@maxim-desktop:~/workspace$ *cat /etc/issue*
> Ubuntu 10.10 \n \l
>
>
>
>