Why don't we just focus on: a) getting an ASF-only repository up first, and b) Getting the management and tooling for that
before taking on virtual hosting. I'm failing to see the requirement for us to do that *now*. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ "Tim Anderson" <[EMAIL PROTECTED]> wrote on 23/11/2003 11:06:08 AM: > Virtual artifacts have the potential to: > . simplify build environments > . simplify installation documentation > . reduce the bar of entry for building ASF software > . reduce support requests > . allow meta-data to be associated with 3rd > party artifacts > > They are not about: > . hosting 3rd party artifacts within ASF repository > . circumventing licenses of 3rd party products > . exposing ASF to liability > > So far, no one has demonstrated that virtual > artifacts would expose ASF to liability - > although I'm not privvy to discussions held on > non-public ASF lists. > > -Tim > > > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > > Sent: Sunday, 23 November 2003 10:41 AM > > To: [EMAIL PROTECTED] > > > > > Suppose ASF has the following link in the repository: > > > http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar > > > This is a virtual artifact, not hosted at ASF. > > > > I do not like the idea of virtual artifacts. I think that the > > meta-data for > > any component that needs a foreign artifact should contain the information > > needed by some tool. I don't think that we want to include foreign > > components in the ASF namespace. In fact, there is a situation right now > > where someone else has done that to the ASF, and we're not happy about it. > > > > --- Noel > > > > > >
