incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Pre-release trial run.
Date Thu, 08 Dec 2011 00:08:25 GMT
I'm really swamped right now. I hope to look at this soon, but given
Leos positive comments below don't be afraid to proceed without my


On 5 December 2011 23:18, Leo Simons <> wrote:
> 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....
> cheers,
> Leo
> 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
>  tarball
> * 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)
> apache-jena-2.7.0-incubator.tar.gz
> * README has a word coppied which obviously should be copied
> * README points at which is
>  empty
> * 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:
>                org.apache.jena:apache-jena:pom:2.7.0-incubating;
>                it doesn't have an associated file or directory.
>        [WARNING] Entry:
>                apache-jena-2.7.0-incubating/javadoc-core/com/hp/hpl
>                /jena/assembler/class-use/BadObjectException.html
>                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]
>        [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]
>        [WARNING] It is highly recommended to fix these problems because they
>                threaten the stability of your build.
>        [WARNING]
>        [WARNING] For this reason, future Maven versions might no longer
>                support building such malformed projects.
>        [WARNING]
>  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

Ross Gardler (@rgardler)
Programme Leader (Open Development)

View raw message