On Wed, 26 Feb 2003, Noel J. Bergman wrote: > - the ASF repository shall contain ASF jars, which don't > require oversight beyond the issuing PMC.
> - the ASF repository should contain shared third party > jars for which the ASF has approved their use and > distribution. > - the ASF repository shall be mirrorable. Tools > intended to work with the ASF repository should > understand mirroring. [If not, they may select > a specific mirror, but I don't believe that we > want them to select the ASF repository as *the* > location.] Yes - finding the closest mirror ( or the fastest mirror ) is technically possible, but I'm sure most people would be ok if they just select one from a list, like they do for sourceforge. The ASF distributions are already mirrorable - all that we need is for the .jars to be included. I'm not very sure why the daedalus repository needs to make the symlinks ( when the main dist for src and binary releases is established ) and how those will be mirrored. > - multiple repositories are good things, and smart > tools should deal with multiple repositories. Supporting multiple kinds of repositories is good - i.e. support the original distribution format. A download tool shouldn't be specific to apache or apache repository - it should be able to get stuff from ibiblio or sourceforge or Sun or IBM ( eventually after displaying the license where it is required ). Multiple repositories for Apache projects are not a bad thing - maven or centipede or RedHat can choose to create other forms of repositories ( that work better with their tools ). I use apt-get to install software on my linux ( and emerge on the other box ) - a rpm or gentoo repository ( that is up to date ) would be great. I usually preffer getting a jar from the "source" - in the original format, with the signatures and guarantee of the producer. > - a smart tool might present a click-through license. > The repository should permit this as necessary. > [netbeans.org does this, by the way] Yes, that's a good example. Not sure if netbeans download tool supports sf or will support ASF repository - or if they provide their own repository with software to download (well, they do - but I don't know how complete it is ). I'm sure eclipse and other IDEs will eventually either support the original repositories ( my prefference ) or their own repositories. The actual layout of the files and location ( ASF mirrors, sf mirrors, etc) is far less important then the metadata format that describes the dependencies. We already have Gump descriptors covering everything in apache - and IMO this should be used either directly or transformed in one of the standard formats for describing dependencies. ( like apt descriptors, etc - there are several de-facto standards that are already supported by tools ). > - ASF projects, however, must not rely upon unapproved > third party jar files in such manner as to compromise > their license integrity, even if that jar is not > distributed via the ASF repository. Exactly. It was made clear ( and nobody objected ) that using tools in the build process is acceptable, and runtime dependencies are the main concern. So in the build process ASF projects may need to get GPL stuff from a GPL repository. This should be optional - IMO - but it seems this is not a legal requirement. > > If this becomes an apache-wide policy, I strongly disagree > > that Maven can decide for apache policies. > > I have proposed that the repository be a build-tool-neutral infrastructure > sub-project, since Dw expressed the willingness to have it under > infrastructure. I propose that Dion Gillard initially lead that effort, > taking advantage of his experience in the area. I don't believe that Dion > is a "Maven will define for all" kind of guy. Yes, the repository effects > all projects, but to me that just means that each PMC that cares to should > represent itself, not that we need to have dozens of people working this > out. Not sure what you mean by "lead" ( do you propose a new PMC with Dion as chair ? ). I'm +1 on Dion - however the layout and recommendations must be decided by the normal apache community process ( which doesn't include the notion of "lead", but proposals and votes ). Again - at least I have absolutely no problem accepting any layout, as long as I am sure it is the result of the apache community decision. Maven made a number of decisions that may be excelent for maven - but they're obviously different from what many apache projects use in their distribution. I'm also fine with a layout and policy that is set by infrastructure, under authority from the board. If a layout/policy is defined - we should do our best to sync the projects and start using the layout ( same thing that happened with the mirroring ) Same for metadata ( that describes dependencies ). However for metadata I think the standard requires participation from all build projects ( who want to participate ) - i.e gump, ant, centipede, maven. I strongly believe Gump descriptors should be the starting point - but again I'm just one vote, and I'm sure a middle ground could be found. Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
