Bug 426883 - Review Request: brazil - Extremely small footprint Java HTTP stack
Review Request: brazil - Extremely small footprint Java HTTP stack
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Andrew Overholt
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 426884
  Show dependency treegraph
 
Reported: 2007-12-27 18:07 EST by Mat Booth
Modified: 2008-04-30 14:55 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-30 14:55:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
kevin: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Mat Booth 2007-12-27 18:07:17 EST
Spec URL: http://www.matbooth.co.uk/fedora/brazil.spec
SRPM URL: http://www.matbooth.co.uk/fedora/brazil-2.3-1.fc8.src.rpm
Description: Brazil is as an extremely small footprint HTTP stack and flexible architecture for adding URL based interfaces to arbitrary applications and devices from Sun Research Labs. This package contains the core set of classes that are not dependent on any other external java libraries.

This package is submitted because it is a dependency of eclipse-epic (another new package I am about to submit and will link to shortly). Only the core classes are built and packaged because that is all the needed for eclipse-epic and I didn't want to cause dependencies of all brazil's ancilliary classes to unnecessarily become dependencies for eclipse-epic. And I'm thinking that if demand occurs in the future for the full gamut of brazil classes, I can easily add a brazil-extras sub-package(s) or something.

---

I notice that some other Java libs (jdom for example) use the "Development/Libraries/Java" group however this yields a non-standard group rpmlint warning, so I've just used "Development/Libraries" for now. I hope this is fine.

Rpmlint on the source rpm gives the following:

brazil.src: W: strange-permission get-brazil.sh 0755

This is merely the script that grabs the source from Sun's Download Centre, which is deliberately executable. It can safely be ignored.

There's also a minor error in the javadoc generation, but I didn't think it was really worth patching out a single comment line from the source, especially when it doesn't appear to adversely affect it in any way.

---

This is the first of two packages I am submitting, the second is dependent on this one. These are my first packages so I'm also looking for sponsorship. While I've been working on this package I've given some pre-reviews on bug #417711 and bug #420161 and I'm planning to do more as time permits.

Thanks for your time.
Comment 1 Mat Booth 2007-12-27 18:16:43 EST
The other new package review I've requested that depends on this package is,
predictably enough, bug #426884.
Comment 2 Mat Booth 2008-03-28 15:05:03 EDT
This currently doesn't build on Rawhide because of bug 439168. :-(
Comment 3 Mat Booth 2008-03-30 10:41:22 EDT
(In reply to comment #2)
> This currently doesn't build on Rawhide because of bug 439168. :-(

Updating findutils seems to fix it, though.
Comment 4 Mat Booth 2008-04-13 16:03:30 EDT
I've updated this package according to the newly approved Java guidelines. The
spec also now builds a demo rpm containing sample brazil projects. The spec
and srpm are as follows:

Spec URL: http://www.matbooth.co.uk/fedora/brazil.spec
SRPM URL: http://www.matbooth.co.uk/fedora/brazil-2.3-2.fc9.src.rpm

Rpmlint is now silent on all packages.
Comment 5 Andrew Overholt 2008-04-17 10:20:51 EDT
I'll take this.
Comment 6 Andrew Overholt 2008-04-17 10:51:24 EDT
Nice job, Mat!  A very clean package.  Here's my review.  Everything's good to
go pending spot's legal approval of the fetching (see the last question below,
spot).  Assuming that is given the go-ahead, this package is APPROVED.

MUST items that either have comments or need looking into:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* verify source and patches (md5sum matches upstream, know what the patches do)
  - the tarball I created using your script didn't have the same md5sum as
    yours, but a recursive diff of the exploded tarball resulted in no
    differences so I'll assume it's a timestamp thing
? specfile is legible
  - two grammar nit-picks (feel free to ignore my pedantry if you wish ;) :
    "URL based" -> "URL-based"
    "java" -> "Java"

Questions:

- does upstream not provide any build mechanism?
- have you considered offering upstream your build.xml?
- your signal-handling patch doesn't affect runtime, right?
- is the script for fetching the source acceptable to Fedora "legal" (CCing
  spot)?  To download myself I had to click through to accept the SPL.
Comment 7 Mat Booth 2008-04-17 15:53:48 EDT
(In reply to comment #6)
> Nice job, Mat!  A very clean package.  Here's my review.  Everything's good to
> go pending spot's legal approval of the fetching (see the last question below,
> spot).  Assuming that is given the go-ahead, this package is APPROVED.
> 

