On 17/11/11 13:22, Paolo Castagna wrote:
Hi Andy
Andy Seaborne wrote:
On 17/11/11 00:57, Paolo Castagna wrote:
Paolo Castagna wrote:
If we agree on this, I'll provide an initial version tomorrow (just
let me know your preference for the name of the module).
Just to make things more explicit, here is an example (which is still
missing
a lot of things, but it has all the necessary jar files):
http://svn.apache.org/repos/asf/incubator/jena/Scratch/PC/JenaDist/trunk/
Paolo
If we do this, we might as well drop the zips for the other packages.
I think it would be a good idea to drop the zip files and just have one
zip for the Apache Jena distribution (including: jena-core, jena-arq,
jena-tdb (why not?), jena-iri, jena-larq as well as all their transitive
dependencies).
TDB needs work (e.g. JENA-143). Fuseki isn't ready.
So let us aim for IRI/core/ARQ/LARQ.
This would reduce the cost of maintaining separate assembly files.
Also, I need to investigate the use of moduleSets in the assembly.xml
descriptor... it might be better if we want to aggregate sources (and/or
shell scripts, no idea if this is possible).
Progress? Is it needed?
And the testing assemblies are not very helpful.
I am not saying we do this, however an option is to put testing files
in the src/test/resources directory and let Maven include them in the
-test.jar. However, tests need to load files via classloader instead of
directly from the file system. Maybe this is something to aim in the
future if there is agreement. Certainly not now.
Forget testing material in the distribution. It's not a helpful as it
might seem as you need all the "test" artifact jars and the test
scripting areas. In the interests of time, I would not consider doing
it this time round. Also, running the tests requires running from
particular locations.
I see some value in allowing people to depend on the test suite of
a project, it's not something that happens often, but sometimes it's
useful to depend/extend/run existing tests from a different module.
The only issue I see is time (but that looks OK) and risk (hard to tell).
Yep, I don't disagree.
Also, shell commands (from Jena, ARQ and TDB) probably should be moved on
a JenaDist module if we do that.
Yes
A crude solution is ship the ARQ zip as "apache-jena-VER.zip" but if
there is time, then a distribution project is a step in the right
direction.
I like this idea, it could be ARQ zip or indeed TDB zip (even better).
But, it would be good to have all the Jena, ARQ and TDB command line
in it.
In which case we have to solve the cross linkages so we might as well
use JenaDist.
Maybe we should do this as a first step and move the assembly part to
a JenaDist later when we do a second or subsequent release.
I scanned JenaDist and if we are going to use this time round:
0/ Make a top level module of Jena2
1/ A README needs to be written (inc how-to-use instructions)
The zip needs to be moderately self contained.
Explain what this is.
Brief how to use "put all the jars on the classpath"
Where to get javadoc.
The current pointer to the website for a standalone zip is a bit harsh.
Setting environment variables.
2/ Needs to include bin/ and bat/
I don't how to mechanism this - copy into JenaDist for now.
README or etc needs something on setting environment variables.
3/ NOTICE is wrong (old text)
4/ Needs the change logs from Jena and ARQ at least.
I don't how to mechanism this - copy into JenaDist for now.
5/ How do we have a "Apache source distribution"?
I think this is going to be interesting to explain to
incubator-general.
Are there any blockers?
Andy
