You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2011/12/01 14:11:25 UTC
Re: Pre-release trial run.
Prototype layout for the incubator/dist/jena area:
This ends up are:
http://www.apache.org/dist/incubator/jena/
and is mirrored and archived.
The layout is one subdirectory per module, with the zip download at the
top level.
The observant will notice that is it is not quite all the files - it
does not contain the .asc.md5 and .asc.sha1 files, nor jena-top
Other projects don't dist these. It's an attempt to make things a bit
more findable.
It's assembled (by script) based in the installed artifacts, in this
case the trial run repo.
Andy
Re: Pre-release trial run.
Posted by Ross Gardler <rg...@opendirective.com>.
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
input.
Ross
On 5 December 2011 23:18, Leo Simons <ma...@leosimons.com> wrote:
> Hey Andy, all,
>
> On Sun, Dec 4, 2011 at 5:17 PM, Andy Seaborne <an...@apache.org> 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 jena-core-2.7.0-incubating-source-release.zip:
> * 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
> http://www.java2html.de/
> which is licensed either GPL or CPL. Per
> http://www.apache.org/legal/resolved.html#category-b
> 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
> http://people.apache.org/~andy/proto-dist/
> see http://www.apache.org/dist/httpd/#sig as example
> * the most popular apache projects have a CHANGES or RELEASE_NOTES file in the
> dist area
> see examples at
> http://www.apache.org/dist/httpd/CHANGES_2.3.15
> http://www.apache.org/dist/ant/RELEASE-NOTES-apache-ant-1.8.2.html
> http://www.apache.org/dist/tomcat/tomcat-7/v7.0.23/RELEASE-NOTES
> http://www.apache.org/dist/lucene/java/3.5.0/changes-3.5.0/Changes.html
> 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 http://incubator.apache.org/jena/getting_started/ 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.
>
> apache-jena-2.7.0-incubating-source-release.zip
> * I don't like apache-jena-2.7.0-incubating-source-release.zip. 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 :-)
>
> jena-top-0-incubating-source-release.zip
> * what a weird version number :)
>
> jena-core-2.7.0-incubating-source-release.zip
> * 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/Metadata.java:28: package org.slf4j
> does not exist
> [javac] import org.slf4j.Logger;
> [snip many more import errors]
> [javac] 100 errors
> [javac] 13 warnings
>
> BUILD FAILED
> ..../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 :-)
>
> jena-iri-0.9.0-incubating-source-release.zip
> * `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
>
> jena-arq-2.9.0-incubating-source-release.zip
> * 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)
OpenDirective http://opendirective.com
Re: Pre-release trial run.
Posted by Andy Seaborne <an...@apache.org>.
On 05/12/11 23:18, Leo Simons wrote:
> Hey Andy, all,
>
> On Sun, Dec 4, 2011 at 5:17 PM, Andy Seaborne<an...@apache.org> 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
Leo,
Thanks for the review. Being nit-picking is good (I'm going to regret
saying that sometime!) for this step because once we get thing sorted
out then the project will run more smoothly.
I'm currently working though some SPARQL review work today; I find it
easier to serialize review processing but I have read through the
comments and they makes sense to me. I'll reply in full ASAP.
We do have some maven-isms which I will 'explain' ("rant about"); the
Apache style and the RAT do push us more towards a single trunk,
multi-module, one version number build. We will then have to work out
how to release individual modules; or not, and always release everything.
As far as I know ("investigations continue") the tools-lib/ jars in Jena
core are unused and should have been deleted years ago.
Again, thanks,
Andy
Re: Pre-release trial run.
Posted by Andy Seaborne <an...@apache.org>.
On 07/12/11 15:28, Ian Dickinson wrote:
> On 07/12/11 14:55, Andy Seaborne wrote:
>>> * README points at http://incubator.apache.org/jena/getting_started/
>>> which is
>>> empty
>>
>> @@ Hmm ... we ought to fix that.
> In progress. I have copy on my machine here, but not enough and not yet
> committed!
>
> Ian
>
Thanks. It's not critical path but it does look better if there is at
least some pointers on that page.
Realistically, it's a few days until the project vote (assuming I can
find some time to move bytes around) then 2 votes (we ought to serialize
them because this is the first time round the loop, having read
discussions on inubcator-general@).
Andy
Re: Pre-release trial run.
Posted by Ian Dickinson <ia...@epimorphics.com>.
On 07/12/11 14:55, Andy Seaborne wrote:
>> * README points at http://incubator.apache.org/jena/getting_started/
>> which is
>> empty
>
> @@ Hmm ... we ought to fix that.
In progress. I have copy on my machine here, but not enough and not yet
committed!
Ian
Re: Pre-release trial run.
Posted by Andy Seaborne <an...@apache.org>.
Anything marked @@ is a "to be done" item.
> ZOMG so many jars!
> ------------------
Yes :-|
In the maven repository:
# This is the useful bit!
jena-xyx-VER.jar
# Maven package things in jars, because, well, it does.
# javadoc (for IDE etc)
jena-xyx-VER-javadoc.jar
# sources (for IDE etc)
jena-xyx-VER-sources.jar
# We ship our testing framework
# mavenionics probably would make that a separate module :-(
jena-xyx-VER-tests.jar
jena-xyx-VER-test-source.jar
# Apache!
jena-xyx-VER-source-release.zip
then times
.md5, .sha1, .asc, .asc.md5, .asc.sha1
I heavily cut this down for the dist/ area to a much smaller set:
jena-xyz-VER-source-release.zip
jena-xyz-VER.jar
jena-xyz-VER-sources.jar
then times .asc, .md5, .sha1
> 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 ;-)
That makes two of us.
> 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.
For any module, usual maven: "mvn clean package"
There is a file BUILD in source-release for JenaZip
which is:
https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaZip/trunk/BUILD
I looked at other projects and didn't see instructions but there's no
harm in adding a BUILD that will automatically get swept into the
source-release. A build of a module assumes jena-top is published.
Building from JenaZip includes how to do it from scratch.
@@ Add BUILD to other modules.
>
> 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 jena-core-2.7.0-incubating-source-release.zip:
> * 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.
All covered by the software grant to Apache. I'll fix this. They are
licensed under ASF so "All rights reserved" is SF-hangover.
> 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
> http://www.java2html.de/
> which is licensed either GPL or CPL. Per
> http://www.apache.org/legal/resolved.html#category-b
> this file needs an "appropriate label".
Gone.
> * 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?
Gone.
>
> 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
Happy to do better - but what? Both are zip files.
The "source-release" classifier seems relatively - other projects use "-src"
apache-jena-VER-source-release.zip in a separate directory so that the
top level zip is the thing most people want to download.
It sees to me better (from a support POV) to put the thing we want users
to find most prominently. Is there better practice?
> * slightly surprised there's no .tar.gz for the sources, as an unixy end user
> I prefer those for irrational reasons
I'm fair certain you can't change what maven source plugin does. We
are, at least, the same as other projects.
> * you should probably explain (or point to explanation for) gpg verification
> in README at
> http://people.apache.org/~andy/proto-dist/
> see http://www.apache.org/dist/httpd/#sig as example
OK
@@ Add README to dist/
> * the most popular apache projects have a CHANGES or RELEASE_NOTES file in the
> dist area
> see examples at
> http://www.apache.org/dist/httpd/CHANGES_2.3.15
> http://www.apache.org/dist/ant/RELEASE-NOTES-apache-ant-1.8.2.html
> http://www.apache.org/dist/tomcat/tomcat-7/v7.0.23/RELEASE-NOTES
> http://www.apache.org/dist/lucene/java/3.5.0/changes-3.5.0/Changes.html
> 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)
I'm assuming apache-jena is the one people look at. The maven artifacts
are for machines. The ReleaseNotes for jena and ARQ are in apache-jena.
@@ Unbundle the release notes.
@@ make the directory dist/apache-jena-2.7.0/ so that the archive ends
up with one directory per released version.
> apache-jena-2.7.0-incubator.tar.gz
> * README has a word coppied which obviously should be copied
Done
> * README points at http://incubator.apache.org/jena/getting_started/ which is
> empty
@@ Hmm ... we ought to fix that.
> * 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.
2.6.5 == 2.7.0 :-)
Fixed.
> * Similarly, ReleaseNotes-ARQ.txt goes up to 2.8.9 but the release is 2.9.0.
Fixed
> apache-jena-2.7.0-incubating-source-release.zip
> * I don't like apache-jena-2.7.0-incubating-source-release.zip. 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.
Swapped to put the instructions for source-release, not SVN first.
Added links to the source-release in the dist/ to be.
All "source-release" are as built by the RAT so that one is just the module.
With BUILD, I tried to explain to build Jena from scratch, and not
explain how to just build apache-jena.
Options:
1/ Redo the build to hierarchical multi-module.
Good long term; significant delay to get stable.
I'd really like to get a release out now then make it better.
2/ Have a special "source-release"
3/ As-is.
4/ err ...
> * BUILD refers to a module jena-zip (to `mvn package`) that doesn't actually
> exist, this should point at itself
Fixed
> * `mvn package` produces a ton of warnings such as
Yes :-(
> [WARNING] Cannot include project artifact:
> org.apache.jena:apache-jena:pom:2.7.0-incubating;
> it doesn't have an associated file or directory.
I don't even know why that happens.
Seems harmless.
> [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
Warning about tar
Unfortunate. Harmless.
> which I assume are either "normal" or because I have an old maven. It does
> build 'something' in the end :-)
>
> jena-top-0-incubating-source-release.zip
> * what a weird version number :)
Got to start somewhere!
>
> jena-core-2.7.0-incubating-source-release.zip
> * 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?
Yes - old - gone.
> * `ant build.xml` fails for me with
> [javac] .../hpl/jena/util/Metadata.java:28: package org.slf4j
> does not exist
> [javac] import org.slf4j.Logger;
> [snip many more import errors]
> [javac] 100 errors
> [javac] 13 warnings
>
> BUILD FAILED
> ..../build.xml:165: Compile failed; see the compiler error output
> for details
> I would guess you just want to remove build.xml?
Gone
> * readme.html redirects to doc/readme.html which does not exist. It should
> probably just be removed?
Gone
> * `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]
<rant>
Maven is not DRY. The version numbers that connect the sub-projects
together are in the parent POM and, clearly, maven processes the parent
POM before worrying about <version>
If written literally into <version> we have to *duplicate* the version
string.
The release plugin exists, in part, because of this
</rant>
Either copy in the version string ("I surrender") or ignore the warnings.
When/if we have a hierarchical multimodule build with a single version,
this goes away.
> 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 :-)
Noted -
Anyone?
>
> jena-iri-0.9.0-incubating-source-release.zip
> * `ant build.xml` fails with
> BUILD FAILED
> ..../build.xml:32: Directory does not exist: ..../doc/javadoc
> I'd consider removing build.xml.
build.xml removed (all modules)
> * get same mvn [WARNING] as above, but it doesn't seem to matter
>
> jena-arq-2.9.0-incubating-source-release.zip
> * README.txt points at doc/ a few times but doc/ does not exist
@@ To be fixed.
> * get same mvn [WARNING] as above, but it doesn't seem to matter
Andy
Re: Pre-release trial run.
Posted by Leo Simons <ma...@leosimons.com>.
On Wed, Dec 7, 2011 at 11:19 AM, Andy Seaborne <an...@apache.org> wrote:
> I'm more than happy to try to get the details right - I'm not aiming to
> merely meet the minimum necessary requirements but to do the "right thing"
> now. We're learning.
Uhuh. I think that's true for just about every project out there --
you can bet your ass that 10 years ago, apache released a lot of
software that didn't follow all of these (most of these?) current
guidelines. I think as the FLOSS movement matures, we are learning how
to do this better and better. A few more years and someone will figure
out how to automate it properly :)
> I guess all of us use maven (or etc) dependency management
Well, hmm, so, I tend to have to use maven for work java projects, but
I will avoid it like the plague when I can [1]. I'm a minority like
that I guess (I also refuse to use eclipse, for example). I decided to
go from "knows lots about ant and maven" to "claims not to know
anything about maven" a while ago, it's much more comfortable that
way.
> but it's a real barrier for people starting out with
> Java, semantic web all at the same time, and not just students doing
> projects. Ditto people who use the command line tools.
Yeah I totally agree. Having something where you can go 1) download,
2) import some N3, 3) write sparql queries is pretty vital. When I got
started with RDF so many years ago I'm pretty sure having a nice phat
jena distro made me very happy.
cheerio......
- Leo
[1] my idea of a good build system is
https://github.com/lsimons/jhttp/blob/master/build.sh
Re: Pre-release trial run.
Posted by Andy Seaborne <an...@apache.org>.
On 07/12/11 08:33, Leo Simons wrote:
> On Wed, Dec 7, 2011 at 1:24 AM, Benson Margulies<bi...@gmail.com> wrote:
>> On Tue, Dec 6, 2011 at 7:03 PM, Leo Simons<ma...@leosimons.com> wrote:
>>> More legal stuff...on reproducing licenses and notices....
>>
>> Since The Official Release is the source, and the binary releases are
>> 'just for convenience', do we really need to apply all the same
>> fine-tooth-comb treatment?
>
> Of course! A lot of open source licensing is about "things you have to
> do when you (re)distribute".
>
> In a binary release with libraries inside, apache is (re)distributing
> those libraries, so those license terms kick in, and we simply have to
> follow them. And a lot of the obligation that comes with those
> licenses is about reproducing licenses and notices.
>
> The only alternative is not to redistribute those libraries, which
> puts the burden of figuring out the legal mess on the user (and so
> makes the binary "less convenient" for them!).
>
> Finally, do remember that _normally_ you would update the binary
> release LICENSE and NOTICE when you updated its build scripts to
> include another dependency, so this painful legal cleanup/scrubbing
> should really be a once-only event.
I'm more than happy to try to get the details right - I'm not aiming to
merely meet the minimum necessary requirements but to do the "right
thing" now. We're learning.
Jena has historically shipped with dependencies, originally (10 years
ago) because that was the only practical way to get the stuff to the
users. The simple act of putting the right versions of the software
into the users hands was been quite important. Getting the classpath set
correctly is another matter ...
Nowadays, because public maven, or even maven, isn't for everyone, it's
still useful to deliver the bundle. I guess all of us use maven (or
etc) dependency management but it's a real barrier for people starting
out with Java, semantic web all at the same time, and not just students
doing projects. Ditto people who use the command line tools.
So I appreciate the fine tooth combing. At the moment I'm on the
receiving end of formal public comments on specs as SPARQL goes through
the later stages of W3C process, and the comments there are not
necessarily as supportive as here.
Andy
Re: Pre-release trial run.
Posted by Leo Simons <ma...@leosimons.com>.
On Wed, Dec 7, 2011 at 1:24 AM, Benson Margulies <bi...@gmail.com> wrote:
> On Tue, Dec 6, 2011 at 7:03 PM, Leo Simons <ma...@leosimons.com> wrote:
>> More legal stuff...on reproducing licenses and notices....
>
> Since The Official Release is the source, and the binary releases are
> 'just for convenience', do we really need to apply all the same
> fine-tooth-comb treatment?
Of course! A lot of open source licensing is about "things you have to
do when you (re)distribute".
In a binary release with libraries inside, apache is (re)distributing
those libraries, so those license terms kick in, and we simply have to
follow them. And a lot of the obligation that comes with those
licenses is about reproducing licenses and notices.
The only alternative is not to redistribute those libraries, which
puts the burden of figuring out the legal mess on the user (and so
makes the binary "less convenient" for them!).
Finally, do remember that _normally_ you would update the binary
release LICENSE and NOTICE when you updated its build scripts to
include another dependency, so this painful legal cleanup/scrubbing
should really be a once-only event.
cheers,
Leo
Re: Pre-release trial run.
Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Dec 6, 2011 at 7:03 PM, Leo Simons <ma...@leosimons.com> wrote:
> More legal stuff...on reproducing licenses and notices....
Leo,
Since The Official Release is the source, and the binary releases are
'just for convenience', do we really need to apply all the same
fine-tooth-comb treatment?
>
> cheers,
>
> Leo
>
> On Tue, Dec 6, 2011 at 12:18 AM, Leo Simons <ma...@leosimons.com> wrote:
>> ZOMG so many jars!
>> ------------------
> ...
>> apache-jena-2.7.0-incubator.tar.gz
> ...
>
> I wonder how I forgot to look at this yesterday. Like I went over for
> the LARQ example, for all the third party stuff (code and/or jars)
> that are included in a distribution, their license and notice data
> needs to be carried forward. For example, BSD/MIT/etc LICENSES for
> included jars have to go into an aggregated LICENSE file, and
> statements in NOTICE files for ALv2 jars need to go into the
> distribution NOTICE.
>
> Concretely, for this binary tarball,
> * commons-codec NOTICE says
> src/test/org/apache/commons/codec/language/DoubleMetaphoneTest.java
> contains
> test data from http://aspell.sourceforge.net/test/batch0.tab.
>
> Copyright (C) 2002 Kevin Atkinson (kevina@gnu.org). Verbatim copying
> and distribution of this entire article is permitted in any medium,
> provided this notice is preserved.
> ...since the jar doesn't contain that test source that seems ok and
> we do not carry
> the NOTICE forward.
> * httpclient says
> This project contains annotations derived from JCIP-ANNOTATIONS
> Copyright (c) 2005 Brian Goetz and Tim Peierls. See http://www.jcip.net
> ...so that statement needs to go in NOTICE.
> * icu4j seems BSD-licensed so its license should go into LICENSE
> * slf4j seems MIT-licensed so its license should go into LICENSE
> * wstx-asl contains a weird NOTICE file. I don't think anything in there
> needs to be carried forward since these don't look like legal
> statements. But, it
> is most likely simpler and safer just to copy the text it supplies verbatim.
> * depending on where the xercesImpl binary came from, the relevant NOTICE data
> needs to be carried forward, which probably is
> http://svn.apache.org/repos/asf/xerces/java/trunk/NOTICE
> Portions of this software were originally based on the following:
> - software copyright (c) 1999, IBM Corporation., http://www.ibm.com.
> - software copyright (c) 1999, Sun Microsystems., http://www.sun.com.
> - voluntary contributions made by Paul Eng on behalf of the
> Apache Software Foundation that were originally developed at
> iClick, Inc.,
> software copyright (c) 1999.
> ...but you'll need to check the distro that you got the jar file from.
>
> I'm trying to remember how I handled this kind of thing before. Looks
> like the last time I actually release managed an apache release was in
> 2007, and what we did then was simply not to ship 3rd party jars at
> all (not the most user friendly). I guess it's easy enough to just
> author the distribution NOTICE and LICENSE by hand, since these
> dependencies don't change all that frequently, and that seems to be
> what is (still) common practice.
>
> Like I said, I did not check the other binary releases, but they need
> to be checked for this too.
Re: Pre-release trial run.
Posted by Andy Seaborne <an...@apache.org>.
On 07/12/11 00:03, Leo Simons wrote:
...
Re: XercesImpl
> ...but you'll need to check the distro that you got the jar file from.
As a general point, all the dependences come from maven central. But
there's no LICENSE/NOTICE etc. through that route (including looking in
the META-INF of the jar). I'm going to go back to the original download
site and work from that.
For Xerces there are several LICENSE.* and NOTICE.* files. I'm tempted
to create a directory specially.
Andy
Re: Pre-release trial run.
Posted by Andy Seaborne <an...@apache.org>.
Oh beep. We really should have been doing this in the pre-Apache releases.
I'll do that for the various modules (that means in practice Jena and
ARQ, then roll through to apache-jena).
Thanks
Andy
On 07/12/11 00:03, Leo Simons wrote:
> More legal stuff...on reproducing licenses and notices....
>
> cheers,
>
> Leo
>
> On Tue, Dec 6, 2011 at 12:18 AM, Leo Simons<ma...@leosimons.com> wrote:
>> ZOMG so many jars!
>> ------------------
> ...
>> apache-jena-2.7.0-incubator.tar.gz
> ...
>
> I wonder how I forgot to look at this yesterday. Like I went over for
> the LARQ example, for all the third party stuff (code and/or jars)
> that are included in a distribution, their license and notice data
> needs to be carried forward. For example, BSD/MIT/etc LICENSES for
> included jars have to go into an aggregated LICENSE file, and
> statements in NOTICE files for ALv2 jars need to go into the
> distribution NOTICE.
>
> Concretely, for this binary tarball,
> * commons-codec NOTICE says
> src/test/org/apache/commons/codec/language/DoubleMetaphoneTest.java
> contains
> test data from http://aspell.sourceforge.net/test/batch0.tab.
>
> Copyright (C) 2002 Kevin Atkinson (kevina@gnu.org). Verbatim copying
> and distribution of this entire article is permitted in any medium,
> provided this notice is preserved.
> ...since the jar doesn't contain that test source that seems ok and
> we do not carry
> the NOTICE forward.
> * httpclient says
> This project contains annotations derived from JCIP-ANNOTATIONS
> Copyright (c) 2005 Brian Goetz and Tim Peierls. See http://www.jcip.net
> ...so that statement needs to go in NOTICE.
> * icu4j seems BSD-licensed so its license should go into LICENSE
> * slf4j seems MIT-licensed so its license should go into LICENSE
> * wstx-asl contains a weird NOTICE file. I don't think anything in there
> needs to be carried forward since these don't look like legal
> statements. But, it
> is most likely simpler and safer just to copy the text it supplies verbatim.
> * depending on where the xercesImpl binary came from, the relevant NOTICE data
> needs to be carried forward, which probably is
> http://svn.apache.org/repos/asf/xerces/java/trunk/NOTICE
> Portions of this software were originally based on the following:
> - software copyright (c) 1999, IBM Corporation., http://www.ibm.com.
> - software copyright (c) 1999, Sun Microsystems., http://www.sun.com.
> - voluntary contributions made by Paul Eng on behalf of the
> Apache Software Foundation that were originally developed at
> iClick, Inc.,
> software copyright (c) 1999.
> ...but you'll need to check the distro that you got the jar file from.
>
> I'm trying to remember how I handled this kind of thing before. Looks
> like the last time I actually release managed an apache release was in
> 2007, and what we did then was simply not to ship 3rd party jars at
> all (not the most user friendly). I guess it's easy enough to just
> author the distribution NOTICE and LICENSE by hand, since these
> dependencies don't change all that frequently, and that seems to be
> what is (still) common practice.
>
> Like I said, I did not check the other binary releases, but they need
> to be checked for this too.
Re: Pre-release trial run.
Posted by Leo Simons <ma...@leosimons.com>.
More legal stuff...on reproducing licenses and notices....
cheers,
Leo
On Tue, Dec 6, 2011 at 12:18 AM, Leo Simons <ma...@leosimons.com> wrote:
> ZOMG so many jars!
> ------------------
...
> apache-jena-2.7.0-incubator.tar.gz
...
I wonder how I forgot to look at this yesterday. Like I went over for
the LARQ example, for all the third party stuff (code and/or jars)
that are included in a distribution, their license and notice data
needs to be carried forward. For example, BSD/MIT/etc LICENSES for
included jars have to go into an aggregated LICENSE file, and
statements in NOTICE files for ALv2 jars need to go into the
distribution NOTICE.
Concretely, for this binary tarball,
* commons-codec NOTICE says
src/test/org/apache/commons/codec/language/DoubleMetaphoneTest.java
contains
test data from http://aspell.sourceforge.net/test/batch0.tab.
Copyright (C) 2002 Kevin Atkinson (kevina@gnu.org). Verbatim copying
and distribution of this entire article is permitted in any medium,
provided this notice is preserved.
...since the jar doesn't contain that test source that seems ok and
we do not carry
the NOTICE forward.
* httpclient says
This project contains annotations derived from JCIP-ANNOTATIONS
Copyright (c) 2005 Brian Goetz and Tim Peierls. See http://www.jcip.net
...so that statement needs to go in NOTICE.
* icu4j seems BSD-licensed so its license should go into LICENSE
* slf4j seems MIT-licensed so its license should go into LICENSE
* wstx-asl contains a weird NOTICE file. I don't think anything in there
needs to be carried forward since these don't look like legal
statements. But, it
is most likely simpler and safer just to copy the text it supplies verbatim.
* depending on where the xercesImpl binary came from, the relevant NOTICE data
needs to be carried forward, which probably is
http://svn.apache.org/repos/asf/xerces/java/trunk/NOTICE
Portions of this software were originally based on the following:
- software copyright (c) 1999, IBM Corporation., http://www.ibm.com.
- software copyright (c) 1999, Sun Microsystems., http://www.sun.com.
- voluntary contributions made by Paul Eng on behalf of the
Apache Software Foundation that were originally developed at
iClick, Inc.,
software copyright (c) 1999.
...but you'll need to check the distro that you got the jar file from.
I'm trying to remember how I handled this kind of thing before. Looks
like the last time I actually release managed an apache release was in
2007, and what we did then was simply not to ship 3rd party jars at
all (not the most user friendly). I guess it's easy enough to just
author the distribution NOTICE and LICENSE by hand, since these
dependencies don't change all that frequently, and that seems to be
what is (still) common practice.
Like I said, I did not check the other binary releases, but they need
to be checked for this too.
Re: Pre-release trial run.
Posted by Andy Seaborne <an...@apache.org>.
On 06/12/11 12:50, Laurent Pellegrino wrote:
>> Which "rsparql" script are you running?
>
> I am running the command from
> http://people.apache.org/~andy/jena-R1-repo/org/apache/jena/apache-jena/2.7.0-incubating/apache-jena-2.7.0-incubating.zip
> once it is unzipped and after having set JENAROOT.
>
> All other commands run with the exception of this one.
>
>> The one in the JenaZip/ project will not run in the project - it only works
>> in the unpacked zip when all the dependences get placed in lib/.
>>
>> Andy
Laurent,
Thanks problem found and corrected (it's the one command where the java
class wasn't the same name as the command - java class renamed).
Andy
Re: Pre-release trial run.
Posted by Laurent Pellegrino <la...@gmail.com>.
> Which "rsparql" script are you running?
I am running the command from
http://people.apache.org/~andy/jena-R1-repo/org/apache/jena/apache-jena/2.7.0-incubating/apache-jena-2.7.0-incubating.zip
once it is unzipped and after having set JENAROOT.
All other commands run with the exception of this one.
> The one in the JenaZip/ project will not run in the project - it only works
> in the unpacked zip when all the dependences get placed in lib/.
>
> Andy
Re: Pre-release trial run.
Posted by Andy Seaborne <an...@apache.org>.
On 06/12/11 07:43, Laurent Pellegrino wrote:
> Hi all,
>
> It seems that rsparql script on UNIX systems is not working. I don't
> know if the class is missing or if the classpath is wrong but I get:
>
> Exception in thread "main" java.lang.NoClassDefFoundError: arq/rsparql
> Caused by: java.lang.ClassNotFoundException: arq.rsparql
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>
> Kind Regards,
>
> Laurent
Laurent,
Which "rsparql" script are you running?
The one in the JenaZip/ project will not run in the project - it only
works in the unpacked zip when all the dependences get placed in lib/.
Andy
Re: Pre-release trial run.
Posted by Laurent Pellegrino <la...@gmail.com>.
Hi all,
It seems that rsparql script on UNIX systems is not working. I don't
know if the class is missing or if the classpath is wrong but I get:
Exception in thread "main" java.lang.NoClassDefFoundError: arq/rsparql
Caused by: java.lang.ClassNotFoundException: arq.rsparql
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Kind Regards,
Laurent
On Tue, Dec 6, 2011 at 12:18 AM, Leo Simons <ma...@leosimons.com> wrote:
> Hey Andy, all,
>
> On Sun, Dec 4, 2011 at 5:17 PM, Andy Seaborne <an...@apache.org> 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 jena-core-2.7.0-incubating-source-release.zip:
> * 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
> http://www.java2html.de/
> which is licensed either GPL or CPL. Per
> http://www.apache.org/legal/resolved.html#category-b
> 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
> http://people.apache.org/~andy/proto-dist/
> see http://www.apache.org/dist/httpd/#sig as example
> * the most popular apache projects have a CHANGES or RELEASE_NOTES file in the
> dist area
> see examples at
> http://www.apache.org/dist/httpd/CHANGES_2.3.15
> http://www.apache.org/dist/ant/RELEASE-NOTES-apache-ant-1.8.2.html
> http://www.apache.org/dist/tomcat/tomcat-7/v7.0.23/RELEASE-NOTES
> http://www.apache.org/dist/lucene/java/3.5.0/changes-3.5.0/Changes.html
> 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 http://incubator.apache.org/jena/getting_started/ 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.
>
> apache-jena-2.7.0-incubating-source-release.zip
> * I don't like apache-jena-2.7.0-incubating-source-release.zip. 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 :-)
>
> jena-top-0-incubating-source-release.zip
> * what a weird version number :)
>
> jena-core-2.7.0-incubating-source-release.zip
> * 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/Metadata.java:28: package org.slf4j
> does not exist
> [javac] import org.slf4j.Logger;
> [snip many more import errors]
> [javac] 100 errors
> [javac] 13 warnings
>
> BUILD FAILED
> ..../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 :-)
>
> jena-iri-0.9.0-incubating-source-release.zip
> * `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
>
> jena-arq-2.9.0-incubating-source-release.zip
> * 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
Re: Pre-release trial run.
Posted by Leo Simons <ma...@leosimons.com>.
Hey Andy, all,
On Sun, Dec 4, 2011 at 5:17 PM, Andy Seaborne <an...@apache.org> 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 jena-core-2.7.0-incubating-source-release.zip:
* 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
http://www.java2html.de/
which is licensed either GPL or CPL. Per
http://www.apache.org/legal/resolved.html#category-b
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
http://people.apache.org/~andy/proto-dist/
see http://www.apache.org/dist/httpd/#sig as example
* the most popular apache projects have a CHANGES or RELEASE_NOTES file in the
dist area
see examples at
http://www.apache.org/dist/httpd/CHANGES_2.3.15
http://www.apache.org/dist/ant/RELEASE-NOTES-apache-ant-1.8.2.html
http://www.apache.org/dist/tomcat/tomcat-7/v7.0.23/RELEASE-NOTES
http://www.apache.org/dist/lucene/java/3.5.0/changes-3.5.0/Changes.html
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 http://incubator.apache.org/jena/getting_started/ 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.
apache-jena-2.7.0-incubating-source-release.zip
* I don't like apache-jena-2.7.0-incubating-source-release.zip. 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 :-)
jena-top-0-incubating-source-release.zip
* what a weird version number :)
jena-core-2.7.0-incubating-source-release.zip
* 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/Metadata.java:28: package org.slf4j
does not exist
[javac] import org.slf4j.Logger;
[snip many more import errors]
[javac] 100 errors
[javac] 13 warnings
BUILD FAILED
..../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 :-)
jena-iri-0.9.0-incubating-source-release.zip
* `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
jena-arq-2.9.0-incubating-source-release.zip
* 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
Re: Pre-release trial run.
Posted by Andy Seaborne <an...@apache.org>.
On 04/12/11 20:05, Benson Margulies wrote:
> My track record as a human lint is awful. I suggest that you
> specifically invite sebb to have a look. He seems to have the most
> careful checker.
Good suggestion. The right time to ask is probably in parallel with the
project vote. I think we should to do a first round of checking
ourselves to eliminate obvious mistakes. sebb time is a limited resource.
Andy
Re: Pre-release trial run.
Posted by Benson Margulies <bi...@gmail.com>.
My track record as a human lint is awful. I suggest that you
specifically invite sebb to have a look. He seems to have the most
careful checker.
On Sun, Dec 4, 2011 at 12:17 PM, Andy Seaborne <an...@apache.org> wrote:
> Everything ready (ish).
>
> Mentors - any time to help check all the necessary Apache process has been
> covered would be appreciated.
>
>
> Proposed maven repository:
> http://people.apache.org/~andy/jena-R1-repo/
>
> Proposed dist/ area:
> http://people.apache.org/~andy/proto-dist/
>
> Jena 2.7.0 download is:
>
> http://people.apache.org/~andy/jena-R1-repo/org/apache/jena/apache-jena/2.7.0-incubating/apache-jena-2.7.0-incubating.zip
>
> (.tar.gz and .tar.bz2 versions also available)
>
> Testing needed:
>
> * Use the repository as a maven repository and check it works.
>
> * Check modules:
> jena-iri
> jena-core
> jena-arq
>
> * Any other checking you think needs doing.
>
> Please try these out and report.
>
>
> I've already rebuilt Jena 2.7.0 from the source-release artifacts and also
> downloaded the zip and checked the bat scripts work. The current prototype
> repo and dist area are, however, composites, not clean builds, because the
> upload of all the bytes for the last few changes to only apache-jena would
> make the cycle time really long.
>
>
> Process from here:
>
> 1/ Checking (see above) / iterate
> 2/ Do the staging build into the Apache nexus staging repository
> 3/ Build the final dist/ area and put on people.apache.org
> 4/ Call the project vote (3 days)
> 5/ If that passes, call the IPMC vote (3+ days)
> 6/ Iterate on feedback.
>
> For the project vote, it's required to be at least a majority vote of the
> PPMC, with mentors, but I think we should be looking for consensus amongst
> the project committers and mentors.
>
> Andy
>
Re: Pre-release trial run.
Posted by Andy Seaborne <an...@apache.org>.
Everything ready (ish).
Mentors - any time to help check all the necessary Apache process has
been covered would be appreciated.
Proposed maven repository:
http://people.apache.org/~andy/jena-R1-repo/
Proposed dist/ area:
http://people.apache.org/~andy/proto-dist/
Jena 2.7.0 download is:
http://people.apache.org/~andy/jena-R1-repo/org/apache/jena/apache-jena/2.7.0-incubating/apache-jena-2.7.0-incubating.zip
(.tar.gz and .tar.bz2 versions also available)
Testing needed:
* Use the repository as a maven repository and check it works.
* Check modules:
jena-iri
jena-core
jena-arq
* Any other checking you think needs doing.
Please try these out and report.
I've already rebuilt Jena 2.7.0 from the source-release artifacts and
also downloaded the zip and checked the bat scripts work. The current
prototype repo and dist area are, however, composites, not clean builds,
because the upload of all the bytes for the last few changes to only
apache-jena would make the cycle time really long.
Process from here:
1/ Checking (see above) / iterate
2/ Do the staging build into the Apache nexus staging repository
3/ Build the final dist/ area and put on people.apache.org
4/ Call the project vote (3 days)
5/ If that passes, call the IPMC vote (3+ days)
6/ Iterate on feedback.
For the project vote, it's required to be at least a majority vote of
the PPMC, with mentors, but I think we should be looking for consensus
amongst the project committers and mentors.
Andy
Re: LARQ depends on TDB:test
Posted by Andy Seaborne <an...@apache.org>.
On 03/12/11 19:44, Paolo Castagna wrote:
> Hi Andy,
> ... right, LARQ uses TDB (scope test) for testing the dataset assembler.
> That dependency could be removed, but I think it's ok to wait and release
> LARQ when TDB is ready.
OK - from earlier, I thought you wanted LARQ in this release.
Andy
Re: LARQ depends on TDB:test
Posted by Paolo Castagna <ca...@googlemail.com>.
Hi Andy,
... right, LARQ uses TDB (scope test) for testing the dataset assembler.
That dependency could be removed, but I think it's ok to wait and release
LARQ when TDB is ready.
I still don't see the root cause of JENA-163. :-/ Do you?
I see the effects, but I don't understand why.
Thanks,
Paolo
Andy Seaborne wrote:
> Paolo,
>
> LARQ depends on TDB (scope test) but TDB isn't ready for this release
> sweep.
>
> What does the release manager do about this?
>
> (Hopefully, TDB is not far behind. Getting the main Jena release out of
> the way will free up some my time to progress TDB.)
>
> Andy
LARQ depends on TDB:test
Posted by Andy Seaborne <an...@apache.org>.
Paolo,
LARQ depends on TDB (scope test) but TDB isn't ready for this release sweep.
What does the release manager do about this?
(Hopefully, TDB is not far behind. Getting the main Jena release out of
the way will free up some my time to progress TDB.)
Andy
Re: Pre-release trial run.
Posted by Andy Seaborne <an...@apache.org>.
On 02/12/11 12:45, Ian Dickinson wrote:
> Hi Andy,
> On 02/12/11 10:33, Andy Seaborne wrote:
>> On 01/12/11 13:11, Andy Seaborne wrote:
>>> Prototype layout for the incubator/dist/jena area:
>>>
>>> This ends up are:
>>>
>>> http://www.apache.org/dist/incubator/jena/
>>>
>>> and is mirrored and archived.
>>>
>>> The layout is one subdirectory per module, with the zip download at the
>>> top level.
>>>
>>> The observant will notice that is it is not quite all the files - it
>>> does not contain the .asc.md5 and .asc.sha1 files, nor jena-top
>>>
>>> Other projects don't dist these. It's an attempt to make things a bit
>>> more findable.
>>>
>>> It's assembled (by script) based in the installed artifacts, in this
>>> case the trial run repo.
>
> Looks pretty good to me. Some minor observations:
Thanks for checking.
>
> * the format for apache-jena-2.7.0-incubating.tar.gz.md5 doesn't allow
> quick checking with md5sum --check. I had to change it to:
>
> 7f2dd10c0fc5bf9cfe33c9373847aa36 *apache-jena-2.7.0-incubating.tar.gz
>
> Ditto the sha1 file and sha1sum --check
Hmm - that's the file as produced by maven and the same format is used
by other projects. Is there any control over the format (rhetorical Q)?
And non-maven ones:
http://www.apache.org/dist/ant/binaries/apache-ant-1.8.2-bin.tar.bz2.md5
Don't how what to do about that except explain it in the README ...
>
> * Some unexpected files are executable:
>
> $> find . -type f -perm /ugo+x | grep -v "bin\|bat"
> ./ReleaseNotes-ARQ.txt
> ./lib/httpcore-4.1.2.jar
> ./lib/commons-codec-1.5.jar
> ./lib/slf4j-log4j12-1.6.1.jar
> ./lib/wstx-asl-3.2.9.jar
> ./lib/stax-api-1.0.1.jar
> ./lib/log4j-1.2.16.jar
> ./lib/xercesImpl-2.7.1.jar
> ./lib/slf4j-api-1.6.1.jar
> ./lib/httpclient-4.1.2.jar
> ./lib/icu4j-3.4.4.jar
> ./log4j.properties
> ./ReleaseNotes-Jena.txt
No idea why that happened. They aren't executable going into the
process. Guess - because the previous assembly action was to set the
filemode and it's not reset afterwards.
I'll explicitly set fileMode for all of them and hope.
> * The command line utils (well, the few that I tried) worked OK once I'd
> set JENAROOT to point to the install directory. Possibly something to
> mention in a readme.txt?
Because I forgot the README! Assembly error. Paolo has written a nice
one which should have been included:
https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaZip/trunk/README
The notes at the top need clearing.
Add stuff about verifying.
Andy
>
> Good job!
>
> Ian
Re: Pre-release trial run.
Posted by Ian Dickinson <ia...@epimorphics.com>.
Hi Andy,
On 02/12/11 10:33, Andy Seaborne wrote:
> On 01/12/11 13:11, Andy Seaborne wrote:
>> Prototype layout for the incubator/dist/jena area:
>>
>> This ends up are:
>>
>> http://www.apache.org/dist/incubator/jena/
>>
>> and is mirrored and archived.
>>
>> The layout is one subdirectory per module, with the zip download at the
>> top level.
>>
>> The observant will notice that is it is not quite all the files - it
>> does not contain the .asc.md5 and .asc.sha1 files, nor jena-top
>>
>> Other projects don't dist these. It's an attempt to make things a bit
>> more findable.
>>
>> It's assembled (by script) based in the installed artifacts, in this
>> case the trial run repo.
Looks pretty good to me. Some minor observations:
* the format for apache-jena-2.7.0-incubating.tar.gz.md5 doesn't allow
quick checking with md5sum --check. I had to change it to:
7f2dd10c0fc5bf9cfe33c9373847aa36 *apache-jena-2.7.0-incubating.tar.gz
Ditto the sha1 file and sha1sum --check
* Some unexpected files are executable:
$> find . -type f -perm /ugo+x | grep -v "bin\|bat"
./ReleaseNotes-ARQ.txt
./lib/httpcore-4.1.2.jar
./lib/commons-codec-1.5.jar
./lib/slf4j-log4j12-1.6.1.jar
./lib/wstx-asl-3.2.9.jar
./lib/stax-api-1.0.1.jar
./lib/log4j-1.2.16.jar
./lib/xercesImpl-2.7.1.jar
./lib/slf4j-api-1.6.1.jar
./lib/httpclient-4.1.2.jar
./lib/icu4j-3.4.4.jar
./log4j.properties
./ReleaseNotes-Jena.txt
* The command line utils (well, the few that I tried) worked OK once I'd
set JENAROOT to point to the install directory. Possibly something to
mention in a readme.txt?
Good job!
Ian
Re: Pre-release trial run.
Posted by Andy Seaborne <an...@apache.org>.
On 01/12/11 13:11, Andy Seaborne wrote:
> Prototype layout for the incubator/dist/jena area:
>
> This ends up are:
>
> http://www.apache.org/dist/incubator/jena/
>
> and is mirrored and archived.
>
> The layout is one subdirectory per module, with the zip download at the
> top level.
>
> The observant will notice that is it is not quite all the files - it
> does not contain the .asc.md5 and .asc.sha1 files, nor jena-top
>
> Other projects don't dist these. It's an attempt to make things a bit
> more findable.
>
> It's assembled (by script) based in the installed artifacts, in this
> case the trial run repo.
>
> Andy
Hmm - No URL:
http://people.apache.org/~andy/proto-dist/
Andy