Thanks. :-)

> MUST items that either have comments or need looking into:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> * verify source and patches (md5sum matches upstream, know what the patches do)
>   - the tarball I created using your script didn't have the same md5sum as
>     yours, but a recursive diff of the exploded tarball resulted in no
>     differences so I'll assume it's a timestamp thing

I didn't try md5sum, but you're right. The sum changes every time I run the
download script. It strips out all the pre-built binaries and source that isn't
used in the build or is licenced differently before tarballing. This can be done
at build time instead if it's a problem.

> ? specfile is legible
>   - two grammar nit-picks (feel free to ignore my pedantry if you wish ;) :
>     "URL based" -> "URL-based"
>     "java" -> "Java"
> 

No problem, I'll change them.

> Questions:
> 
> - does upstream not provide any build mechanism?

Yes, but their ant script is incomplete (missing Javadoc build, mostly). I think
it'll be easier to maintain a separate script than to massively patch upstream's
in this case.

> - have you considered offering upstream your build.xml?

I have now. I may shoot an email at their mailing list about it...

> - your signal-handling patch doesn't affect runtime, right?

That's the real question. I have only ever used brazil as part of the EPIC Perl
Eclipse plugin and since that is the only package that uses it, I've only tested
it as part of that. The is no, as far as I can tell. Eclipse is able to stop and
start the brazil server and CGI process without problem for my CGI Perl projects.

The reason for patch was to get it building on GCJ, however it does build
without the patch on the OpenJDK. What would be the right thing do here, drop
support for GCJ in favour of less modifications to the upstream code?

> - is the script for fetching the source acceptable to Fedora "legal" (CCing
>   spot)?  To download myself I had to click through to accept the SPL.

I wanted to make it an easy and automated process, since I'm lazy like that. The
SPL licence is included in the main package and the source files are each headed
with licence information, though alternative download instructions could be
included if I fail a Spot check. :-)

Thanks for your time.

PS, did you mean to assign the bug to me?
Comment 8 Andrew Overholt 2008-04-18 09:19:44 EDT
(In reply to comment #7)
> The reason for patch was to get it building on GCJ, however it does build
> without the patch on the OpenJDK. What would be the right thing do here, drop
> support for GCJ in favour of less modifications to the upstream code?

I think what you've done is fine.  If someone notices problems with brazil on
its own, we can always revert the patch.

Please post new URLs when you have them for the grammatical changes (if you're
going to change them ... they're not blockers).

spot:  I'm putting the ball in your court here for a decision on the
click-through situation.
Comment 9 Mat Booth 2008-04-18 09:46:42 EDT
(In reply to comment #8)
> Please post new URLs when you have them for the grammatical changes (if you're
> going to change them ... they're not blockers).
> 

Sure, I was just waiting to see if I needed to change anything else.

SPEC and SRPM are as follows:

Spec URL: http://www.matbooth.co.uk/fedora/brazil.spec
SRPM URL: http://www.matbooth.co.uk/fedora/brazil-2.3-3.fc9.src.rpm
Comment 10 Andrew Overholt 2008-04-18 11:46:08 EDT
Thanks, Mat.  Outside of spot's thoughts on the click-through situation, this is
APPROVED.
Comment 11 Tom "spot" Callaway 2008-04-25 16:39:06 EDT
Script is fine, sorry it took so long. :) 
Comment 12 Mat Booth 2008-04-25 18:50:30 EDT
Thanks Tom and Andrew for all your help.

Comment 13 Mat Booth 2008-04-25 18:52:47 EDT
New Package CVS Request
=======================
Package Name: brazil
Short Description: Extremely small footprint Java HTTP stack
Owners: mbooth
Branches: F-9
InitialCC: 
Cvsextras Commits: yes
Comment 14 Kevin Fenzi 2008-04-26 12:39:41 EDT
I assume from comment #10 this is approved, so setting the fedora-review flag to
+. ;) 

cvs done.
Comment 15 Mat Booth 2008-04-29 18:38:41 EDT
I'd like an F-8 branch of this to support the F-8 branch of eclipse-epic. See:
https://bugzilla.redhat.com/show_bug.cgi?id=426884#c28


Package Change Request
======================
Package Name: brazil
New Branches: F-8
Comment 16 Kevin Fenzi 2008-04-29 19:07:40 EDT
cvs done.
Comment 17 Mat Booth 2008-04-30 14:55:23 EDT
Built for all requested branches. Closing.

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