On Sat, Jan 23, 2016 at 9:16 PM Orcan Ogetbil <oget.fedora@xxxxxxxxx> wrote:
Hi folks,
It's been a while. I am giving a shot to update our tuxguitar package
from 1.2 to the recent 1.3. The new release comes with a build system
switch from ant to maven. I do not have much experience with maven, so
I tried to follow the packaging instructions [1] which I found quite
useful. I managed to build the package from source, but I still have 4
problems:
1- tuxguitar-1.3 has an itext5 dependency, but we only ship itext2 in
Fedora. I tried to disable the tuxguitar-pdf plugin (which uses itext)
by various combinations of %pom_remove_dep, %pom_remove_plugin,
%pom_disable_module. The following takes me a couple steps further
%pom_remove_dep -r com.itextpdf:itextpdf
%pom_remove_dep -r com.itextpdf.tool:xmlworker
Also, one alternative is to update the itext dependency to itext5.
Another is to patch your project with itext2, and use the xpath macro to change the dep version:
%pom_xpath_set "pom:project/pom:dependencyManagement/pom:dependencies/pom:dependency[pom:artifactId='itextpdf']/pom:version" "5.???"
or similar
Another is to patch your project with itext2, and use the xpath macro to change the dep version:
%pom_xpath_set "pom:project/pom:dependencyManagement/pom:dependencies/pom:dependency[pom:artifactId='itextpdf']/pom:version" "5.???"
or similar
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>
%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/tuxguitar/. 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 -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}
-- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
