Re: Maven and repository@apache.org
Hi gang, On 05-01-2005 09:39, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: What relationship does the repository list have with Maven? What relationship does Maven have with the repository list? Ass Brett Porter has written, and I agree: 1) Maven PMC takes ownership for getting the repository right IIRC [EMAIL PROTECTED] is actually a President's committee sort-of hanging off infra@ that's been tasked with figuring all this stuff out. The reason its not just the Maven PMC in the first place is that there's some other people that have something to say as well (i.e. precisely the people listed below). So I don't get why there's an ownership issue to reconsider. The maven PMC peeps to work on this (Brett, Mark, anyone else who volunteers) just get on the repository mailing list and JFDI. 2) Henk, myself (Maven PMC), Mark Diggory (if available), representative from interested Apache projects PMC (most likely someone from Ant) get together to sort out exactly what we think needs doing (we can use the repository list if appropriate) Yep, sounds like a good idea. 3) suggest small steps to fix each problem rather than coming up with a killer solution that will never get implemented Sounds like a good idea too. I'm guessing this is why I bailed out of that mailing list in the first place; we were solving too big a problem at once. 4) can use the repository wiki for information based on what has already been discussed And again, sounds like a good idea. I'd add that to use a common repository, there needs an implementation for all projects to use. The [EMAIL PROTECTED] project was not tasked to deal with that. I think this conflicts with #3. Maven has support, ant will have support, magic (from the DPML guys) has support, several ant-based scripts are around that provide support. Any tool that can HTTP GET can trivially be made to get files from the repository. For example I think I've done the basics in python, ruby, and bash+wget+grep every now and then. Cheers, - Leo
unsubscribing
Hi gang, I've not been keeping up with activities over here for a while now (busy doing other things :-D). I'm unsubscribing. Insofar as there was a special president's committee for repository@ (I vaguely seem to recall such a thing being set up), can someone please take the steps required to remove me from the committee? -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett
Re: Maven Repository @ Apache
Joshua Slive wrote: maven.repo.remote = [preferred]/avalon,http://www.ibiblio.org/maven Sorry, I'm not on [EMAIL PROTECTED] (Do we have any mirror maintainers on that list?) But I don't believe this is a particularly smart thing to do. hmm. Good point. I've disabled this feature for now. A shame though :D cheers, - Leo PS: note this was not something discussed on [EMAIL PROTECTED] just seemed a good idea at the time :D
Re: Revival
As for standards, I like the concensus we arrived at (and I would be highly against changing that again now as its just a major pain in the to move 100s of files around). As for code, well, personally, not really. Maven worksforme :D. But it could be a good idea nevertheless. cheers, - Leo [EMAIL PROTECTED] wrote: Is anyone interested in reviving this project?
[PROPOSAL] follow apache mirror layout convention
Hi gang,
I propose we start following the apache mirror layout convention as
designed by the infrastructure team, including the amendment voted upon
by the [EMAIL PROTECTED] I volunteer to do so (aw!). Details below.
- 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
[proposal] repository URI format
Hi all, just read what's in the archive until now. I've summarized (well, not really summarized, more elongated) the discussions up till now, added my own thoughts, done some reasearch, and then I came to a conclusion. I suggest y'all rip this apart, put it together again, (it's in wiki-compatible format :D) and then someone tallies a vote on whatever list is appropriate. cheers, - Leo = THE URI FORMAT FOR A SOFTWARE ARTIFACT REPOSITORY = = Conclusion = I'll provide my conclusion first, as this is rather a lot of text :D When the following is known, the URI for any software distribution architecture is uniquely specified: * FQDN - fully qualified domain name of the repository as defined in the URL spec * protocol - scheme as defined in the URI spec * base - base directory on the machine identified by FQDN (probably relative to documentroot), preferably consisting of lowercase letters, dashes and slashes * organisation - the inverse of the domain name of the organisation that produces the artifact * project - the division/group within the organisation that produces the artifact, preferably consisting of lowercase letters, dashes and slashes, with a website at http://project.organisation/ * name - the name of the artifact (unique within the project), preferably consisting of lowercase letters and dashes * type - the filetype of the artifact, consisting of whatever part of the artifact filename normally identifies the filetype * version - the version of the artifact, consisting of any set of characters allowed in an URI, augmented with any information about software or hardware platform requirements if not normally part of the version, preferably consiting of numbers, letters, dashes and points and for various reasons detailed below I think the URI should be composed based on the above as follows: protocol://FQDN/baseorganisation/project/name/types/artifact = Goal of the Discussion = The goal of this part of the discussion is to define additional constraints/ guidelines above and beyond the URI specification to make it possible to uniquely and unambiguously define the location of a software distribution artifact, when the following are known: * the /FQDN/ of the repository (ie repo.apache.org) * the /protocol/ used to access the repository (ie http) * the /base/ directory of the repository (ie /dist/repository or /) * the /organisation/ that produces the artifact * the /project/ within the organisation that produces the artifact * the /name/ of the artifact * the distribution /type/ of the artifact * the /version/ of the artifact = Requirements = * The URI should be stable * The URI should be easy to generate by humans and machines when the above listed items are known * The URI should be unique based on the uniqueness of the above listed items, ie: if ! otherURI.FQDN == thisURI.FQDN return false elseif ! otherURI.protocol == thisURI.protocol return false elseif ! otherURI.basedir == thisURI.basedir return false elseif ! otherURI.organisation == thisURI.organisation return false elseif ! otherURI.project == thisURI.project return false elseif ! otherURI.name == thisURI.name return false elseif ! otherURI.version == thisURI.version return false else return true * the part of the URI not containing FQDN, protocol and basedir should be common across repositories, ie it is desirable that an artifact identified by ** the organisation that produces the artifact ** the project within the organisation that produces the artifact ** the name of the artifact ** the version of the artifact can be found on any repository by substituting the repository FQDN, protocol and basedir from the current URI = Proposals = == Base Identifaction conventions == base will often be , but in the case of mirrors mirroring many repositories (ie ibiblio), that might be impractical, in which case I suggest the base is whatever maps to a directory on the filesystem the repository is using (ie whatever ext2/3, fat32, whatever accepts as a directory identifier). == Organisation Identification conventions == It has been suggested that the identification of the organisation is done by reverse domain names, ie org.apache, org.sun and com.ibm. It has also been suggested that the organisation is not identified seperately (ie as is current practice on http://www.ibiblio.org/maven/). == Project Identification conventions == It has been suggested that the identification of a project is done by lowercase letters seperated by dashes, ie jakarta-commons. I have seen no suggestions as to how the apache project sturcture should map into the project names in the
