On 06/09/11 11:22, Paolo Castagna wrote:
Hi Andy
Andy Seaborne wrote:
On 05/09/11 14:58, Paolo Castagna wrote:
Hi,
I propose these changes (see patch attached) to the ARQ's pom.xml file
and, if that is ok, similar changes to for Jena and the other Jena
modules.
We will be using this<groupId>org.apache.jena</groupId> as groupId for
all the artifacts produced by the Jena project.
We can start publishing SNAPSHOTs to the Apache Maven Repository [1] and
receive feedback on those as well as the technical details of the
releases
in Apache.
Paolo
[1] https://repository.apache.org/
There are various things we need to do to get the build into a state
where we can release on Apache. We also need to sort out the build
system (more in another email).
I'd prefer that the changes as seen by our users are made in a single
step, or as few steps as possible. Advanced users do pickup snapshots,
as do builds of the other components that depend on ARQ. Fuseki and
TxTDB are picking up ARQ snapshots currently.
I do agree: a single step change is better.
I included the changes for ARQ's pom.xml file only, as an example of what
I am proposing, but I also proposed to do same changes for all the other
Jena modules: Eyeball, Fuseki, IRI, Joseki, LARQ, SDB, TDB and, last but
not least, jena.
We can change the<groupId> to "org.apache.jena" for all the modules in
one step.
By "one step" I meant more than changes to all the POMs. If we change
the POMs, we can't release as we currently do so there is a gap. The
one step I'd ideally like to see includes any jar renaming.
I'd rather get the build sorted out, and start snapshots from something
close to an Apache compliant release process even for a Jena2 release.
Andy
This way we can publish all the SNAPSHOTs on the Apache Maven Repository
and test the technicalities of releasing artifacts and "dist" files into
Apache.
>
At release time, we will need to release on Apache infrastructure as well
(i.e. next release for each module will be an Apache one).
Notice: there are no SNAPSHOTs with "non Apache" groupIds here:
https://repository.apache.org/content/repositories/snapshots/
Also:
"It is best to use the groupId and artifactId that will be used upon
graduation. The version should include incubating (or incubator) to
ensure that the artifacts created comply with Incubator release policy."
--
http://incubator.apache.org/guides/releasemanagement.html#best-practice-maven
We have an example with the LARQ module, but I had no chance to test
the final step of the release process (i.e. there are SNAPSHOTs published:
https://repository.apache.org/content/repositories/snapshots/org/apache/jena/larq/
the only way I can think of to test it end-to-end on Apache infrastructure
is doing it.
Also, maybe one of our mentors familiar with Maven and Maven in Apache
can also help here or give feedback on what we are doing, for example by
inspecting:
https://svn.apache.org/repos/asf/incubator/jena/Jena2/LARQ/trunk/pom.xml
and signal problems, missing things, etc. Any volunteer?
Just moving the non-Apache releaseable snapshots to Apache causes users
(and other modules) to have to do something in order to keep picking up
the latest from the new location. Just making this change and then
using it would force changes things so it has a cost.
Yes, it has a cost.
Let's at least try to do this with a minimal number of change points,
ideally one.
Ok.
Let's discuss where we want to get to, then see the way to
get there before making incremental steps that cause a number of
external changes.
Here
https://repository.apache.org/content/repositories/releases/org/apache/jena/
and out of the incubator :-)
Paolo
Andy
