Bug 446134 - Review Request: jsr-305 - reference implementation of JSR-305
Review Request: jsr-305 - reference implementation of JSR-305
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
Depends On:
Blocks: 1128852
  Show dependency treegraph
Reported: 2008-05-12 18:19 EDT by Jerry James
Modified: 2015-01-01 15:57 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-09-17 10:18:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tibbs: fedora‑review+
opensource: fedora‑cvs+

Attachments (Terms of Use)

  None (edit)
Description Jerry James 2008-05-12 18:19:49 EDT
Spec URL: http://jjames.fedorapeople.org/jsr-305/jsr-305.spec
SRPM URL: http://jjames.fedorapeople.org/jsr-305/jsr-305-0-0.1.20071105svn.src.rpm
Description: This package contains reference implementations, test cases, and other documents for Java Specification Request 305: Annotations for Software Defect Detection.

This is a prerequisite for findbugs.  There has been no official release, so it is a snapshot of the Subversion repository, whose last checkin occurred on 5 Nov 2007.  The license terms do not appear in any file in the repository, so I have included a downloaded copy of http://code.google.com/p/jsr-305/index.html, which claims that the project is available under the "New BSD License", which is the "BSD" license tag for Fedora.
Comment 1 Jerry James 2008-05-12 18:22:51 EDT
I forgot to note that I asked upstream to include a license file:
http://groups.google.com/group/jsr-305/msg/959fee95941a8743.  I made this
request on 18 Apr 2008, with no response so far.
Comment 2 Jerry James 2008-06-02 18:32:58 EDT
Upstream has been active recently.  The patches from my original submission have
been accepted.  Unfortunately, there is still no license file.  New versions of
the spec and srpm are here:

Spec URL: http://jjames.fedorapeople.org/jsr-305/jsr-305.spec
SRPM URL: http://jjames.fedorapeople.org/jsr-305/jsr-305-0-0.1.20080527svn.src.rpm
Comment 3 Jason Tibbitts 2008-06-28 18:37:09 EDT
I have essentially no idea what this package is for, and very little knowledge
of Java, but it's been in the queue for six weeks and I can read the packaging
guidelines as well as anyone else so I'll see what I can do.

This builds fine for me; rpmlint says:
  jsr-305.x86_64: W: non-conffile-in-etc /etc/maven/fragments/jsr-305
Unfortunate; these should be under /usr/share but that's what our maven package
does so you have no choice.
  jsr-305.x86_64: W: non-standard-group Development/Libraries/Java
  jsr-305-javadoc.x86_64: W: non-standard-group Development/Documentation
These don't matter; we don't care what goes in Group:.

The URL in the spec (and the comment before the License: tag, and what's in
Source1) are 404 for me.  It works if you remove the "index.html" bit.

I don't think it's necessary to include a copy of the upstream web page to prove
the license, although if you have a copy of the email sent in response to your
query, perhaps you might want to include that.  If you do want to include a
copy, though, please do use a functioning URL.

You will need to include instructions for actually obtaining the subversion
snapshot that you include in the package.  And it would be a good idea to
version the tarball as well.  See http://fedoraproject.org/wiki/Packaging/SourceURL

Looking at the debug package, it seems that a bunch of the source is missing.  I
do not know enough about java to tell if something's gone wrong here or if the
source files just aren't supposed to be there for whatever reason.  Can you have
a look?

I thought the Java folks had decided that they didn't want to make unversioned
symlinks for javadocs.  I don't, however, see it in any of the guidelines,
neither encouraged nor discouraged.

This package should not own /etc/maven/fragments.  The same goes for
/usr/share/maven2/poms.  Unfortunately this is actually specified by the
guidelines, so I'm working to try and get the guidelines fixed, because this is
simply broken.

The guidelines indicate that all of the aot compilation bits should be

X can't compare source files with upstream; no instructions for making the svn 
   checkout and Source1: URL does not exist.
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text not included upstream.
* BuildRequires are proper.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
? debuginfo package looks a bit too empty.
* rpmlint has acceptable complaints.
* final provides and requires are sane:
   jsr-305 = 0-0.1.20080527svn.fc10
   java >= 1.5
   java-gcj-compat >= 1.0.31

   jsr-305-javadoc = 0-0.1.20080527svn.fc10
   jsr-305 = 0-0.1.20080527svn.fc10

