incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: ooo large commit breaks mirror sync !!
Date Wed, 22 Feb 2012 00:08:45 GMT

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.
> 


Mime
View raw message