Description of problem: The hadoop spec does: %mvn_file :%{name}-common::{}: %{_jnidir}/%{name}-common %{_datadir}/%{name}/common/%{name}-common Which works fine for F20. In rawhide, the symlinks seems to be ending up in /usr/lib/hadoop/common instead of /usr/share/hadoop/common. This causes the build to fail. http://kojipkgs.fedoraproject.org//work/tasks/4622/6094622/build.log Version-Release number of selected component (if applicable): xmvn-1.2.0-4.fc21 How reproducible: 100% Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This appears to be fixed upstream.
Fixed in xmvn-1.2.0-5
I believe that this bug is fixed in xmvn-1.3.0-1, which is available in Fedora Rawhide, so I am closing this bug now. The build containing the fix can be found at Koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=476472
This is still occurring in rawhide. Mock seems to work correctly however. http://kojipkgs.fedoraproject.org//work/tasks/3060/6193060/build.log
Snippet from mvn-install: [INFO] SOURCE ARTIFACT: [INFO] groupId: org.apache.hadoop [INFO] artifactId: hadoop-common [INFO] extension: jar [INFO] classifier: [INFO] version: 2.2.0 [INFO] stereotype: native [INFO] namespace: [INFO] file: /builddir/build/BUILD/hadoop-common-2e01e27e5ba4ece19650484f646fac42596250ce/hadoop-common-project/hadoop-common/target/hadoop-common-2.2.0.jar [INFO] ----------------------------------------------- [INFO] TARGET ARTIFACT: [INFO] groupId: JPP/../../lib/java [INFO] artifactId: hadoop-common [INFO] extension: jar [INFO] classifier: [INFO] version: SYSTEM [INFO] stereotype: native [INFO] namespace: [INFO] file: usr/lib/java/../../lib/java/hadoop-common.jar [INFO] ----------------------------------------------- [INFO] TARGET ARTIFACT: [INFO] groupId: JPP/../hadoop/common [INFO] artifactId: hadoop-common [INFO] extension: jar [INFO] classifier: [INFO] version: SYSTEM [INFO] stereotype: native [INFO] namespace: [INFO] file: usr/lib/java/../hadoop/common/hadoop-common.jar The above really seems incorrect.
Using an x86_64 system and mock, I can successfully build for x86_64 but i386 fails. From the build.log from the x86_64 build: [INFO] SOURCE ARTIFACT: [INFO] groupId: org.apache.hadoop [INFO] artifactId: hadoop-common [INFO] extension: jar [INFO] classifier: [INFO] version: 2.2.0 [INFO] stereotype: native [INFO] namespace: [INFO] file: /builddir/build/BUILD/hadoop-common-2e01e27e5ba4ece19650484f646fac42596250ce/hadoop-common-project/hadoop-common/target/hadoop-common-2.2.0.jar [INFO] ----------------------------------------------- [INFO] TARGET ARTIFACT: [INFO] groupId: JPP/../../lib/java [INFO] artifactId: hadoop-common [INFO] extension: jar [INFO] classifier: [INFO] version: SYSTEM [INFO] stereotype: native [INFO] namespace: [INFO] file: usr/lib/java/../../lib/java/hadoop-common.jar [INFO] ----------------------------------------------- [INFO] TARGET ARTIFACT: [INFO] groupId: JPP/../hadoop/common [INFO] artifactId: hadoop-common [INFO] extension: jar [INFO] classifier: [INFO] version: SYSTEM [INFO] stereotype: native [INFO] namespace: [INFO] file: usr/lib/java/../hadoop/common/hadoop-common.jar
This is the configuration for XMvn generated by %mvn_file macro call: <?xml version='1.0' encoding='UTF-8'?> <configuration xmlns="http://fedorahosted.org/xmvn/CONFIG/0.6.0"> <!--XMvn configuration file generated by javapackages.xmvn_config (part of javapackages-tools)--> <artifactManagement> <rule> <artifactGlob> <artifactId>hadoop-common</artifactId> <classifier>{}</classifier> </artifactGlob> <files> <file>../../lib/java/hadoop-common</file> <file>../hadoop/common/hadoop-common</file> </files> </rule> </artifactManagement> </configuration> While the first file is correct (relative to _javadir). Second file should be relative to the first file, not relative to _javadir. Reassigning to javapackages-tools
Removing the absolute path (_jnidir} from mvn_file creates this: [INFO] =============================================== [INFO] SOURCE ARTIFACT: [INFO] groupId: org.apache.hadoop [INFO] artifactId: hadoop-common [INFO] extension: jar [INFO] classifier: [INFO] version: 2.2.0 [INFO] stereotype: native [INFO] namespace: [INFO] file: /builddir/build/BUILD/hadoop-common-2e01e27e5ba4ece19650484f646fac42596250ce/hadoop-common-project/hadoop-common/target/hadoop-common-2.2.0.jar [INFO] ----------------------------------------------- [INFO] TARGET ARTIFACT: [INFO] groupId: JPP [INFO] artifactId: hadoop-common [INFO] extension: jar [INFO] classifier: [INFO] version: SYSTEM [INFO] stereotype: native [INFO] namespace: [INFO] file: usr/lib/java/hadoop-common.jar [INFO] ----------------------------------------------- [INFO] TARGET ARTIFACT: [INFO] groupId: JPP/../hadoop/common [INFO] artifactId: hadoop-common [INFO] extension: jar [INFO] classifier: [INFO] version: SYSTEM [INFO] stereotype: native [INFO] namespace: [INFO] file: usr/lib/java/../hadoop/common/hadoop-common.jar [INFO] =============================================== i.e. XMvn correctly places hadoop-common.jar into _jnidir, but the second part has incorrect path that has usr/lib/java prefix and then relative path against usr/share/java. Configuration generated in this case by mvn_file is: <?xml version="1.0" encoding="UTF-8"?> <configuration xmlns="http://fedorahosted.org/xmvn/CONFIG/0.6.0"> <!--XMvn configuration file generated by javapackages.xmvn_config (part of javapackages-tools)--> <artifactManagement> <rule> <artifactGlob> <artifactId>hadoop-common</artifactId> <classifier>{}</classifier> </artifactGlob> <files> <file>hadoop-common</file> <file>../hadoop/common/hadoop-common</file> </files> </rule> </artifactManagement> </configuration
OK, so after talking to Mikolaj a bit we decided to switch this back to XMvn. Reasoning: 1. XMvn currently doesn't support absolute paths for file symlinks. This is due to the fact that XMvn handles these symlinks as complete artifacts (symlinking even pom.xml and versioned alternatives automatically) and artifacts have to be in *some* repository. We have repositories for _javadir and few other directories but that won't help with absolute paths 2. javapackages-tools can't properly decide what relative paths to give to XMvn because it doesn't know where the first file will end up (since XMvn decides based on configuration). It could be _javadir or _jnidir or something completely else. You *can* currently override with -p switch for mvn_file but that means packager has to know where the file ends up before creating the package and ... it gets confusing fast All that said Mikolaj is now working on a proper fix in XMvn itself so that absolute symlinks are possible.
limited support for absolute JPP artifact files was implemented in upstream commit af51da3. Anything more powerfull would be too complicated and it's probably not worth the effort. Artifact files specified as absolute paths pointing to arbitrary locations are now allowed. They are implemented as symbolic links which are pointing to the primary artifact file, which must be explicitly specified as non-absolute file. Appropriate suffixes are added depending on artifact version, classifier and extension. As absolute symlinks can be placed at any location, configured repositories are not taken into account and flat repository layout is always assumed. Absolute symlinks are only created for artifact files and attached artifacts, but not for POM files. Absolute files for artifacts with no files (i.e. POM artifacts) are silently ignored.
Verified upstream. I've rebuilt maven-downloader and added %mvn_file : /foo /dummy/file %{name} /usr/share/java/bar/baz the results are as below: $ rpm -q xmvn xmvn-1.4.0-0.7.git1777a06.noarch $ rpm -ql maven-downloader /dummy/file.jar /foo.jar /usr/share/doc/maven-downloader /usr/share/doc/maven-downloader/LICENSE.txt /usr/share/java/bar/baz.jar /usr/share/java/maven-downloader.jar /usr/share/maven-effective-poms/JPP-maven-downloader.pom /usr/share/maven-fragments/maven-downloader.xml /usr/share/maven-poms/JPP-maven-downloader.pom $ ls -go /dummy/file.jar /foo.jar /usr/share/java/bar/baz.jar /usr/share/java/maven-downloader.jar lrwxrwxrwx. 1 38 Dec 4 18:07 /dummy/file.jar -> ../usr/share/java/maven-downloader.jar lrwxrwxrwx. 1 35 Dec 4 18:07 /foo.jar -> usr/share/java/maven-downloader.jar lrwxrwxrwx. 1 23 Dec 4 18:07 /usr/share/java/bar/baz.jar -> ../maven-downloader.jar -rw-r--r--. 1 16192 Dec 4 18:03 /usr/share/java/maven-downloader.jar Everything seems correct to me.
Fixed in xmvn-1.4.0-1
I believe that this bug is fixed in xmvn-1.4.0-1, which is available in Fedora Rawhide, so I am closing this bug now. The build containing the fix can be found at Koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=483639