On 02/21/12 19:08, Dave Fisher wrote:
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.
The recent issue in SVN was due to incorrect properties when uploading
the initial image of the repository: I don't see how tagging could have
prevented it but thankfully I don't think changing the properties will
be necessary in the future.
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.
The versions of icc and saxon that we carry are obsolete and are not
available anywhere but it's just a matter of updating them. I don't
think we carry orphaned projects proper.
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.
Yes, that's essentially what FreeBSD ports and all the subsequent linux
reinventions (Debian, Gentoo, etc) do. Subversion is not
a good place for holding them though.
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:
For an alternative approach look at the instructions in
main/stax/download/ .
cheers,
Pedro.
