On 08/15/2011 01:13 AM, 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
Hi Pascal, I think is a good idea, I once wrote something similar but did not get that far... even the name was the same :-).
===== 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.
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.
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).
I agree with your view on the matter. I can speak with some experience here because we had to build a hundred of package in order to get SUSE Manager running. We are now in the process to reconcile those packages in a project called Java:base, merging our packages with stuff we rebuilt from Fedora, stuff from Java:packages and stuff from Stephen. The main issue for us (my team) with this approach is that we need to be able to patch sources to give L3 support (we can't wait for the next upstream release). When building Java:base, we gave up with maven. We have a maven3 package from binaries, but we are not using it. We continued packaging every maven dependent package using the maven ant plugin, generating build.xml and maven-build.xml and then using ant. Worked very well on most of the cases. However, we will never be able to package more complex stuff: think glassfish. Just imagine Redhat is still unable to build JBoss, which they own, and they are resorting to add mvn-build support directly to koji to handle the complexity. Still, I think your tool covers the 90% of the cases where people just want to run stuff, and this should not get lost. I propose to build a self-contained repository for Java based on this tool, it would be lot of value for the community and SUSE customers. The main goal of this repo would be more completeness and being vanilla instead of patches and bugfixes. Then we could work to make Java:base compatible with the "evil" packages, so that they can be mixed without much trouble: Provides, locations, etc. For the Provides part, we should give a look at what Fedora is doing as they are already adding provides for OSGi at least, and being compatible would be nice. Now that you are still playing with the technology, another project that looks interesting is Ivy Roundup, with is a self-contained and consistent repository of packager.xml metadata to be used with the Ivy packager resolver, this allows ivy to resolve an artifact directly from the upstream project (even unziping dist files) allowing the Roundup project itself to contain only metadata: http://code.google.com/p/ivyroundup/ cheers, and keep up this cool stuff. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org