Mailing-List: contact repository-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: repository@apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Maven and repository@apache.org
Date: Wed, 5 Jan 2005 09:27:16 -0500
Message-ID: <8E2D018A78A5A04095667ADF098FF29A042D61D2@ms06>
Thread-Topic: Maven and repository@apache.org
Thread-Index: AcTzJAVzdc78zK9NQXyOZ5e+iFVeewADWS0Q
From: "Tim O'Brien" <tobrien@discursive.com>
To: <repository@apache.org>,
	"Brett Porter" <brett.porter@gmail.com>

What about having an XML description of the contents of a repository? =20

Such a description could serve multiple purposes, it could be used to
enumerate known mirrors, it could be used to segment the "namespace" -
say we reach some agreement with Sun and all sun artifacts fall into a
namespace of sun-* and must be redirected to a Sun server, etc.  This
XML file could be used by tools that want to provide a list of every
possible artifact.

What if every Maven repository knew of every other Maven repository
because they all shared a common resolution.xml file (think /etc/hosts
before the existence of DNS - hackish but it worked). =20

> -----Original Message-----
> From: Brett Porter [mailto:brett.porter@gmail.com]=20
> Sent: Wednesday, January 05, 2005 6:43 AM
> To: repository@apache.org; Steve Loughran
> Subject: Re: Maven and repository@apache.org
>=20
> > I'll be the Ant rep.
>=20
> Great, thanks.
>=20
> > I am co-author of the (still stabilising) Ant <libraries> task; it'd
>=20
> yeah, I've got to 50 mail threads sitting flagged in gmail to=20
> read one day, as this is about the extent of what I know=20
> about it :) (after you introduced it to repository@ last year)
>=20
> > 1. security. this could be with MD5 checksums, or it could be with=20
> > signed JARs.
>=20
> MD5's aren't going to do much for security - they're mainly=20
> for download integrity. checking and publishing ASC files is=20
> a definite want I have, and that can be ramped up to the=20
> level of security you need (there are obviously varying=20
> levels of trust of the files and the KEYS themselves).
>=20
> > JAR signing needs retrofitting to existing files, but has the=20
> > advantage that JVMs integrate with it and you can do other tricks=20
> > (like put http://ibiblio.org.../artifact.jar on the classpath with=20
> > security turned on)
>=20
> That I haven't looked into, but would also be a good, but=20
> optional feature. I think this is more of a build feature=20
> than a repository feature? In fact, I'm sure we already do=20
> this for JNLP.
>=20
> > 2. licenses. not just auto-download of .LICENSE files, but ideally=20
> > some way to do click-through that even Sun are happy with.
>=20
> Yeah, there's a low hundreds JIRA entry for that (ie OLD :) I=20
> think even that wouldn't fly with Sun IIRC but it doesn't hurt to ask.
>=20
> Should be easy to add hooks and allow a user to say "never=20
> ask again for this license" to always accept ASL or=20
> something, but still report the license on download.
>=20
> Good ideas and reminders - keep them coming, and I'll put all=20
> this together on the wiki tomorrow-ish.
>=20
> Thanks,
> Brett
>=20
>=20