JPackage and Fedora

Lee Faus lee.faus at alfresco.com
Wed Aug 13 23:17:10 UTC 2008


Alfresco is in the same boat.  Not allowing binary compatible RPMs from a third party repo only causes proliferation.  Plus you can end up with version conflicts.  JPackage is the defacto location for Java RPMs, not Fedora.  I also notice that a number of Fedora Java RPMs already are JPP packages based on the naming convention.  The folks from Fedora grab the source RPM from JPackage and then recompile it to get it to run under Fedora.  There are some problems with this approach because you don't know what version of Java this package was compiled against.  GCJ, IcedTea, OpenJava, it is a big assumption that you can compile it under one and get it to run under another (try compliling Hibernate under GCJ).  There needs to be a common repository of ONLY java packages.  Why Fedora wants to duplicate work that is already established and replicate disk space just doesn't make sense.  Plus, I would think the process here would also follow for RHEL and CentOS.  Do we really want different YUM repos out there with the same RPM?  Will I end up being responsible for that RPM downstream in CentOS and RHEL?  Great discussion Matt, keep it up.

Lee Faus
Director of Solution Engineering 
Alfresco

----- Original Message -----
From: "Matthew Dahlman" <mdahlman at jaspersoft.com>
To: "Jason Hibbets" <jhibbets at redhat.com>
Cc: fedora-isv-sig-list at redhat.com
Sent: Wednesday, August 13, 2008 5:20:38 PM GMT -05:00 US/Canada Eastern
Subject: RE: JPackage and Fedora

Yes, I'd say that's a good way of rephrasing my question.

As an additional point I'll add this. We expect that many other vendors
will use many of the same jar files that we use. Some credibility is lent
to this expectation by the fact that the big majority of our 80 jar files
are already in JPackage. (e.g. acegi-security.jar, axis.jar,
hibernate.jar, jakarta-commons-io.jar, etc.)

While the idea of Jaspersoft maintaining 80 jars as well as our own
JasperServer jars sounds... daunting. The idea that we would contribute to
maintaining a common library of jars seems much more reasonable. That's
the reason that JPP caught my eye.

I'll stay tuned to see what Karsten and Tom have to add. For now I'll
assume that JPP is probably not the right solution, but that the right
solution will eventually shake out of this list.

-Matt
Jaspersoft


-----Original Message-----
From: Jason Hibbets [mailto:jhibbets at redhat.com] 
Sent: Wednesday, 13 August, 2008 13:02
To: Matthew Dahlman
Cc: fedora-isv-sig-list at redhat.com
Subject: Re: JPackage and Fedora



Matthew Dahlman wrote:
> 
> Therefore it would be good if we had a standard way to distribute the 
> various jars along with their source. That brings us to JPackage (JPP).
> According to their site (http://www.jpackage.org/aboutjpp.php):
> The JPackage Project has two primary goals:
> - To provide a coherent set of Java software packages for Linux, 
> satisfying all quality requirements of other applications.
> - To establish an efficient and robust policy for Java software 
> packaging and installation.
> 

Matt,

Disclaimer: Matt and I had a brief discussion about this in person last
week at LinuxWorld (over some really good Vietnamese I might add).

So...I'm trying to remember the details of our talk.  And iirc, Matt, you
were presenting the issue about having to upload and maintain 60+ jar
libraries (into the EPEL repo) in order to make all things JasperSoft
work.  You're looking for a way that makes this scalable and re-usable by
others?  Is that a good summary?  I've seen that Karsten responded, but I
wanted to try and pose the question in a different way. 
  Is that the question you are asking?

Jason

--
Jason Hibbets, RHCE
RHX & ISV Marketing Specialist
Office - 919.754.4181
Red Hat :: 1801 Varsity Drive :: Raleigh, NC  27606

IT executives: Red Hat #1 in value. Again.
http://www.redhat.com/promo/vendor/

_______________________________________________
Fedora-isv-sig-list mailing list
Fedora-isv-sig-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-isv-sig-list




More information about the Fedora-isv-sig-list mailing list