* %check is not present; no test suite usptream.  (Although there's a couple of 
   test directories in the tarball, they're empty.)
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
X shouldn't own /etc/maven/fragments or /usr/share/maven2/poms
* no duplicates in %files.
* file permissions are appropriate.
X scriptlets shoudl consitionalize the aot bits.
* code, not content.
* %docs are not necessary for the proper functioning of the package.
* no pre-built jars
* single jar, named after the package
* jarfiles are under _javadir.
* javadocs are under _javadocdir.
* maven called properly.
* no wrapper script necessary.
X gcj should be called conditionally.
Comment 4 Jerry James 2008-06-30 17:06:13 EDT
Thanks once again for doing a review for me, Jason.

This package defines some annotations that Java programmers use to declare
various properties of their code.  Those annotations are consumed by the
findbugs tool, which I will be submitting to Fedora Real Soon Now.

I fixed the broken URLs and dropped the index.html file.  Incidentally, upstream
has promised to include a LICENSE file at some point; see
http://groups.google.com/group/jsr-305/msg/e6d62dc6cd7fe361.  This is noted in
the spec file.

I have included subversion checkout instructions, and have versioned the
tarball.  I have made the package own what it puts into /etc/maven/fragments and
/usr/share/maven2/poms instead of owning the directories.  As far as I know, the
question about versioned symlinks for javadocs is still unresolved, so I left
that bit alone.  I have conditionalized the GCJ bits.

Some source files do not appear in the debuginfo package because they contain no
code.  Those files contain only annotation definitions.  This is why I dropped
the GCJ bits from the jcip-annotations package altogether, because GCJ produces
nothing useful from annotation definition only files.  There are some files with
code in this package, though, so I left the GCJ bits in; those files show up in
the debuginfo package.

New versions of the spec file and SRPM are here:
Comment 5 Jason Tibbitts 2008-06-30 18:33:53 EDT
Thanks for the info, and the description of the debuginfo package.

The ownership (and perhaps location) of the maven directories is under
discussion currently and its possible that ownership of those directories will
move into jpackage-utils by the end of the week.

I'm going to go ahead and take this for review, but I'm going to wait until that
situation becomes clear before I approve anything.
Comment 6 Jerry James 2008-07-01 15:07:22 EDT
I understand.  I'm in no hurry.  I have to wait for the next findbugs release
anyway, which will include some patches I pushed upstream that fix a handful of
build/deployment problems on Fedora.  Thanks again.
Comment 7 Jason Tibbitts 2008-07-03 22:32:01 EDT
OK, please let me know when you'd like for me to take another look.  The java
folks have indicated that the directory ownership bits will be fixed soon so I'm
prepared to move forward with this whenever you're ready.
Comment 8 Jerry James 2008-07-07 14:29:13 EDT
I'd like to proceed with this package once the maven directory issue is
finalized.  That way it can be in place when the next findbugs release occurs.
Comment 9 Jerry James 2008-08-04 15:55:52 EDT
Has the maven directory issue been resolved?  If so, I'd like to move forward with this review.  A new findbugs release is supposed to be out within the next couple of weeks, and I'd like to have this package in place by then.  Upstream (which is also upstream for findbugs) has been active recently with some changes needed for the new findbugs version.  New versions of the spec file and SRPM are here:

Comment 10 Jason Tibbitts 2008-08-04 16:01:34 EDT
I believe that the maven stuff is done, but I am out of the country for another few days so I won't be able to look at this until, most likely, next weekend.
Comment 11 Jason Tibbitts 2008-08-09 12:56:05 EDT
OK, I'm back from vacation and have my build infrastructure running again.

Things still build.
The checkout instructions work fine.
The directory ownership issues are resolved on all sides.
debuginfo issues are explained.
gcj bits are conditionalized properly.

Everything looks good to me; APPROVED
Comment 12 Jerry James 2008-08-11 11:10:44 EDT
New Package CVS Request
Package Name: jsr-305
Short Description: Java annotations for software defect detection
Owners: jjames
Branches: F-9
Cvsextras Commits: yes
Comment 13 Kevin Fenzi 2008-08-11 13:28:30 EDT
cvs done.
Comment 14 Jerry James 2008-09-17 10:18:16 EDT
I still haven't figured out what to do about the missing PPC64 maven2 on Fedora 9, but this package now exists in Rawhide, so I'm closing this bug.  Thanks, Jason!
Comment 15 Richard Fearn 2015-01-01 08:31:16 EST
Package Change Request
Package Name: jsr-305
New Branches: el6 epel7
Owners: richardfearn
Comment 16 Till Maas 2015-01-01 15:57:32 EST
Git done (by process-git-requests).

Note You need to log in before you can comment on or make changes to this bug.