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
