On Feb 21, 2012, at 12:59 PM, Pedro Giffuni wrote:

> On 02/21/12 12:46, Dave Fisher wrote:
>> Hi Armin,
>> 
>>  U   
>> branches/alg/install/ext_sources/48470d662650c3c074e1c3fabbc67bbd-README_source-9.0.0.7-bj.txt
>>  U   
>> branches/alg/install/ext_sources/3b179ed18f65c43141528aa6d2440db4-serf-1.0.0.tar.bz2
>>  U   
>> branches/alg/install/ext_sources/2c9b0f83ed5890af02c0df1c1776f39b-commons-httpclient-3.1-src.tar.gz
>>  U   
>> branches/alg/install/ext_sources/48a9f787f43a09c0a9b7b00cd1fddbbf-hyphen-2.7.1.tar.gz
>>  U   
>> branches/alg/install/ext_sources/bc702168a2af16869201dbe91e46ae48-LICENSE_Python-2.6.1
>> ...
>> <snipping a bunch of redundant external source tarballs.>
>> ...
>>  U   
>> branches/alg/install/ext_sources/c441926f3a552ed3e5b274b62e86af16-STLport-4.0.tar.gz
>> 
>> Is it necessary to have all these external source tarballs in the branch? 
>> These files are kept outside of trunk for a reason - to avoid sledgehammers 
>> on changes.
> 
> I have always been of the idea of keeping them outside the repository.

They're OK where they are right now. I just think they need to be on a branch. 
The proper action in svn is to tag.

> 
> I think that sourceforge will provide some extra space in the extensions
> site where we could keep them... but it's just an idea for later.

To me, dealing with the build dependencies is a post-release and pre-graduation 
issue. SourceForge might be the place if we need a forked version of a tool, 
but I really think that we should be using the dependent project's distribution 
as much as we can. For example Apache Tomcat 5.5.35 will always be available 
from http://archive.apache.org/dist/tomcat/tomcat-5/v5.5.35/

I'm certain that Rob will come up with the case of an orphaned project or one 
where needed alterations are not taken by the upstream. These are the 
SourceForge or new Incubator project cases.

Here is a list of apparent Apache projects (not intended to be complete)

commons-lang-2.3-src.tar.gz
commons-httpclient-3.1-src.tar.gz
commons-logging-1.1.1-src.tar.gz
commons-codec-1.3-src.tar.gz
lucene-2.3.2.tar.gz
apr-util-1.4.1.tar.gz
apr-1.4.5.tar.gz
apache-tomcat-5.5.35-src.tar.gz

In Apache POI we pull dependencies in an ant build script from maven.

    <property name="repository.m2" value="http://repo1.maven.org"/>
...
    <property name="ooxml.jsr173.jar" 
location="${ooxml.lib}/stax-api-1.0.1.jar"/>
    <property name="ooxml.jsr173.url" 
value="${repository.m2}/maven2/stax/stax-api/1.0.1/stax-api-1.0.1.jar"/>
...
        <antcall target="downloadfile">
            <param name="sourcefile" value="${ooxml.jsr173.url}"/>
            <param name="destfile" value="${ooxml.jsr173.jar}"/>
        </antcall>
...

I'm just saying that much can be managed outside of the Apache ooo repository. 
The best place is somewhere the dependent project has placed their releases.

For cases of files like the Adobe core AFMs - Adobe-Core35_AFMs-314.tar.gz 
These don't need to be external they are category A[1] and can be in the source 
tree if that makes sense:

Regards,
Dave

[1] https://issues.apache.org/jira/browse/LEGAL-35


> 
> Pedro.
> 

Reply via email to