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