Hi Andy
Andy Seaborne wrote:
> 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.
Ack.
>> 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?
None (I'll look at it on Monday). Not needed.
However, I have no idea how to aggregate sources from different modules
(this is needed as we need to publish the sources as well as binaries).
>>> 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.
Ok.
I was just saying that a good practice it to use src/test/resources
and load data files necessary for tests via classpath so that it's
possible and trivial to ship a self contained and working test suite
as a single jar. Apply this to what we have has a big cost for little
or close to zero value. So, I aggree on no action on this.
>
>> 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.
jena-core does not currently depend on jena-arq.
jena-arq depends on jena-core.
That's fine, no circular dependency.
We can use an assembly.xml in jena-arq to build a distribution including
jena-core, jena-iri, jena-arq. However, LARQ will not fit nicely with this
approach (since jena-arq does not depend on jena-larq).
Three options:
1/ We do this in LARQ
2/ We do this in JenaDist
3/ We do not include LARQ in the Jena distribution
2/ JenaDist is better IMHO.
3/ is also fine.
>
>> 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:
Oh, yeah, as I said: it is missing a lot of things. I wanted to share it
to show the idea of having a module with the dependencies on all the things
we want to include and no code whose aim is just to build the distribution.
> 0/ Make a top level module of Jena2
JenaDist should have JenaTop as parent pom, but other than this I do not
see what else we would need.
> 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.
Yes.
> 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.
Yes.
> 3/ NOTICE is wrong (old text)
Easy to fix.
Is this the NOTICE we want?
"""
Apache Jena - {module} module
Copyright 2011 The Apache Software Foundation
This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).
"""
>
> 4/ Needs the change logs from Jena and ARQ at least.
> I don't how to mechanism this - copy into JenaDist for now.
Ok.
JIRA has a "Change Log" tab which could help automating this (I often
forget to update the CHANGELOG.txt files and I agree that is important).
>
> 5/ How do we have a "Apache source distribution"?
> I think this is going to be interesting to explain to
> incubator-general.
This is one of the reasons why I wanted to explore the moduleSets option.
I think that could be the way to achieve this, but I am not sure until
I do it.
> Are there any blockers?
The source distribution is a MUST, so until we do that, that is a blocker.
Other than this, I do not see blockers or problems.
A final comment. We will probably not get everything right with the first
release, that's fine so long we are ready to quickly fix (via a bug fix
release) problems as we discover them. I think "release early and often"
applies here as we learn the release process in Apache and we try to fit
what we used to do in a different context (with different constraints).
Paolo
>
> Andy
