but I end up getting:
[ERROR] Failed to execute goal on project tuxguitar-pdf:
Could not
resolve dependencies for project
org.herac.tuxguitar:tuxguitar-pdf:jar:1.3.0: The following
artifacts
could not be resolved: com.itextpdf:itextpdf:jar:SYSTEM,
com.itextpdf.tool:xmlworker:jar:SYSTEM: Cannot access
swt-repo
(https://swt-repo.googlecode.com/svn/repo/)
in offline mode and the
artifact com.itextpdf:itextpdf:jar:SYSTEM has not been
downloaded from
it before. -> [Help 1]
So, I worked around by patching the pom.xml file and removed
the
dependency by hand. I am pretty sure there is a better way
of doing
this with the maven macros.
You can't just remove the dependency. You have to
disable any module which uses that dependency:
%pom_disable_module <moduledir>
I noticed that the project is structured like a multi-module
project, but I don't see a <modules> section in the
pom.xml. I looked at your spec, but I couldn't figure out
how the builds in the subdirectories are being triggered.
Usually, maven triggers them from the parent. I'm not sure
about this project, though.
Looking at the top-level pom.xml, it also looks like you'll
need to build with a specific arch-dependent profile active,
which you'll probably need to manipulate with some %ifarch
condition.
2- When the package is built with %mvn_build and installed
with
%mvn_install the jar files get installed into
/usr/share/java/tuxguitar/. But looking at the launcher
script, the
application expects the jar files to be in /usr/share//. Is
there a way to tell maven to install the jar files there
instead
(these are application jars, not shared libraries) ?
Doesn't matter if they are application jars or shared...
they should be put in a standard location, because you never
know what kind of projects may want to reuse these jars as
their own dependencies. (for example,
formatter-maven-plugin, which is not packaged in Fedora,
uses Eclipse's jars to provide formatting during a maven
build according to Eclipse's standards when using the IDE...
not something Eclipse developers probably expected, but very
a very useful example of code reuse from an application
jar).
3- I manually moved the jar files into
/usr/share/tuxguitar/. The
launcher calls the entry point in tuxguitar.jar. But this
jar doesn't
find the other jars, for example the
tuxguitar-editor-utils.jar, and
the application doesn't launch. I can add this jar file and
the other
15 jar files to the CLASSPATH in the lancher script, but I
am not sure
this is the right way. I didn't have to do this with ant.
With ant,
the tuxguitar.jar somehow knew about the other jars. How can
we fix
this?
Don't move the jars. You can symlink them, or change the
launch scripts to point to the location in the Fedora
system. If this is problematic, you may also want to work
with upstream to make it easier by making the actual
classpath location more easily configurable.
4- There are a bunch of supplementary files (.desktop file,
icons,
mime xmls, the launcher script etc) which are listed in the
main
pom.xml file, but %mvn_install doesn't install them. I had
to copy
them manually to the $RPM_BUILD_ROOT. Is there a way to do
this with
better?
[snip]
I think that's pretty normal. Use 'install' to put them
in the proper location in the buildroot (here's examples
from accumulo):
install -d -m 755 %{buildroot}%{_libdir}/%{name}
install -p -m 755
server/native/target/%{name}-native-%{version}/%{name}-native-%{version}/lib%{name}.so
%{buildroot}%{_libdir}/%{name}