incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: Pre-release trial run.
Date Mon, 05 Dec 2011 23:18:06 GMT
Hey Andy, all,

On Sun, Dec 4, 2011 at 5:17 PM, Andy Seaborne <> wrote:
> Everything ready (ish).
> Mentors - any time to help check all the necessary Apache process has been
> covered would be appreciated.

Yay! Well done, that's looking really really good for a first (second?) RC.
I'm impressed :-). Having said that, let me try and get as annoying as
possible....gna gna gna gna. No seriously, I'm trying to be a hard ass
so that when you get to general@incubator there's either
* no surprises, or
* we have plenty of ammunition at the ready if it's needed...

hope this helps....



ZOMG so many jars!
I've looked at apache-jena-2.7.0-incubator.tar.gz and source releases only,
not at any of the convenience binary jars. Inspecting how the releases are
produced that normally gives me some reasonable confidence all the other files
are also ok. "Reasonable" since, well, I'm never *completely* comfortable
with maven ;-)

If someone could provide me with some instructions for how to reproduce all
those jars from the source code then I can use that to satisfy myself I
understand what is in them. If not, well, *I* am not going to +1 those since
it's too much work to check all those jars by hand.

I have also _not_ tested things work well with maven since that probably
requires more studying of maven docs than I feel like doing. Fortunately we
seem to have critical mass of maven mavens around here so I'll try and stick
to my ignorance!

Test's 'n tools matter! (?)
Here are some legal issues for
* the data files in src-examples/data/, vocabularies/ and testing/ do generally
  not have license information. Some have statements such as
        # (c) Copyright 2004, Hewlett-Packard Development Company, LP
        # All rights reserved.
  What is the license situation for all these files? Unless it interferes with
  testing, there should probably be license headers in these files explaining
  their status. If any of these files are differently-licensed that should be
  indicated as appropriate.
  If these files can't have license headers then there should probably be files
  explaining that in these directories along with a statement as to the details
  of their licensing.
* tools-lib/java2html.jar seems to originate from
  which is licensed either GPL or CPL. Per
  this file needs an "appropriate label".
* tools-lib/rdf-html.jar seems to be a file that was built quite a while ago
  from jena source code. Where is the source code for that file? It should
  probably be part of the distribution?

I think these above issues should be addressed one way or another.

Relentless nitpicking
And then what follows now are a bunch of tiny small suggestions that would
absolutely not prevent me voting +1, but that I wrote down since you might like
the feedback and/or want to clean things up while doing all this release stuff:

Download area
* it was not clear to me at first where to get the source release. In fact
  I thought I was downloading the source release when I downloaded the main
* slightly surprised there's no .tar.gz for the sources, as an unixy end user
  I prefer those for irrational reasons
* you should probably explain (or point to explanation for) gpg verification
  in README at
  see as example
* the most popular apache projects have a CHANGES or RELEASE_NOTES file in the
  dist area
  see examples at
  this is absolutely not required (AFAIK) but you may want to consider doing it
  as a convenience for users (note one advantage of having them hear instead of
  or as well as on the website is that these files get mirrored out)

* README has a word coppied which obviously should be copied
* README points at which is
* ReleaseNotes-Jena.txt goes up to 2.6.5 but the release is 2.7.0, I'd expect
  to learn what's changed with 2.7.0.
* Similarly, ReleaseNotes-ARQ.txt goes up to 2.8.9 but the release is 2.9.0.
* I don't like I downloaded
  a .zip, opened it up, found a BUILD file, which directed me to svn first and
  then to manually download a bunch more zips. Then there's unzipping those,
  having maven download the internet so it can run itself, etc. I got
  pretty impatient halfway through.
* BUILD refers to a module jena-zip (to `mvn package`) that doesn't actually
  exist, this should point at itself
* `mvn package` produces a ton of warnings such as
        [WARNING] Cannot include project artifact:
                it doesn't have an associated file or directory.
        [WARNING] Entry:
                longer than 100 characters.
        [WARNING] Resulting tar file can only be processed successfully by
                GNU compatible tar commands
  which I assume are either "normal" or because I have an old maven. It does
  build 'something' in the end :-)
* what a weird version number :)
* see comment above about release notes
* INSTALL.txt talks about jars that don't exist and docs that don't exist.
  It reads as if it's written for an older binary release?
* `ant build.xml` fails for me with
            [javac] .../hpl/jena/util/ package org.slf4j
                does not exist
                [javac] import org.slf4j.Logger;
            [snip many more import errors]
            [javac] 100 errors
            [javac] 13 warnings

        ..../build.xml:165: Compile failed; see the compiler error output
                for details
  I would guess you just want to remove build.xml?
* readme.html redirects to doc/readme.html which does not exist. It should
  probably just be removed?
* `mvn clean install` gives me this warning:
        [WARNING] Some problems were encountered while building the effective
                model for org.apache.jena:jena-core:jar:2.7.0-incubating
        [WARNING] 'version' contains an expression but should be a constant.
                @ org.apache.jena:jena-core:${ver.jena},
                ..../pom.xml, line 27, column 12
        [WARNING] It is highly recommended to fix these problems because they
                threaten the stability of your build.
        [WARNING] For this reason, future Maven versions might no longer
                support building such malformed projects.
  I imagine this could be maven complaining because I didn't update it for
  a year. You may want to specify minimum supported maven version or something
  like that?
  And then it fails because I should've build iri first. After that (see
  below), I thought a test was hanging but it was just that it was doing 10k
  tests without any console output. And then it built :-)
* `ant build.xml` fails with
          BUILD FAILED
          ..../build.xml:32: Directory does not exist: ..../doc/javadoc
  I'd consider removing build.xml.
* get same mvn [WARNING] as above, but it doesn't seem to matter
* README.txt points at doc/ a few times but doc/ does not exist
* get same mvn [WARNING] as above, but it doesn't seem to matter

View raw message