Mailinglist Archive: opensuse-packaging (171 mails)

< Previous Next >
Re: [opensuse-packaging] Automated binary java packaging using maven central
Hi Pascal.

Comments inline:

I tested this and it mostly just works TM. Not bad for a prototype :)

On 08/14/2011 04:13 PM, Pascal Bleser wrote:
I've written a successful prototype that does the following:
* generates a completely functional .spec file based on the
metadata of java artifacts (POM) that is available at Maven
Central (http://repo1.maven.org/maven2/)
* does *NOT* build from source but, instead, simply takes the
.jar file from Maven Central and installs it into %{_javadir}
(including the usual symlinks)
* optionally also creates a subpackage with the source jar from
Maven Central (very useful for IDEs such as Eclipse)
* all that including dependencies, as far as they're declared in
the POM file
* written in Perl (hey, it's a prototype ;)), just one file, no
exotic dependencies

The script is there:
https://gitorious.org/pbleser/pbleser/blobs/master/pom2spec

Here's an example on how to run it:
1) pull the script and chmod it:
cd ~/bin
wget https://gitorious.org/pbleser/pbleser/blobs/raw/master/pom2spec
chmod +x pom2spec

2) go to your OBS sandbox and create a new package:
osc mkpac log4j-log4j-1_2_15

This part failed for me. But I am on a new laptop, so I needed to init
my home repo locally.


3) generate the .spec file, passing groupId artifactId and
version:
pom2spec log4j log4j 1.2.15

(if you don't specify the version, pom2spec will give you a list
of possible versions, i.e. those that are available in Maven
Central)

4) well, obviously, build it ;)
osc build ...

Missing step, move the spec into the project/package directory.

===== The longer story...

First of all, I guess that everyone knows by now that the
packaging situation around Java libraries (and, hence,
applications (desktop and server) that depend on those
libraries) is ... let's say... suboptimal.

Very very true.

It is very complex to build those from source as the build
systems that are typically used for Java projects (Ant, Maven,
Gradle, Ant+Ivy, ...) have a dependency management of their own
that is quite difficult to integrate with RPM packaging.

Sometimes face palming impossible.


Stephen Shaw has been putting a lot of effort into doing it
properly since some time and while he's made a lot of progress
already, I think we're still far away from having a useful set
of common Java libraries (there are gazillions of open source
Java libraries and frameworks out there).

Yes, and we are missing the boat there. The fewer rpms we have the
messier it is to support Java.

Hence, I believe that having them as "bad" RPMs (because they're
not built from source but just install the already compiled .jar
files from Maven Central (hence upstream)) is better than not
having them _at all_.
Of course, starting from there, we should still continue to
improve our tool set and experience with building Java packages
from source, in order to replace at least some of those "bad"
RPMs with "good" ones.


I see this as as tool and a repo to bootstrap building more java
packages. We may need a separate repo just so the "bad" rpms intially.

The drawback is that we cannot add our own patches to the
upstream sources, for obvious reasons.
But the advantage of this approach is that it is very easy to
build the RPMs. And, to be honest, I don't think that, in the
past or in the future, we often need to add patches to portable
Java source code that haven't been included upstream already.

99% of the patching I have seen to java packages are to the build.xml
files for messing with class paths or install paths. I cannot recall
ever seeing the sources themselves patched in rpm packages.



Sure, that doesn't work well with the typical policy for the
distribution updates (backport patches instead of version bumps)
but hey... better than nothing, don't you think ?


Yes and in the java world backports really do not exist afaik. Want a
bug fixed ? Update..

===== Now the interactive part...

While writing the pom2spec script, a few questions or, rather, a
need for some decisions, appeared.

We probably can all agree that we should add Provides in those
Java library packages in the same fashion as with Perl packages,
along the lines of this:
Provides: java(${groupId}:${artifactId}) = ${version}
e.g.:
Provides: java(org.springframework:spring-beans) = 2.5.6.SEC02

(the g:a and g:a:v notation is very commonly used in
Java/Maven/Gradle/...)

That would make it easier, more portable and clearly more
future-proof in dependencies (Requires).

But what I'm not sure about, at this point, is how to name the
packages themselves.

I believe we should use fully qualified ${groupId}-${artifactId}
names, e.g.:
Name: org.springframework.spring-beans
^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^
${groupId} ${artifactId}

That (${ŋroupId}:${artifactId}) already is a unique and
canonical name as of Maven Central, which is what 90%+ Java
projects on the planet use (either through Maven, or Ant+Ivy,
or Gradle, or ...).

But that's too long for Joliet. Is that still an issue ?

Works for me. I did not see an issue testing. Where I am more curious
is how we map the provides auto generated by rpm vs build requires in
the spec files generated from the pom file. That will need some
attention it seems.



Another thing is that I believe that it would make our life
easier if we also included the ${version} in the %{NAME} of the
package, in order to be able to install several different
versions of libraries side-by-side.
That way we can always reflect upstream's dependencies as
defined in their POM file (e.g.
org.springframework:spring-beans:2.5.6.SEC02 requiring
log4j:log4j:1.2.15).

Example:
Name: org.springframework.spring-beans-2_5_6_SEC02
Version: 2.5.6.SEC02

Yes, that's a pretty long package name alright.

That would also mean dropping the symlink that drops the
%{version} in %{_javadir}.

How will this affect runtimes ? The rest we can live with.

Feedback please :)

(And thanks for reading this far, I know this email is way too
long, but I wanted to give enough background :)).

cheers

Thanks for taking this on.. Java packaging has become a pain point and
I do not want to see either openSUSE nor SLES become less usable as a
java platform.

Thanks,

Peter
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References