Am 31.05.2012 um 16:00 schrieb Andy Seaborne: > Assuming nothing gets in the way to create a higher priority task ... > > I'll start on the next release process. This may take a few days to get > completely clean. This will need some fine tuning to get all the names of > things right as it's slightly different from the last release (one single > build) and it's worth getting things right as (hopefully)!) this general > build approach will be the same for the next few releases. And it's also an > extended weekend here in the UK. > > The goal is to produce > > + The source-release > + Maven artifacts (iri, core, arq, tdb, fuseki) > + apache-jena download (zip and tar.gz) (iri,core,arq,tdb) > + jena-fuseki distribution. > > > Expect some svn turbulence of mvn release checkins. > > Expect one or more checking versions to be produced in advance of the formal > vote - normally, this would not be necessary but it is different from last > time. You can produce your own by "mvn package" in the top directory. > > > Speak now if there is anything outstanding. I have just done a RAT check of > licenses and fixed a few source files that had no license but as far as I am > aware and can see, otherwise this release is the same legal setup as last > time, except there is no ICU4j. > > I'm updating the release notes as well -- next time it would be good for > someone else to crank the release handle. It's not too bad ... > > Shout now if anything needs doing,
As an "external" developer that works directly from the sources, I have one wish (which seems appropriate to be addressed now): would it be possible to consolidate the compiler output path between Eclipse and Maven? At least for jena-arq and jena-core Eclipse is currently configured to use "classes" whereas Maven uses the standard "target/classes". If possible then make this consistent: target/classes and target/test-classes, respectively. I'm using this setup since a couple of years without problems (which reduces the amount of redundancy on my disk a bit). Thorsten > > Andy > > > On 27/05/12 18:17, Andy Seaborne wrote: >> On 25/05/12 14:29, Andy Seaborne wrote: >>> Next step: >>> >>> I will set up a Jenkins job to build (2.7.1-snapshot) apache-jena as a >>> preliminary step and then disable the explicit snapshot builds of >>> iri-core-arq-tdb. >>> >>> We can inspect the binary it builds ... and it will at least mean no >>> ordering problems with snapshot builds. >> >> There's a new job under Jenkins cunningly named to make it appear at the >> top of the list. It runs "mvn deploy" from the top of jena trunk. >> >> I tweaked the assembly for apache-jena to put in the examples code (a >> bit messily - tidying would be better). >> >> Needs more work - the version number of apache-jena is the parent .. and >> it's wrong. >> >> There is a spurious org.apache.jena.jena. which is the trunk pom. >> >> Suggestions for improvements welcome. I ran out of time yesterday to >> check/improve/tune so it is a bit rough. >> >> And please do commit fixes to any warnings. >> >> If you have a few moment, checking the zip file in apache-jena (tar.gz >> not made - just commented for testing as it whines about long file names >> a lot). >> >> Snapshot builds for iri/core/arq/tdb/fuseki disabled as the development >> build job makes those. >> >> Andy >
