incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <>
Subject Re: Jena (i.e. jena-core): ARQ isn't included in the distribution zip file
Date Sun, 20 Nov 2011 20:51:55 GMT
Hi Andy

Andy Seaborne wrote:
> On 20/11/11 14:46, Paolo Castagna wrote:
>> 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.
> This is the web!
> Loading from the classpath does not work - some tests need a base URI
> and some test load files using relative URIs.
>>> 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.
> We need to have a proper SVN area for it.  We can't go with something
> tucked under /Scratch/PC/


I put it there since is was just an experiment to communicate the idea.
I am also not sure about the name: JenaDist? JenaAll? Others?

> Can you do that?


I would call it JenaDist (and jena-dist the Maven name) and put it here:


>>> 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).
> Can we just concentrate on getting release done and not adding work to
> the timeline? We have the ChangeLogs already (and the JIRA log is
> somewhat minimal).


> We are not trying to detail every change (too much) - we're trying to
> tell people what they need to know, which isn't a detail dump of
> everything.
>> 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).
> I don't see it like that; it's not about the code, it's the process.
> We are trying to get through Apache process, including checking on
> incubator-general@  It's useful to read other incubator projects getting
> through that.
> We will only get some much bandwidth from people there; it's a busy place.
> While we can do dev builds, there isn't "quick" for releases.  My idea
> of "quick" is a few hours; loop time here is going to one week+ for a
> two sequential votes.  Getting it right is quite a good idea.



>     Andy

View raw message