Bug 504891

Summary:	Review Request: trove - Efficient Java collections
Product:	[Fedora] Fedora	Reporter:	Jerry James <loganjerry>
Component:	Package Review	Assignee:	Nobody's working on this, feel free to take it <nobody>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	fedora-package-review, guido.grazioli, mefoster, notting
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-11-17 10:29:34 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jerry James 2009-06-09 22:47:20 UTC

Spec URL: http://jjames.fedorapeople.org/trove/trove.spec
SRPM URL: http://jjames.fedorapeople.org/trove/trove-2.0.4-1.fc10.src.rpm
Description: The GNU Trove library has two objectives:
- Provide "free" (as in "free speech" and "free beer"), fast, lightweight
  implementations of the java.util Collections API.  These implementations
  are designed to be pluggable replacements for their JDK equivalents.
- Whenever possible, provide the same collections support for primitive types.
  This gap in the JDK is often addressed by using the "wrapper" classes
  (java.lang.Integer, java.lang.Float, etc.) with Object-based collections.
  For most applications, however, collections which store primitives directly
  will require less space and yield significant performance gains.

Comment 1 Jason Tibbitts 2009-06-11 19:51:59 UTC

Any comments on the conflict between this and ESR's Trove project?  http://catb.org/~esr/trove/

Is the other project sufficiently dead that this isn't an issue?  Even this project's upstream seems to use "trove4j" in places.

Comment 2 Jerry James 2009-06-11 19:56:31 UTC

I don't know anything about that other Trove project, but it sure appears to be dead.  It's developer mailing list doesn't even exist any more.  However, I'm all for avoiding name conflicts.  Should I call this submission "trove4j", do you think?

Comment 3 Jason Tibbitts 2009-11-10 20:08:30 UTC

*** Bug 532521 has been marked as a duplicate of this bug. ***

Comment 4 Guido Grazioli 2009-11-11 00:37:09 UTC

I'm interested in this package, Jerry are you still working on it?
Some quick things:
- renaming to trove4j seems reasonable (other distros did that also)
- prefer %global over %define
- group Development/Libraries/Java is not standard, change it to Development/Libraries
- -javadoc subpackage should Requires: jpackage-utils too
- would packaging lastest stable ver 2.1.0 be feasible?
- as per gcj guidelines, in %%files:
%if %{with_gcj}
- %{_libdir}/gcj/%{name}
+ %attr(-,root,root) %{_libdir}/gcj/%{name}
%endif

Comment 5 Jerry James 2009-11-12 23:16:32 UTC

Actually, my reason for wanting this package in Fedora vanished a couple of months ago.  I'm still willing to see it through if nobody else wants to so do, but if someone else is interested in maintaining, I'm happy to pass the baton.

Otherwise, I'll fix the problems noted in comment 4 sometime in the next 24 hours or so.

Comment 6 Mary Ellen Foster 2009-11-16 21:26:54 UTC

I have a package-in-progress of version 2.1 in bug 532521 if anyone's interested -- Jerry, do you still want to package this?

Comment 7 Jerry James 2009-11-16 21:39:50 UTC

Not really.  The package I wanted to push that depended on this turned out to have some severe license problems.  Please go ahead and take it.  I'm not sure what the proper bugzilla etiquette is, though.

Comment 8 Mary Ellen Foster 2009-11-17 10:29:34 UTC

How reversing the "closed duplicate" direction of the two bugs?

*** This bug has been marked as a duplicate of bug 532521 ***