[Mageia-dev] Java-Policy first draft published

[piep]

Refection about Java_Packaging_Policy : what about a jpackage project 
for mageia java based rpm ?

like others I am still a "padawan" packager, but I also plan to work on 
java (and music) packages

I follow this thread with interest for few days and I wonder why nobody 
thinks to just import java packages from jpackage repositories ?


1) For many years jpackage.org project provides strong rpm packages of 
java based applications. These packages are used on the professional 
platform : Red Hat Enterprise Linux.

  Last project, "jpp6", provides rpm packages built on java6 
(JavaRuntimeEnvironment 1.6) and more than 2700 packages are ready to be 
installed on any rpm based system.
see : http://www.jpackage.org/browser/browse.php?jppversion=6.0

This is not the 400 packages of Mandriva project. Jpackage provides most 
of all java applications from the apache foundation (tomcat, maven, 
glassfish, hibernate, jakarta etc...) but also the J2EE application 
server "jboss" (from Red Hat now).

"jpp6" project is still under "Work In Progress" (WIP) state but I guess 
the number of package will reach the number of the actual "stable" 
version 5 : 3327 rpms.
see : http://www.jpackage.org/browser/browse.php?jppversion=5.0


2) JavaRuntimeEnvironment 1.6 aka java6 VM is the version provided in 
Mandriva cooker (and now Mageia caultron I guess) and it already 
provides the "jpackage-utils" package which is necessary to run packages 
from a jpackage repository.
Jpackage now (jpp6) uses java compiler : openjdk

Despite the arguments why Mandriva developers left the jpackage project 
to build their own java packages.
http://wiki.mandriva.com/en/Java_Packaging_Policy#Compatibility_with_proprietary_Java_stacks 


	We are at the beginning of a new rpm based distribution. It would be 
stupid and suicidal to work on our own java packages and reinvent the 
wheel again and again. If we want Mageia becomes a major distribution on 
java application servers also, we have to consider jpackage as source of 
java packages. Then we can concentrate our java packagers to improve the 
"time to market" of jpackage applications and on  desktop application 
(tuxguitar, sweethome3d, JOSM, homeplayer etc..) and all java 
application that lack in jpackage  and why not try to provide them to 
jpackage.



3) If you want to test the jpackage repository on your actual distro.

3.1) add a jpackage repository in mandriva cooker. (test on mdv cooker 
dec 2010)

3.1.1) add the jpackage key

# rpm --import http://www.jpackage.org/jpackage.asc

(ref : http://jpackage.org/gpgkey.php)

3.1.2) replace jpackage-utils-1.7.5 by jpackage-utils-5.0.0
(I guess final version will be jpackage-utils-6.0.0)

# rpm -Uvh 
http://vesta.informatik.rwth-aachen.de/ftp/pub/comp/Linux/jpackage/6.0/generic/free/RPMS/jpackage-utils-5.0.0-2.jpp6.noarch.rpm

3.1.3) add the jpackage-6.0-generic-free depot

	The standard command provides an error :
# urpmi.addmedia jpackage-6.0-generic 
http://vesta.informatik.rwth-aachen.de/ftp/pub/comp/Linux/jpackage/6.0/generic/free 
with hdlist.cz
adding medium "jpackage-6.0-generic"
...retrieving failed: curl failed: exited with 22

no metadata found for medium

This is because urpmi runs the following command :
/usr/bin/curl -q -s --location-trusted -R -f --disable-epsv 
--connect-timeout 60 --anyauth --stderr - -O 
http://vesta.informatik.rwth-aachen.de/ftp/pub/comp/Linux/jpackage/6.0/generic/free/reconfig.urpmi

and this reconfig.urpmi does not exist on the jpackage depot (I guess 
this is a mismatch between "urpmi" version)

solution :
# urpmi.addmedia --probe-synthesis jpackage-6.0-generic-free 
http://vesta.informatik.rwth-aachen.de/ftp/pub/comp/Linux/jpackage/6.0/generic/free/RPMS

3.1.4) add the jpackage-6.0-generic-non-free depot (empty depot on 
2010-dec but can be useful)
# urpmi.addmedia --probe-synthesis jpackage-6.0-generic-non-free 
http://vesta.informatik.rwth-aachen.de/ftp/pub/comp/Linux/jpackage/6.0/generic/non-free/RPMS



4) some major application already packaged on jpp6 :
ant
glassfish
hibernate
jakarta
jboss
log4j
lucene
maven
saxon
tomcat
xerces
xalan
wsdl4j
etc...

see "Available Groups" for more details
http://mirrors.dotsrc.org/jpackage/6.0/generic/free/repoview/index.html


5) some old links found about Co-existence_with_JPackage:
http://wiki.mandriva.com/en/Java_Packaging_Policy#Co-existence_with_JPackage
http://wiki.mandriva.com/en/Policies/Java/JPackage


6) So why don't we consider "jpackage" with the new eye of a new distro 
and consider it as an external java application repository like we 
already use "plf" ?
Why don't we work closer with the jpackage team to improve the urpmi 
connection ?


long life to Mageia,
Pierrick Hervé