On 31/05/12 16:42, Möller Thorsten wrote:
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
I use that setup in some projects but I have found it to be problematic
in the detail sometimes.
I use maven from the command line.
Compiler settings can be different (and even different compilers).
Running maven outside, particularly "mvn clean", outside of Eclipse can
lead to confusion and sometimes. I "mvn clean deploy" to push a built
jar out to people quickly - I don't want an incremental built nor a mix
of compiler output. Nor the built jar being behind the classes but
that's more minor.
The classes directories don't take much space: the classes directories
account for about 32M for all of the active modules, 24M for core+ARQ.
((
Why jena-core is large than jena-arq when the jar sizes are the other
way round is a little bit of a mystery. Waving "compression" and
different package structures over the matter seems a bit weak.
))
Andy
~/Jena >> find . -name classes
./jena-iri/classes
./jena-core/classes
./jena-fuseki/classes
./jena-sdb/classes
./jena-tdb/classes
./jena-arq/classes
~/Jena >> find . -name classes | xargs du -shc
1.5M ./jena-iri/classes
13M ./jena-core/classes
740K ./jena-fuseki/classes
2.9M ./jena-sdb/classes
3.2M ./jena-tdb/classes
11M ./jena-arq/classes
32M total
