On 04/25/2013 06:41 PM, Troy Dawson wrote:
I've been trying to get activemq to build on F19.
Although it built on F19 originally, it no longer does. Without
changing the package, all the dependencies have changed. (And the
%build section, but that was the simple fix.)
It's taken me several days of trial and error to get through one section
of building, and I think I'm on my last, but I just cannot figure out
what provides the following dependancies.
[ERROR] Failed to execute goal on project activemq-core: Could not
resolve dependencies for project
org.apache.activemq:activemq-core:bundle:5.6.0: The following artifacts
could not be resolved: org.springframework:spring-test:jar:SYSTEM,
org.apache.ftpserver:ftpserver-core:jar:1.0.0: The repository system is
offline but the artifact org.springframework:spring-test:jar:SYSTEM is
not available in the local repository. -> [Help 1]
You are running mvn-rpmbuild with option -Dmaven.test.skip=true.
Setting maven.test.skip property to true prevents Maven from compiling
and running unit and integration tests. In Fedora 18 and Fedora Maven
(i.e. mvn-rpmbuild and mvn-local) had another undocumented property -
setting maven.test.skip to true caused test dependencies to be replaced
by empty JAR, which effectively disabled them.
Since Fedora 19 maven.test.skip=true no longer causes Maven to disable
test dependencies. This means that pssing -Dmaven.test.skip=true will
only prevent tests from being compiled and ran, but it will *not*
prevent Maven from trying to resolve dependencies with scope "test".
This is much closer to upstream behaviour and that's the reason for the
The preferred way of building Maven projects on Fedora 19 and later is
%mvn_build macro. Of course you can still use mvn-rpmbuild, but if you
decide to do so then you'll either need to add all test dependencies to
BuildRequires or remove them from POM, for example:
The above macro call in %prep causes all test dependencies to be removed
Is there a java/maven/rpm/yum trick for figuring out which packages
need install to resolve those dependencies?
repoquery -f 'mvn(gId:aId)'
Or you can use maven artifacts directly as dependencies in your spec
file, for example: