[fedora-java] building new tuxguitar with maven

Christopher ctubbsii-fedora at apache.org
Sun Jan 24 04:03:15 UTC 2016


On Sat, Jan 23, 2016 at 9:16 PM Orcan Ogetbil <oget.fedora at gmail.com> 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


> 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/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 -p -m 755
server/native/target/%{name}-native-%{version}/%{name}-native-%{version}/lib%{name}.so
%{buildroot}%{_libdir}/%{name}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/java-devel/attachments/20160124/796bc267/attachment.html>


More information about the java-devel mailing list