- Leo
PS: ccing [EMAIL PROTECTED] so the lurkers on there know some actual
actions are imminent ;)
Summary
-------
Avalon should start following the distribution layout as it has been
decided by the infrastructure team. That means these mappings:
from:/www/www.apache.org/dist/avalon/${subproject}/v${v}/${artifact}-${v}-bin.${type}
to:/www/www.apache.org/dist/avalon/${subproject}/binaries/${artifact}-${v}-bin.${type}
from:/www/www.apache.org/dist/avalon/${subproject}/v${v}/${artifact}-${v}-src.${type}
to:/www/www.apache.org/dist/avalon/${subproject}/source/${artifact}-${v}-src.${type}
from:/www/www.apache.org/dist/avalon/${subproject}/latest/${artifact}-${v}-src.${type}
to:/www/www.apache.org/dist/avalon/${subproject}/${artifact}-current-src.${type}
from:/www/www.apache.org/dist/avalon/${subproject}/latest/${artifact}-${v}-bin.${type}
to:/www/www.apache.org/dist/avalon/${subproject}/${artifact}-current-bin.${type}
In addition, I'd like to flatten excalibur's components structure into
the main tree.
from:/www/www.apache.org/dist/avalon/excalibur/components/${subsubproject}/${artifact}-${v}-bin.${type}
to:/www/www.apache.org/dist/avalon/excalibur-${subsubproject}/binaries/${artifact}-${v}-bin.${type}
In addition, I would like to move files to the new location, then use
symlinks to refer back to the old location, so old urls to any
particular file will keep working.
What are the benefits?
----------------------
- it translates the avalon part of the distribution site to be compliant
with the mirroring guidelines, including the decisions reached on the
repository list some time ago
- it works with maven out of the box
- it works with ruper out of the box
- it removes the odd difference between excalibur and the rest of our
distribution setup
- it makes it easier to guess the url for the location of the most
current artifact of some project
(somemirror.com/avalon/framework/avalon-framework-current.tar.gz)
- we follow the same setup as all other projects (at least as all other
projects should), making locations easier to guess for our users
What are the drawbacks?
-----------------------
It is quite a bit of work to move existing files and do the symlinking.
As I am volunteering, that shouldn't concern y'all :D. You will also
need to get used to the new setup, and there'll be some disruption as
various mirrors update.
What else is planned?
---------------------
I want a maven or ant plugin which will allow you to do
cd ${someproject-location}
maven avalon:generate-distribution # build absolutely all artifacts
# which should be uploaded
# ... check the files built manually ...
maven avalon:publish \ # upload to
-Davalon.repo.location=avalon.apache.org/~you/candidate
# avalon.apache.org/~you/candidate
maven avalon:publish # publish to
# www.apache.org/dist/avalon/
but a completely consistent layout is the first step we need to take.
Further Comments
----------------
http://www.apache.org/dev/mirrors.html
describes a project layout which is different from our own:
"Each project (and sub-project) should follow this layout:
---
|--- source/
|--- binaries/
|--- platform/ [optional if produce platform-specific binaries]
|--- KEYS (containing PGP keys of all Release Managers to date)
|--- current (symlink to the current source tarball)
|--- current-source-tarball (symlink to the current source tarball)
[optional]"
the reorg discussions to date have resulted in a sort-of consensus to
just keep things simple. The idea is to add either
[root]
|--- [base]
|--- binaries/
|--- jars/ [this is new]
or
[root]
|--- [base]
|--- binaries/
|--- jars/ [this is new]
the last one is potentially compatible with maven: the directory named
[root] can be seen as a maven repository. We are now kind just waiting
for some projects to start doing this.
I would like to implement this @ avalon. My plan is to make sure the
entire existing structure is preserved by using symlinks, but it is
important we are all on board and aware so future releases go to the
right place. Please note that while I also don't think the layout
described above is completely optimal, it is IMHO way more important
that layouts are consistent than that they are perfect.
In the current setup, we basically have 2 "roots":
/www/www.apache.org/dist/avalon
(containing the subprojects framework, phoenix, logkit, and
the old excalibur 4.0 and 4.1 big archives)
/www/www.apache.org/dist/avalon/excalibur/components
(containing the recent per-component releases in a slightly
different directory structure)
I would like to have only one.
I didn't get that. Spell it out!
--------------------------------
The new directory structure would be (-> indicates a symlink):
/www/www.apache.org/dist/avalon/
# one global KEYS file
KEYS
README.html
HEADER.html
# explanatory text about licensing, refer
# to actual license files in subdirectories
LICENSE.txt
framework/
binaries/
avalon-framework-4.0-bin.tar.gz
avalon-framework-4.0-bin.tar.gz.asc
avalon-framework-4.0-bin.zip
avalon-framework-4.0-bin.zip.asc
# ...
avalon-framework-4.1.4-bin.tar.gz
avalon-framework-4.1.4-bin.tar.gz.asc
avalon-framework-4.1.4-bin.zip
avalon-framework-4.1.4-bin.zip.asc
LICENSE.txt -> ../LICENSE.txt
KEYS -> ../KEYS
README.html -> ../README.html
HEADER.html
jars/
avalon-framework-current.jar
-> avalon-framework-4.1.4.jar
avalon-framework-4.0.jar
avalon-framework-4.0.jar
# ...
avalon-framework-4.1.3.jar
avalon-framework-4.1.4.jar
LICENSE.txt -> ../LICENSE.txt
KEYS -> ../KEYS
README.html -> ../README.html
HEADER.html
source/
avalon-framework-4.0-src.tar.gz
avalon-framework-4.0-src.tar.gz.asc
avalon-framework-4.0-src.zip
avalon-framework-4.0-src.zip.asc
# ...
avalon-framework-4.1.4-src.tar.gz
avalon-framework-4.1.4-src.tar.gz.asc
avalon-framework-4.1.4-src.zip
avalon-framework-4.1.4-src.zip.asc
LICENSE.txt -> ../LICENSE.txt
KEYS -> ../KEYS
README.html -> ../README.html
HEADER.html
avalon-framework-4.1.4-src.tar.gz
-> source/avalon-framework-4.1.4-src.tar.gz
avalon-framework-4.1.4-src.tar.gz.asc
-> source/avalon-framework-4.1.4-src.tar.gz.asc
avalon-framework-current-src.tar.gz
-> avalon-framework-4.1.4-src.tar.gz
avalon-framework-current-src.tar.gz.asc
-> avalon-framework-4.1.4-src.tar.gz.asc
avalon-framework-4.1.4-bin.tar.gz
-> binaries/avalon-framework-4.1.4-bin.tar.gz
avalon-framework-4.1.4-bin.tar.gz.asc
-> binaries/avalon-framework-4.1.4-bin.tar.gz.asc
avalon-framework-current-bin.tar.gz
-> avalon-framework-4.1.4.tar.gz
avalon-framework-current-bin.tar.gz.asc
-> avalon-framework-4.1.4.tar.gz.asc
avalon-framework-4.1.4-src.zip
-> source/avalon-framework-4.1.4-src.zip
avalon-framework-4.1.4-src.zip.asc
-> source/avalon-framework-4.1.4-src.zip.asc
avalon-framework-current-zip.gz
-> avalon-framework-4.1.4-src.zip
avalon-framework-current-src.zip.asc
-> avalon-framework-4.1.4-src.zip.asc
avalon-framework-4.1.4-bin.zip
-> binaries/avalon-framework-4.1.4-bin.zip
avalon-framework-4.1.4-bin.zip.asc
-> binaries/avalon-framework-4.1.4-bin.zip.asc
avalon-framework-current-bin.zip
-> avalon-framework-4.1.4.zip
avalon-framework-current-bin.zip.asc
-> avalon-framework-4.1.4.zip.asc
KEYS -> ../KEYS
LICENSE.txt
README.html
HEADER.html
# for url compatibility, not continued for new releases
latest -> v4.1.4/
v4.0/
avalon-framework-4.0-bin.*
-> ../binaries/avalon-framework-4.0-bin.*
avalon-framework-4.0-src.*
-> ../source/avalon-framework-4.0-src.*
LICENSE.txt -> ../LICENSE.txt
KEYS -> ../KEYS
README.html -> ../README.html
HEADER.html
# ...
v4.1.4/
avalon-framework-4.1.4-bin.*
-> ../binaries/avalon-framework-4.1.4-bin.*
avalon-framework-4.1.4-src.*
-> ../source/avalon-framework-4.1.4-src.*
LICENSE.txt -> ../LICENSE.txt
KEYS -> ../KEYS
README.html -> ../README.html
HEADER.html
phoenix/
# exact same thing happens here as for framework
logkit/
# exact same thing happens here as for framework
excalibur-all/
# exact same thing happens here as for framework, with
# the exception of the components/ dir
# for url compatibility
components/
compatibility/ -> ../../excalibur-compatibility/
# ...
thread/ -> ../../excalibur-thread/
excalibur-compatibility/
source/
excalibur-compatibility-1.0.zip
excalibur-compatibility-1.0.zip.asc
LICENSE.txt -> ../LICENSE.txt
KEYS -> ../KEYS
README.html -> ../README.html
HEADER.html
binaries/ -> source/
jars/
excalibur-compatibility-current.jar
-> excalibur-compatibility-4.1.4.jar
excalibur-compatibility-1.0.jar
LICENSE.txt -> ../LICENSE.txt
KEYS -> ../KEYS
README.html -> ../README.html
HEADER.html
excalibur-compatibility-1.0.zip
-> source/excalibur-compatibility-1.0.zip
excalibur-compatibility-1.0.zip.asc
-> source/excalibur-compatibility-1.0.zip.asc
excalibur-compatibility-current.zip
-> excalibur-compatibility-1.0.zip
excalibur-compatibility-current.zip.asc
-> excalibur-compatibility-current.zip
KEYS -> ../KEYS
LICENSE.txt
README.html
HEADER.html
# ...
excalibur-thread/
# exact the same thing happens for excalibur-compatibility
How would this work with maven?
-------------------------------
maven.repository.root =
${maven.repository.root};http://www.apache.org/dist/avalon/
<!-- refer version 4.1.4 of avalon-framework -->
<dependency>
<groupId>framework</groupId>
<id>avalon-framework</id>
<version>4.1.4</version>
</dependency>
<!-- refer current version of phoenix -->
<dependency>
<groupId>phoenix</groupId>
<id>phoenix</id>
<version>current</version>
</dependency>
<!-- refer version 1.0 of excalibur-compatibility -->
<dependency>
<id>excalibur-compatibility</id>
<version>1.0</version>
</dependency>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]