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/14 18:45:37 UTC
[VOTE] Release Jena 2.7.0
Hi,
Here vote on a release build for Jena 2.7.0
Versions:
jena-top 0-incubating
jena-iri 0.9.0-incubating
jena-code 2.7.0-incubating
jena-arq 2.9.0-incubating
jena-zip 2.7.0-incubating
Staging repository:
https://repository.apache.org/content/repositories/orgapachejena-331/
Proposed dist/ area:
http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/
Keys:
https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS
SVN tags:
Each module is tagged with the version and "RC-1" to denote the first
release candidate for this release cycle. It voted on successfully, the
tag will be changed ("svn mv") to the same but minus the RC-1.
https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaTop/tags/jena-top-0-incubating-RC-1/
https://svn.apache.org/repos/asf/incubator/jena/Jena2/IRI/tags/jena-iri-0.9.0-incubating-RC-1/
https://svn.apache.org/repos/asf/incubator/jena/Jena2/jena/tags/jena-core-2.7.0-incubating-RC-1/
https://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/tags/jena-arq-2.9.0-incubating-RC-1/
https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaZip/tags/apache-jena-2.7.0-incubating-RC-1/
Please vote to approve this release:
[ ] +1 Approve the release
[ ] 0 Don't care
[ ] -1 Don't release, because ...
This vote will be open to the end of
Saturday 17/December 23:59 UTC
(72 hours from the same hour tonight).
Andy
Re: [VOTE] Release Jena 2.7.0
Posted by Ian Dickinson <ia...@epimorphics.com>.
On 14/12/11 17:45, Andy Seaborne wrote:
> [ ] +1 Approve the release
> [ ] 0 Don't care
> [ ] -1 Don't release, because ...
+1 Great job!
Ian
RE: [VOTE] [RESULT] Release Jena 2.7.0
Posted by Martin Merry <ma...@epimorphics.com>.
Epimorphics Ltd www.epimorphics.com
Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Epimorphics Ltd. is a limited company registered in England (number 7016688)
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT, UK
> -----Original Message-----
> From: Andy Seaborne [mailto:andy.seaborne.apache@gmail.com] On Behalf
> Of Andy Seaborne
> Sent: 18 December 2011 1:09 PM
> To: jena-dev@incubator.apache.org
> Subject: [VOTE] [RESULT] Release Jena 2.7.0
>
> Result of the vote for release of Jena 2.7.0
> (vote started 2011-12-14)
>
> The vote passes:
>
> +1 votes: 8
>
> Mentors:
> Leo Simons
> Benson Margulies
>
> PPMC:
> Stephen Allen
> Dave Reynolds
> Damian Steer
> Ian Dickinson
> Paolo Castagna
> Andy Seaborne
>
> 0 votes: none
>
> -1 votes: none
>
> Call for the VOTE was:
>
> Apache archives:
> http://mail-archives.apache.org/mod_mbox/incubator-jena-
> dev/201112.mbox/%3C4EE8E0C1.7030608%40apache.org%3E
>
> Markmail:
> http://markmail.org/message/e7eozu2ji7gtmsgd
>
> Andy
[VOTE] [RESULT] Release Jena 2.7.0
Posted by Andy Seaborne <an...@apache.org>.
Result of the vote for release of Jena 2.7.0
(vote started 2011-12-14)
The vote passes:
+1 votes: 8
Mentors:
Leo Simons
Benson Margulies
PPMC:
Stephen Allen
Dave Reynolds
Damian Steer
Ian Dickinson
Paolo Castagna
Andy Seaborne
0 votes: none
-1 votes: none
Call for the VOTE was:
Apache archives:
http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201112.mbox/%3C4EE8E0C1.7030608%40apache.org%3E
Markmail:
http://markmail.org/message/e7eozu2ji7gtmsgd
Andy
Re: [] Release Jena 2.7.0
Posted by Andy Seaborne <an...@apache.org>.
On 16/12/11 17:03, Dave Reynolds wrote:
> On Wed, 2011-12-14 at 17:45 +0000, Andy Seaborne wrote:
>> Hi,
>>
>> Here vote on a release build for Jena 2.7.0
>>
>> Versions:
>>
>> jena-top 0-incubating
>> jena-iri 0.9.0-incubating
>> jena-code 2.7.0-incubating
>> jena-arq 2.9.0-incubating
>> jena-zip 2.7.0-incubating
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachejena-331/
>>
>> Proposed dist/ area:
>> http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/
>>
>> Keys:
>> https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS
>
> +1
>
> Fantastic job Andy!!
>
> Checked basic signatures, hashes, BUILD/LICENSE/NOTICE files, maven
> install from sources and test of random jena code using the results of
> maven install. All fine as far as I can see
>
> Trivial nits that don't affect release:
>
Bother.
If anything is changed, then the release will have to be restaged.
(we need to find away to do release candidates - something that is
almost but not quite a release, but which is "frozen" in someway).
If any bytes are changed, then it's not the same vote so we'd go round
again.
My expectation is that incubator-general@ will turn up something and
we'll have top go round the loop again.
As you have said the corrections don't affect the release, I'll continue
with the bytes that currently exist.
Andy
> # Release message:
>
> s/jena-code/jena-core/
>
> Possible also s/jena-zip/apache-jena/ to match the artefact name.
>
> # BUILD files for all projects
>
> These reference in various places to:
> jena-zzz-VER-incubator*
> whereas the candidate release artefacts are all called:
> jena-zzz-VER-incubating*
>
> # jena-core README.txt
>
> Refers to doc/readme.html which does not exist any more.
>
> # jena-core ReleaseNotes.txt
>
> Top entry is for "Jena 2.6.5" shouldn't that be 2.7.0?
> (It's right in apache-jena/ReleaseNotes-Jena.txt).
>
> # jena-arq pom.xml
>
> The maven-resources-plugin is declared twice which causes Maven (3.0.3)
> to complain:
>
> """
> Some problems were encountered while building the effective model for
> org.apache.jena:jena-arq:jar:2.9.0-incubating
> [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but
> found duplicate declaration of plugin
> org.apache.maven.plugins:maven-resources-plugin @ line 200, column 15
> [WARNING]
> """
>
> # jena-arq README.txt
>
> For setting up the command line arguments the README talks about setting
> JENAROOT. If I try that the scripts complain that they were expecting
> ARQROOT.
>
> Might be worth explicitly mentioning in here that when working from an
> ARQ source release and wanting to set up command line use then you also
> need to do:
> mvn -DoutputDirectory=lib dependency:copy-dependencies
>
> # apache-jena-sources DEPENDENCIES
>
> Looks odd in having several duplicate entries (three references to each
> of jena-core and jena-arq for example) and having xerces as being from
> an unknown organization.
>
> # apache-jena-sources BUILD
>
> s/alternativbely, yo/alternatively, you/
>
>
> Dave
>
>
>
Re: [] Release Jena 2.7.0
Posted by Andy Seaborne <an...@apache.org>.
On 16/12/11 17:03, Dave Reynolds wrote:
...
> Trivial nits that don't affect release:
Thanks for checking - I was more word-blind than usual.
>
> # Release message:
>
> s/jena-code/jena-core/
>
> Possible also s/jena-zip/apache-jena/ to match the artefact name.
I'll fix this in the incubator-general@ message
> # BUILD files for all projects
>
> These reference in various places to:
> jena-zzz-VER-incubator*
> whereas the candidate release artefacts are all called:
> jena-zzz-VER-incubating*
Fixed in SVN
>
> # jena-core README.txt
>
> Refers to doc/readme.html which does not exist any more.
Removed in SVN.
> # jena-core ReleaseNotes.txt
>
> Top entry is for "Jena 2.6.5" shouldn't that be 2.7.0?
> (It's right in apache-jena/ReleaseNotes-Jena.txt).
Relief - it's right in the copy we ship!
Numbering restarted in the in-project versions.
> # jena-arq pom.xml
>
> The maven-resources-plugin is declared twice which causes Maven (3.0.3)
> to complain:
>
> """
> Some problems were encountered while building the effective model for
> org.apache.jena:jena-arq:jar:2.9.0-incubating
> [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but
> found duplicate declaration of plugin
> org.apache.maven.plugins:maven-resources-plugin @ line 200, column 15
> [WARNING]
> """
Yes - I found that after the event - fixed - another X,000 warnings to go.
> # jena-arq README.txt
>
> For setting up the command line arguments the README talks about setting
> JENAROOT. If I try that the scripts complain that they were expecting
> ARQROOT.
Fixed.
The scripts in the dev system are different to the download zip ones.
Sort of preparation for when/if we have a "command zip".
> Might be worth explicitly mentioning in here that when working from an
> ARQ source release and wanting to set up command line use then you also
> need to do:
> mvn -DoutputDirectory=lib dependency:copy-dependencies
Done.
> # apache-jena-sources DEPENDENCIES
>
> Looks odd in having several duplicate entries (three references to each
> of jena-core and jena-arq for example) and having xerces as being from
> an unknown organization.
That file was autogenerated by RAT. There should have been a manually
edited version (automatic one neatened up).
I've put in a manual, better looking one here and other places.
Unfortunately, the DEPENDENCIES in the jars in WEB-INF always seems to
be auto-generated by RAT and has the same oddities - anyone know how to
control the choice of file?
> # apache-jena-sources BUILD
>
> s/alternativbely, yo/alternatively, you/
Done.
>
>
> Dave
Andy
Re: [VOTE] Release Jena 2.7.0
Posted by Dave Reynolds <da...@gmail.com>.
On Wed, 2011-12-14 at 17:45 +0000, Andy Seaborne wrote:
> Hi,
>
> Here vote on a release build for Jena 2.7.0
>
> Versions:
>
> jena-top 0-incubating
> jena-iri 0.9.0-incubating
> jena-code 2.7.0-incubating
> jena-arq 2.9.0-incubating
> jena-zip 2.7.0-incubating
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachejena-331/
>
> Proposed dist/ area:
> http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/
>
> Keys:
> https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS
+1
Fantastic job Andy!!
Checked basic signatures, hashes, BUILD/LICENSE/NOTICE files, maven
install from sources and test of random jena code using the results of
maven install. All fine as far as I can see
Trivial nits that don't affect release:
# Release message:
s/jena-code/jena-core/
Possible also s/jena-zip/apache-jena/ to match the artefact name.
# BUILD files for all projects
These reference in various places to:
jena-zzz-VER-incubator*
whereas the candidate release artefacts are all called:
jena-zzz-VER-incubating*
# jena-core README.txt
Refers to doc/readme.html which does not exist any more.
# jena-core ReleaseNotes.txt
Top entry is for "Jena 2.6.5" shouldn't that be 2.7.0?
(It's right in apache-jena/ReleaseNotes-Jena.txt).
# jena-arq pom.xml
The maven-resources-plugin is declared twice which causes Maven (3.0.3)
to complain:
"""
Some problems were encountered while building the effective model for
org.apache.jena:jena-arq:jar:2.9.0-incubating
[WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but
found duplicate declaration of plugin
org.apache.maven.plugins:maven-resources-plugin @ line 200, column 15
[WARNING]
"""
# jena-arq README.txt
For setting up the command line arguments the README talks about setting
JENAROOT. If I try that the scripts complain that they were expecting
ARQROOT.
Might be worth explicitly mentioning in here that when working from an
ARQ source release and wanting to set up command line use then you also
need to do:
mvn -DoutputDirectory=lib dependency:copy-dependencies
# apache-jena-sources DEPENDENCIES
Looks odd in having several duplicate entries (three references to each
of jena-core and jena-arq for example) and having xerces as being from
an unknown organization.
# apache-jena-sources BUILD
s/alternativbely, yo/alternatively, you/
Dave
Re: [] Release Jena 2.7.0
Posted by Paolo Castagna <ca...@googlemail.com>.
Hi Andy,
thanks again for all the work you have done to push out the first Apache
Jena release.
I answer your questions below. Answers can safely be ignored or read later.
No more questions from me => a reply is not necessary.
Time to celebrate the first Apache Jena release.
Happy Christmas to all.
Paolo
Andy Seaborne wrote:
>> Comments and rationale (longer version):
>>
>>
>> The dist area is used by people and reducing choices there, in future
>> releases,
>> would be a great improvement. For example, I was not sure about the
>> difference
>> between:
>>
>> apache-jena-2.7.0-incubating.tar.bz2 14-Dec-2011 15:50 14M
>> apache-jena-2.7.0-incubating.tar.gz 14-Dec-2011 15:44 16M
>>
>> I did not find a difference, so is apache-jena-2.7.0-incubating.tar.bz2
>> necessary?
>
> See
> http://incubator.apache.org/guides/releasemanagement.html
>
> and as an example:
> http://www.apache.org/dist/ant/binaries/
>
> These are the same set of files, packaged differently. bzip2 is
> sometimes significantly smaller.
"Compression Formats"
"Ship at least one of tar.gz, bz or bz2 for UNIX and linux (but note this).
Ship zip for windows."
The "note this" link does not work for me. I am not sure if there are good
reasons for bz2 vs. tar.gz.
"Note (TODO link) that there are known compatibility issues when using
certain tar programs. (TODO Saris verses GNU tar) It is recommend that
project that use Ant or Maven as build tools, use these tools to create
the archives since these implementations work well across a range of
platforms. It is recommended that project which do not use these tools
consider shipping the *nix package as a bz2 archive."
bz2 it is recommended for projects which do not use Ant or Maven to
create their archives.
[1] http://incubator.apache.org/guides/releasemanagement.html#best-practice-formats
When I was testing .tar.gz I was unsure if .bz2 was the same or not.
I checked and I did not find differences, therefore .bz2 did not increase
testing cost.
I am still unsure if other than size there are other reasons why it's there.
The documentation above does not answer that (probably because of the broken
links).
>
>> The instruction to recreate the release in the BUILD file found in
>> apache-jena-2.7.0-incubating-source-release.zip involve a lot of manual
>> steps (fortunately it's something most of the people will not need to go
>> through). Ideally, it could be: download, uncompress and run a command.
>> Easier to document, less likely something goes wrong.
>
> I thought we'd agreed this long ago.
> This release is to get something out of the door now.
Yes.
> I've suggested a change to a single-trunk multi-module build already so
> I'm not sure what point you are making here.
A single-trunk multi-module is an improvement and a simplication.
However, I used multi-module projects only with a single version for
all modules and where all modules are released together.
I am not sure if other approaches work well... and at the moment I do
not have time nor energy to investigate.
> For a single-trunk multi-module, like all the project you keep pointing
> to, we can have a single build. Multi-trunk, multi-module is a
> non-starter because of RAT, version tags and mvn release plugin
> assumptions. But we will loose the ability to branch modules as we do
> at the moment.
Yep.
For me, it is not a problem to branch a single-trunk even if I need
to experiment with only one module (if this simplifies the life of the
release manager and/or experience with tools we use).
> JenaDist replaces the a replacement source-release artifact creator. It
> does not create a complete image of the development systems at the point
> of release to match the SVN tag; it creates a special composite that
> isn't tested. The point of RAT is to capture common practice.
JenaDist is not something I am proud of :-). It should be ditched and moved
back to the Scratch area where it came from. It is something unusual and
certainly not a best practice. It is the best I was able to do with the
constraint of: "not change anything in all the others modules" and without
a single-trunk layout.
>
>> This is an example of ideal 'dist' area which I would be more happy with:
>
> Why are you unhappy? You use Jena from maven - this does not affect you.
The 'dist' area is for people who want to download and use Apache Jena.
Perhaps, they are not even developers and they want the binary version
to run some of the command line tools. A 'dist' area with less choices
is IMHO better for the 'dist' target audience.
The perfect situation is: no choice. Just one download option.
This in practice is not possible, since we need a 'source' release and
the operating system (i.e. .tar.gz and/or .bz2 for UNIX and .zip for
Windows).
Even if something does not affect directly me, it does not mean I don't care.
Better user experience for all Apache Jena users is something I care.
The more users the better. The better experience for everyone using Jena,
the better.
The current 'dist' also affect committers/testing at the time of a release.
This round I had time to test only:
- apache-jena-2.7.0-incubating.tar.gz
- apache-jena-2.7.0-incubating.tar.bz2 (same as above => zero cost)
Not the content in the directories:
- jena-arq-2.9.0-incubating/
- jena-core-2.7.0-incubating/
- jena-iri-0.9.0-incubating/
- jena-top-0-incubating/
I tested the content of the directories above (but *-source-release.zip)
via the Maven repository.
> The statement
> jena.staging.apache.org/jena/download/index.html
>
> """
> You can download official Apache releases from here:
>
> www.apache.org/dist/incubator/jena/
> """
>
> will lead as directly as possible to the latest version.
Ack.
> Building version numbers into documentation is to be strongly avoided
> IMHO.
Agree.
Some projects keep more than one version in the 'dist' area. If we will
only have one version in the 'dist' area. Good.
A directory is not necessary in this case.
Projects with more than one version in the 'dist' area, often have a
'stable'|'current'|'latest' link to point to the latest release (and
use that in the documentation). A good practice as well.
> (I'd remove them from that page - they don't get maintained
> especially at the point of release when there is enough to do already -
> but "thank you" to Ian for making sure it's ready to go).
>
>> http://w.a.o/dist/incubator/jena/apache-jena-x.y.z-incubating/
>
> Have you checked what is proposed?
>
Yes. See above.
> http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/apache-jena-2.7.0-incubating/
>
>
> Those files are all there exactly as you have them. +bz2 (separate issue).
>
> In addition, the latest download is top level as explained to make it
> easy for people, especially non-maven, novice users.
Yes.
If you think it's a good thing, when releases are archived, would it be
possible to move stuff:
- from: http://www.apache.org/dist/incubator/jena/*
- to: http://archive.apache.org/dist/incubator/jena/apache-jena-x.y.z-incubating/*
(or http://archive.apache.org/dist/incubator/jena/jena-x.y.z-incubating/*)
*not* in the rood http://archive.apache.org/dist/incubator/jena/, otherwise
it can become messy and confusing in the long run.
>> apache-jena-x.y.z-incubating.tar.gz
>> apache-jena-x.y.z-incubating.tar.gz.asc
>> apache-jena-x.y.z-incubating.tar.gz.md5
>> apache-jena-x.y.z-incubating.tar.gz.sha1
>> apache-jena-x.y.z-incubating.zip
>> apache-jena-x.y.z-incubating.zip.asc
>> apache-jena-x.y.z-incubating.zip.md5
>> apache-jena-x.y.z-incubating.zip.sha1
>> apache-jena-x.y.z-incubating-source-release.tar.gz (*)
>> apache-jena-x.y.z-incubating-source-release.tar.gz.asc
>> apache-jena-x.y.z-incubating-source-release.tar.gz.md5
>> apache-jena-x.y.z-incubating-source-release.tar.gz.sha1
>>
>> ... or, if people on Windows can uncompress a .tar.gz,
>
> They can't, without additional, non-standard programs. Support for zip
> files is built-in to Windows.
Ack.
> For more, see
> http://incubator.apache.org/guides/releasemanagement.html
Ack.
>> and there is no
>> difference between the content of:
>> apache-jena-x.y.z-incubating.tar.gz
>> apache-jena-x.y.z-incubating.zip
>>
>> Then, the 'dist' are could have even less choices (even better):
>>
>> http://w.a.o/dist/incubator/jena/apache-jena-x.y.z-incubating/
>>
>> apache-jena-x.y.z-incubating.tar.gz
>> apache-jena-x.y.z-incubating.tar.gz.asc
>> apache-jena-x.y.z-incubating.tar.gz.md5
>> apache-jena-x.y.z-incubating.tar.gz.sha1
>> apache-jena-x.y.z-incubating-source-release.tar.gz (*)
>> apache-jena-x.y.z-incubating-source-release.tar.gz.asc
>> apache-jena-x.y.z-incubating-source-release.tar.gz.md5
>> apache-jena-x.y.z-incubating-source-release.tar.gz.sha1
>>
>> (*) this file should (if future) contain all the sources necessary to
>> rebuild
>> the binary release (i.e. apache-jena-x.y.z-incubating.tar.gz). People who
>> want to recreate the binary release can download (*), uncompress and
>> run a
>> command.
>
> And we have discussed this several times. Release something now, create
> space for a reorg. What is the problem with what was in the pre-release
> trial run and the current release proposal?
Explained above.
> If, as it should be, (*) is everything, then we need a single-trunk
> multi-module layout to work with RAT. It has pros and cons; downside -
> branching per module is changed; releasing just a module needs tagging.
> I have no idea how the release plugin deals with it and want to test it
> out first.
Yes.
> I do know from experience that misconfiguring the release
> plugin will attempt to tag junk in the wrong place, not generate an
> warning or error in a dry run.
I've only used the release plugin (not on the Apache infrastructure) and
for single-trunk, multi-module projects where all the modules have the same
version and all the modules are released together. In this situation, I do
not have problems and there is little things left to do manually.
>> With the dist area above, users are presented with just one choice:
>> binary or sources?
>
> "users" is a vague and broad label.
>
> What sort of user might be looking in dist/?
> novice? redistributor?
Novice (more likely) => Less choices.
>
> How is each of those classes of user served?
Novice, first adopters => 'dist' area
Developers => artifacts repository
> Why add an additional level of directory naming?
> The file names have versions in them. What is gained and for whom?
As I said above.
If we have only one (i.e. the latest) release in the 'dist' area the
current approach works well (IMHO it can be further improved reducing
choices for users (in particular novice users) and, if possible,
removing the directories).
>> An example of an Apache multi-module project which keep a 'dist' area
>> very
>> clean and usable for people is Apache Whirr:
>> http://www.apache.org/dist/incubator/whirr/whirr-0.6.0-incubating/
>
> Does whirr serve the same community Jena does?
No. Only Jena serve the same community as Jena.
I think we can learn from looking at other well managed Apache projects.
None of the other well managed Apache projects will serve the same community
Jena does.
> Does it serve its community in the same way?
No. See above.
> Who is being served from thir dist/?
The Apache Whirr users who want to install and use the binary distribution
of Apache Whirr as quickly as possible. They download a .tar.gz, unzip it
and they can run the scripts in the bin/ directory.
Similar to Jena novice users: download a binary distribution, unzip it
and run the scripts in the bin/ or bat/ directory.
> Why is it called "src"? And what does that mean?
What they call 'src' is what we call 'source-release'.
> What is the history of its community and the expectations on
> distribution, naming and layout?
See above.
> Please can you explain how it applies to Jena?
It's a good example of a multi-module project with a minimal 'dist' area
which present users (in particular novice) with the less number of choices.
> Whirr does not produce a zip, yet its best practice to do so.
>
> "Apache Whirr is a set of libraries for running cloud services."
>
> Jena is not just a set of libraries. You yourself keep asking about
> Fuseki which is not a library.
Agree.
Fuseki is not a library. Closer (not the same) to something like Tomcat.
But, the Tomcat community is much bigger.
Apache Tomcat distribution area is here:
http://www.apache.org/dist/tomcat/
> You continually tell users to use maven - that's your personal opinion.
I didn't in this thread. :-)
In future, I'll make clear that everything I write about Maven or anything
else is my personal opinion.
I don't care about Maven in itself or any other tool we use to build/manage/
publish Apache Jena artifact. I am convinced that a repository or artifacts
with their sources and the dependencies between artifacts in a machine
readable format is a very good thing for the entire Java/Apache ecosystem.
Same is true for other programming languages which use different tools but
have an automated way to mange dependencies.
IMHO Maven happens to be the tool, from the ones I've used, that currently
sucks less and 'scales better' (*) with diversity and complexity.
(*) this does not mean 'maximum flexibility' nor freedom.
> I see the complete download as useful to a class of users.
Agree.
>> In relation to the artifacts in the Maven repo, we currently have:
>>
>>
>> https://repository.apache.org/content/repositories/orgapachejena-334/org/apache/jena/
>>
>>
>> apache-jena/
>> jena-arq/
>> jena-core/
>> jena-iri/
>> jena-top/
>>
>> My suggestion here, if possible, is not to publish the 'apache-jena'
>> artifact.
>
> And you want a single build command?
>
> It is the maven way to publish artifacts.
>
> Where would not-an-artifact go?
> How would it get there?
The problem with the current 'apache-jena' artifact is, as I said, that
it is not something developers can add to their dependencies in order to
use Jena. The name is a strong attractor and I fear someone might assume
it is that the artifact to depend on.
> What constitutes the formal release artifacts if it's split between
> maven repo and somewhere else?
http://www.apache.org/dev/release.html#what-must-every-release-contain
>
> If you look on incubator-general@, most maven-based projects don't even
> mention dist/. No idea why - it seems important to me.
Agree.
> I put it in
> because this is our first release and because I think that it should be
> mentioned in the vote. I explained that in the message on 1/Dec about
> the pre-release trial run.
>
>> Rationale: the files of the distribution are all available in the
>> 'dist' area
>> and apache-jena is not something people can use as their dependencies.
>
> The dist/ area is the official release bytes.
Yep.
>
>> Right now, you cannot have:
>>
>> <dependency>
>> <groupId>org.apache.jena</groupId>
>> <artifactId>apache-jena</artifactId>
>> <version>2.7.0-incubating</version>
>> </dependency>
>>
>> While an artifact repository is supposed to be used by programs rather
>> than
>> people, people often browse artifact repositories to find their
>> dependencies
>> or the latest version for a dependency they already have.
>
> This is contradictory to me. People can browse and find apache-jena.zip.
The artifact org.apache.jena:apache-jena:2.7.0-incubating is not a valid
dependency for developers wanting to use Apache Jena.
It you put this in your dependencies:
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>apache-jena</artifactId>
<version>2.7.0-incubating</version>
</dependency>
You get:
[ERROR] [...] Could not find artifact org.apache.jena:apache-jena:jar:2.7.0-incubating in apache-staging-repo (https://repository.apache.org/content/repositories/orgapachejena-334/)
> We could now add making it using Jenkins at low cost. I don't know
> another way to do that.
>
>>
>> The principle of less choices is still valid here. More importantly,
>> apache-jena would be the wrong choice and probably cause frustration
>> and questions as result.
>>
>> Paolo
>>
>
> Andy
Paolo
Re: [] Release Jena 2.7.0
Posted by Andy Seaborne <an...@apache.org>.
> Comments and rationale (longer version):
>
>
> The dist area is used by people and reducing choices there, in future releases,
> would be a great improvement. For example, I was not sure about the difference
> between:
>
> apache-jena-2.7.0-incubating.tar.bz2 14-Dec-2011 15:50 14M
> apache-jena-2.7.0-incubating.tar.gz 14-Dec-2011 15:44 16M
>
> I did not find a difference, so is apache-jena-2.7.0-incubating.tar.bz2
> necessary?
See
http://incubator.apache.org/guides/releasemanagement.html
and as an example:
http://www.apache.org/dist/ant/binaries/
These are the same set of files, packaged differently. bzip2 is
sometimes significantly smaller.
> The instruction to recreate the release in the BUILD file found in
> apache-jena-2.7.0-incubating-source-release.zip involve a lot of manual
> steps (fortunately it's something most of the people will not need to go
> through). Ideally, it could be: download, uncompress and run a command.
> Easier to document, less likely something goes wrong.
I thought we'd agreed this long ago.
This release is to get something out of the door now.
1/ This could easily be scripted
2/ Doing the build of the modules isn't the time consuming part.
Checking and fixing is. I built the entire cycle twice - one script
saves a little time and effort but there are far bigger cost in doing a
release, like writing all the emails.
3/ This is at-odds with not putting the download zip in maven.
I've suggested a change to a single-trunk multi-module build already so
I'm not sure what point you are making here.
For a single-trunk multi-module, like all the project you keep pointing
to, we can have a single build. Multi-trunk, multi-module is a
non-starter because of RAT, version tags and mvn release plugin
assumptions. But we will loose the ability to branch modules as we do
at the moment.
JenaDist replaces the a replacement source-release artifact creator. It
does not create a complete image of the development systems at the point
of release to match the SVN tag; it creates a special composite that
isn't tested. The point of RAT is to capture common practice.
> This is an example of ideal 'dist' area which I would be more happy with:
Why are you unhappy? You use Jena from maven - this does not affect you.
The statement
jena.staging.apache.org/jena/download/index.html
"""
You can download official Apache releases from here:
www.apache.org/dist/incubator/jena/
"""
will lead as directly as possible to the latest version.
Building version numbers into documentation is to be strongly avoided
IMHO. (I'd remove them from that page - they don't get maintained
especially at the point of release when there is enough to do already -
but "thank you" to Ian for making sure it's ready to go).
> http://w.a.o/dist/incubator/jena/apache-jena-x.y.z-incubating/
Have you checked what is proposed?
http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/apache-jena-2.7.0-incubating/
Those files are all there exactly as you have them. +bz2 (separate issue).
In addition, the latest download is top level as explained to make it
easy for people, especially non-maven, novice users.
> apache-jena-x.y.z-incubating.tar.gz
> apache-jena-x.y.z-incubating.tar.gz.asc
> apache-jena-x.y.z-incubating.tar.gz.md5
> apache-jena-x.y.z-incubating.tar.gz.sha1
> apache-jena-x.y.z-incubating.zip
> apache-jena-x.y.z-incubating.zip.asc
> apache-jena-x.y.z-incubating.zip.md5
> apache-jena-x.y.z-incubating.zip.sha1
> apache-jena-x.y.z-incubating-source-release.tar.gz (*)
> apache-jena-x.y.z-incubating-source-release.tar.gz.asc
> apache-jena-x.y.z-incubating-source-release.tar.gz.md5
> apache-jena-x.y.z-incubating-source-release.tar.gz.sha1
>
> ... or, if people on Windows can uncompress a .tar.gz,
They can't, without additional, non-standard programs. Support for zip
files is built-in to Windows.
For more, see
http://incubator.apache.org/guides/releasemanagement.html
> and there is no
> difference between the content of:
> apache-jena-x.y.z-incubating.tar.gz
> apache-jena-x.y.z-incubating.zip
>
> Then, the 'dist' are could have even less choices (even better):
>
> http://w.a.o/dist/incubator/jena/apache-jena-x.y.z-incubating/
>
> apache-jena-x.y.z-incubating.tar.gz
> apache-jena-x.y.z-incubating.tar.gz.asc
> apache-jena-x.y.z-incubating.tar.gz.md5
> apache-jena-x.y.z-incubating.tar.gz.sha1
> apache-jena-x.y.z-incubating-source-release.tar.gz (*)
> apache-jena-x.y.z-incubating-source-release.tar.gz.asc
> apache-jena-x.y.z-incubating-source-release.tar.gz.md5
> apache-jena-x.y.z-incubating-source-release.tar.gz.sha1
>
> (*) this file should (if future) contain all the sources necessary to rebuild
> the binary release (i.e. apache-jena-x.y.z-incubating.tar.gz). People who
> want to recreate the binary release can download (*), uncompress and run a
> command.
And we have discussed this several times. Release something now, create
space for a reorg. What is the problem with what was in the pre-release
trial run and the current release proposal?
If, as it should be, (*) is everything, then we need a single-trunk
multi-module layout to work with RAT. It has pros and cons; downside -
branching per module is changed; releasing just a module needs tagging.
I have no idea how the release plugin deals with it and want to test
it out first. I do know from experience that misconfiguring the release
plugin will attempt to tag junk in the wrong place, not generate an
warning or error in a dry run.
> With the dist area above, users are presented with just one choice:
> binary or sources?
"users" is a vague and broad label.
What sort of user might be looking in dist/?
novice? redistributor?
How is each of those classes of user served?
Why add an additional level of directory naming?
The file names have versions in them. What is gained and for whom?
> An example of an Apache multi-module project which keep a 'dist' area very
> clean and usable for people is Apache Whirr:
> http://www.apache.org/dist/incubator/whirr/whirr-0.6.0-incubating/
Does whirr serve the same community Jena does?
Does it serve its community in the same way?
Who is being served from thir dist/?
Why is it called "src"? And what does that mean?
What is the history of its community and the expectations on
distribution, naming and layout?
Please can you explain how it applies to Jena?
Whirr does not produce a zip, yet its best practice to do so.
"Apache Whirr is a set of libraries for running cloud services."
Jena is not just a set of libraries. You yourself keep asking about
Fuseki which is not a library.
You continually tell users to use maven - that's your personal opinion.
I see the complete download as useful to a class of users.
> In relation to the artifacts in the Maven repo, we currently have:
>
> https://repository.apache.org/content/repositories/orgapachejena-334/org/apache/jena/
>
> apache-jena/
> jena-arq/
> jena-core/
> jena-iri/
> jena-top/
>
> My suggestion here, if possible, is not to publish the 'apache-jena' artifact.
And you want a single build command?
It is the maven way to publish artifacts.
Where would not-an-artifact go?
How would it get there?
What constitutes the formal release artifacts if it's split between
maven repo and somewhere else?
If you look on incubator-general@, most maven-based projects don't even
mention dist/. No idea why - it seems important to me. I put it in
because this is our first release and because I think that it should be
mentioned in the vote. I explained that in the message on 1/Dec about
the pre-release trial run.
> Rationale: the files of the distribution are all available in the 'dist' area
> and apache-jena is not something people can use as their dependencies.
The dist/ area is the official release bytes.
> Right now, you cannot have:
>
> <dependency>
> <groupId>org.apache.jena</groupId>
> <artifactId>apache-jena</artifactId>
> <version>2.7.0-incubating</version>
> </dependency>
>
> While an artifact repository is supposed to be used by programs rather than
> people, people often browse artifact repositories to find their dependencies
> or the latest version for a dependency they already have.
This is contradictory to me. People can browse and find apache-jena.zip.
We could now add making it using Jenkins at low cost. I don't know
another way to do that.
>
> The principle of less choices is still valid here. More importantly,
> apache-jena would be the wrong choice and probably cause frustration
> and questions as result.
>
> Paolo
>
Andy
Re: [VOTE] Release Jena 2.7.0
Posted by Andy Seaborne <an...@apache.org>.
On 17/12/11 19:49, Paolo Castagna wrote:
> Andy Seaborne wrote:
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] 0 Don't care
>> [ ] -1 Don't release, because ...
>
> +1
>
> With a couple of important (short) comments:
>
> I suggest to put the files in a directory named 'apache-jena-2.7.0-incubating'
> in the Jena dist area (*not* in the root):
>
> http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/*
> http://www.apache.org/dist/incubator/jena/apache-jena-2.7.0-incubating/*
>
> If this is what you already had in mind, great.
No - I had in mind to put
~andy/dist-apache-jena-2.7.0-incubating-RC-1/*
as the contents of:
http://www.apache.org/dist/incubator/jena/
exactly as-is and as in the previous pre-release build proposal.
This will be archived and mirrored. We can then say widely
"download jena from http://www.apache.org/dist/incubator/jena/"
and that statement will lead to the latest version.
Only the latest version is in the dist/ area. On a new release, the
dist/ area is replaced with the new release. There is a link to the
archive of previous Apache releases - the dist/ area uses fancy
directory listing and I have put into a HEADER.html as strongly
suggested (maybe required - I don't care - it's a good idea).
> I suggest not to publish the 'apache-jena' artifact in the Maven repository.
> It is not an artifact people can use for their dependencies and the files
> for the distribution are all in the dist area.
What is in staging and the proposed dist are is what is being voted for.
The vote is on what is proposed; any change and a new vote is needed.
I can't ask for a vote, then change the details after people have voted.
If you wish to change your vote, please do so before the deadline.
Andy
Re: [VOTE] Release Jena 2.7.0
Posted by Paolo Castagna <ca...@googlemail.com>.
Andy Seaborne wrote:
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] 0 Don't care
> [ ] -1 Don't release, because ...
+1
With a couple of important (short) comments:
I suggest to put the files in a directory named 'apache-jena-2.7.0-incubating'
in the Jena dist area (*not* in the root):
http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/*
http://www.apache.org/dist/incubator/jena/apache-jena-2.7.0-incubating/*
If this is what you already had in mind, great.
I suggest not to publish the 'apache-jena' artifact in the Maven repository.
It is not an artifact people can use for their dependencies and the files
for the distribution are all in the dist area.
Thank you Andy.
- o -
Comments and rationale (longer version):
The dist area is used by people and reducing choices there, in future releases,
would be a great improvement. For example, I was not sure about the difference
between:
apache-jena-2.7.0-incubating.tar.bz2 14-Dec-2011 15:50 14M
apache-jena-2.7.0-incubating.tar.gz 14-Dec-2011 15:44 16M
I did not find a difference, so is apache-jena-2.7.0-incubating.tar.bz2
necessary?
The instruction to recreate the release in the BUILD file found in
apache-jena-2.7.0-incubating-source-release.zip involve a lot of manual
steps (fortunately it's something most of the people will not need to go
through). Ideally, it could be: download, uncompress and run a command.
Easier to document, less likely something goes wrong.
This is an example of ideal 'dist' area which I would be more happy with:
http://w.a.o/dist/incubator/jena/apache-jena-x.y.z-incubating/
apache-jena-x.y.z-incubating.tar.gz
apache-jena-x.y.z-incubating.tar.gz.asc
apache-jena-x.y.z-incubating.tar.gz.md5
apache-jena-x.y.z-incubating.tar.gz.sha1
apache-jena-x.y.z-incubating.zip
apache-jena-x.y.z-incubating.zip.asc
apache-jena-x.y.z-incubating.zip.md5
apache-jena-x.y.z-incubating.zip.sha1
apache-jena-x.y.z-incubating-source-release.tar.gz (*)
apache-jena-x.y.z-incubating-source-release.tar.gz.asc
apache-jena-x.y.z-incubating-source-release.tar.gz.md5
apache-jena-x.y.z-incubating-source-release.tar.gz.sha1
... or, if people on Windows can uncompress a .tar.gz, and there is no
difference between the content of:
apache-jena-x.y.z-incubating.tar.gz
apache-jena-x.y.z-incubating.zip
Then, the 'dist' are could have even less choices (even better):
http://w.a.o/dist/incubator/jena/apache-jena-x.y.z-incubating/
apache-jena-x.y.z-incubating.tar.gz
apache-jena-x.y.z-incubating.tar.gz.asc
apache-jena-x.y.z-incubating.tar.gz.md5
apache-jena-x.y.z-incubating.tar.gz.sha1
apache-jena-x.y.z-incubating-source-release.tar.gz (*)
apache-jena-x.y.z-incubating-source-release.tar.gz.asc
apache-jena-x.y.z-incubating-source-release.tar.gz.md5
apache-jena-x.y.z-incubating-source-release.tar.gz.sha1
(*) this file should (if future) contain all the sources necessary to rebuild
the binary release (i.e. apache-jena-x.y.z-incubating.tar.gz). People who
want to recreate the binary release can download (*), uncompress and run a
command.
With the dist area above, users are presented with just one choice:
binary or sources?
An example of an Apache multi-module project which keep a 'dist' area very
clean and usable for people is Apache Whirr:
http://www.apache.org/dist/incubator/whirr/whirr-0.6.0-incubating/
In relation to the artifacts in the Maven repo, we currently have:
https://repository.apache.org/content/repositories/orgapachejena-334/org/apache/jena/
apache-jena/
jena-arq/
jena-core/
jena-iri/
jena-top/
My suggestion here, if possible, is not to publish the 'apache-jena' artifact.
Rationale: the files of the distribution are all available in the 'dist' area
and apache-jena is not something people can use as their dependencies.
Right now, you cannot have:
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>apache-jena</artifactId>
<version>2.7.0-incubating</version>
</dependency>
While an artifact repository is supposed to be used by programs rather than
people, people often browse artifact repositories to find their dependencies
or the latest version for a dependency they already have.
The principle of less choices is still valid here. More importantly,
apache-jena would be the wrong choice and probably cause frustration
and questions as result.
Paolo
Re: [VOTE] Release Jena 2.7.0
Posted by Damian Steer <d....@bristol.ac.uk>.
On 14 Dec 2011, at 17:45, Andy Seaborne wrote:
> Hi,
>
> Here vote on a release build for Jena 2.7.0
+1 from me.
Thanks for all your hard work on this Andy.
Damian
(Minor issue while checking: what is the point of
<http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/apache-jena-2.7.0-incubating/apache-jena-2.7.0-incubating-source-release.zip>
?)
Re: [VOTE] Release Jena 2.7.0
Posted by Andy Seaborne <an...@apache.org>.
On 15/12/11 08:42, Paolo Castagna wrote:
> Thanks Andy for all the work you have done.
>
> Andy Seaborne wrote:
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachejena-331/
>
> This was a 404 for me.
>
> Found the staging repository here:
> https://repository.apache.org/content/repositories/orgapachejena-334/
>
> Thanks,
> Paolo
My apologies - 331 was my first attempt. I had to drop that and restart.
Andy
Re: [VOTE] Release Jena 2.7.0
Posted by Paolo Castagna <ca...@googlemail.com>.
Thanks Andy for all the work you have done.
Andy Seaborne wrote:
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachejena-331/
This was a 404 for me.
Found the staging repository here:
https://repository.apache.org/content/repositories/orgapachejena-334/
Thanks,
Paolo
Re: [VOTE] Release Jena 2.7.0
Posted by Leo Simons <ma...@leosimons.com>.
On Wed, Dec 14, 2011 at 6:45 PM, Andy Seaborne <an...@apache.org> wrote:
> Here vote on a release build for Jena 2.7.0
...
> Proposed dist/ area:
> http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/
+1 from me.
Well done Andy!
cheers,
Leo
Re: [VOTE] Release Jena 2.7.0
Posted by Benson Margulies <bi...@gmail.com>.
+1
0 is way cool. It's a separately released parent, and the next one
will be 1, and it will not be on the same schedule as the rest of the
system.
On Thu, Dec 15, 2011 at 8:11 PM, Ian Dickinson <ia...@epimorphics.com> wrote:
> Hi Andy,
>
>
> On 14/12/11 17:45, Andy Seaborne wrote:
>>
>> Hi,
>>
>> Here vote on a release build for Jena 2.7.0
>>
>> Versions:
>>
>> jena-top 0-incubating
>
> Version 0 of jena-top looks a bit unusual ... any particular reason why it's
> 0 and not, say, 2.7.0 for consistency?
>
> Ian
Re: [] Release Jena 2.7.0
Posted by Andy Seaborne <an...@apache.org>.
On 16/12/11 01:11, Ian Dickinson wrote:
> Hi Andy,
>
> On 14/12/11 17:45, Andy Seaborne wrote:
>> Hi,
>>
>> Here vote on a release build for Jena 2.7.0
>>
>> Versions:
>>
>> jena-top 0-incubating
> Version 0 of jena-top looks a bit unusual ... any particular reason why
> it's 0 and not, say, 2.7.0 for consistency?
>
> Ian
As Benson says.
The root Apache POM that jena-top defers to is v10,; it started at 1.
But why 1? It's just an ordering :-)
I had hoped that it would change very infrequently, not in step with
Jena full releases. Maybe, maybe not.
Andy
Re: [VOTE] Release Jena 2.7.0
Posted by Ian Dickinson <ia...@epimorphics.com>.
Hi Andy,
On 14/12/11 17:45, Andy Seaborne wrote:
> Hi,
>
> Here vote on a release build for Jena 2.7.0
>
> Versions:
>
> jena-top 0-incubating
Version 0 of jena-top looks a bit unusual ... any particular reason why
it's 0 and not, say, 2.7.0 for consistency?
Ian
Re: [VOTE] Release Jena 2.7.0
Posted by Stephen Allen <sa...@apache.org>.
> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] 0 Don't care
>> [ ] -1 Don't release, because ...
>>
>
+1
I was able to build all the modules successfully. Good work!
-Stephen
Re: [VOTE] Release Jena 2.7.0
Posted by Andy Seaborne <an...@apache.org>.
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] 0 Don't care
> [ ] -1 Don't release, because ...
+1
I have used the release artifacts from staging with TDB and Fuseki.
I've also downloaded, unpacked the apache-jena zip and run some linux
scripts. (For other testing, I'm probably blind to errors now.)
Andy