FAQ Search Today's Posts Mark Forums Read

» Linux Archive
Home
New Posts
Search
FAQ


Go Back   Linux Archive > Redhat > Fedora Development Java

 
 
LinkBack Thread Tools
 
Old 10-27-2008, 09:01 PM
"Jerry James"
 
Default Fedora & JPackage

A few months back, I had to start using a web service provided by a
certain commercial content management system. This particular web
service uses a namespace that is provided only by Apache Axis 1. At
that time, I discovered that we are two versions behind on this dead
product [1] (Apache Axis 2 is the version under active development).
I started looking into what would be needed to get Apache Axis 2 into
Fedora, and discovered a long list of missing dependencies and a long
list of packages that would need to be upgraded.

More recently, I took over the pmd package, and found that 3 other
packages would need to be upgraded to move pmd to a newer version [2]
[3] [4].

Both events made me wonder how much we are gaining by drawing spec
files from JPackage, and how much we are losing. I wondered whether
maintainers were not moving forward to newer versions of their
packages because the JPackage versions were not moving forward. So I
collected a little data on the subject. This is far from the final
word; more information has to be collected to make any final
determination. But I thought some of you might find what I have
collected so far interesting.

http://jjames.fedorapeople.org/java.html

Comments welcome.

Relevant bugs:
[1] https://bugzilla.redhat.com/show_bug.cgi?id=231153
[2] https://bugzilla.redhat.com/show_bug.cgi?id=465985
[3] https://bugzilla.redhat.com/show_bug.cgi?id=465987
[4] https://bugzilla.redhat.com/show_bug.cgi?id=465989
--
Jerry James
http://loganjerry.googlepages.com/

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 10-27-2008, 09:45 PM
David Walluck
 
Default Fedora & JPackage

Jerry James wrote:

Both events made me wonder how much we are gaining by drawing spec
files from JPackage, and how much we are losing. I wondered whether
maintainers were not moving forward to newer versions of their
packages because the JPackage versions were not moving forward. So I


I have a similar table listing the jbossas dependencies in JPackage and
Fedora. I found that many more packages were up to date in JPackage and
that many packages don't even exist in Fedora.


The simple fact is that there are very few people packaging for
JPackage, and even less packging for Java for Fedora. There is also a
very anti-Java attitude from most Fedora users. Packages are even harder
to maintain when people try to fracture such a small community in this way.


I am not sure what the exact problem is that you're uncovering. We can
take the junit4 as an example: (a) junit4 in JPackage is newer than
Fedora (before I updated it) and (b) junit4 in JPackage has a full
version of hamcrest while Fedora didn't have any version (before I
updated it and hacked it up). The hamcrest package was created primarily
by non-Red Hat employess/non-Fedora contributors.


Also, concerning your webpage:

There is no findbugs-specific version of bcel---they simply need a
version which has a certain fix in CVS. I didn't make any assumptions
here---I verified this with the findbugs devs upstream.


The maintainer of cryptix-asn1 probably had a good reason for the
snapshot. It's very common in the Java world to use all sorts of
unreleased versions of software upstream, and that bad practice is
sometimes trickles down unavoidably.


The jcip-annotations and jsr-305 versions are taken from maven, so since
this is what upstream refers to them by, then I assume them to be correct.


--
Sincerely,

David Walluck
<david@zarb.org>

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 

Thread Tools




All times are GMT. The time now is 07:00 AM.

VBulletin, Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org