incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Re: Pre-release trial run.
Date Wed, 07 Dec 2011 14:55:23 GMT
Anything marked @@ is a "to be done" item.

> ZOMG so many jars!
> ------------------

Yes :-|

In the maven repository:

# This is the useful bit!
# Maven package things in jars, because, well, it does.
# javadoc (for IDE etc)
# sources (for IDE etc)

# We ship our testing framework
# mavenionics probably would make that a separate module :-(

# Apache!

then times
.md5, .sha1, .asc, .asc.md5, .asc.sha1

I heavily cut this down for the dist/ area to a much smaller set:

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:

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
> * 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
>    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

Happy to do better - but what?  Both are zip files.

The "source-release" classifier seems relatively - other projects use "-src" 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
>    see as example


@@ Add README to dist/

> * 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)

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


> * README points at 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 :-)


> * 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.

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.

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


> * `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 :-)
> * what a weird version number :)

Got to start somewhere!

> * 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/ 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]

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 

The release plugin exists, in part, because of this

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 -


> * `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
> * 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


View raw message