incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)
Date Sun, 26 Feb 2012 17:08:30 GMT
>>>> `-- source-release
>>>>      `-- jena-tdb-0.9.0-incubating
>>> What's the point of the subdirectory?
>> because there are other modules with their own source-release artifact.  The
>> TDB release items will be merged into the existing directory.
> So why don't you do the same for the download directory?

The download/ directory would be for all modules.

But as I said, top level work for me as well.  One place where you can 
get all the jena-related "unpack-and-go" files.

Is that not possible?

>> We had been following a layout like CXF where source-release and binaries
>> are in the same directory.

>>> I still find it very confusing.
>>> e.g. where is the source file for
>>> jena-tdb-0.9.0-incubating-distribution.tar.gz?
> Sorry, that was a mistake - I meant where is the source for the dowload file
> apache-jena-tdb-0.9.0-incubating-distribution.tar.gz

As per "ant" example - there is a correctly named and positioned file 
and also a copy (and rename) elsewhere.

The specific rename is because, long term, post rework the build, we 
think "apache-jena-..." will be the packaged up forms and "jena-..." the 
core jars but that isn't really the issue here.  A systematically named 
file is available.

> What I care about is that it is:
> - more difficult to find the source than some of the binaries, because
> of the extra directory level.

Maybe I don't understand how should we manage multiple modules with 
currently have independent version numbers.

The proposal is have:


Is this better?


Can we put "easy to find" files in "/"?

> - not at all clear how to find the source for some of the binaries, as
> it is at a different level and with a different name.


are at the same level.

We did have a form like "sling" uses, split per module.

> - binaries are available as tar.gz and zip, but source only as zip

Sorry - I thought I'd answered this earlier.  We use org.apache:apache 
which comes down to this (in assemblies/source-release.xml) which just 
makes a zip.


so we just followed that.  It's a tradeoff - reuse unchnaged vs forking it.

For the .jar.gz: we used to ship a zip, which any Java systems must have 
access to as jar files are zip archives.  Adding .tar.gz was courtesy 
for people wanting files in those forms because it very little work to 
help them.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message