Mailing-List: contact repository-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: repository@apache.org
Received-SPF: pass (herse.apache.org: domain of steve.loughran@gmail.com
 designates 64.233.184.229 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=LrCriAbFRt4u8sxotNYHrTQz0bsy9xaQOzV6O9Cy8+lVVvEYCb782o71wbnzcKqjygEX3h4eYEVw6JOwGgSQGU91d2OITqvRt4AgWUNZS/IFfuOY+rNT5+2mk2ymSpy3gEoKbM7Wc909da8WA7xrhq4PzG34gQJ/oyrB93RVYXM=
Message-ID: <c84a50780612220812r1b37f3acqc62b41c78e5d210a@mail.gmail.com>
Date: Fri, 22 Dec 2006 16:12:20 +0000
From: "Steve Loughran" <steve.loughran@gmail.com>
To: repository@apache.org
Subject: Re: [repo] /www/people.apache.org/repo/m1-ibiblio-rsync-repository/
In-Reply-To: <768dcb2e0612220756w428f380ejeef679837980f705@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20061211091504.18111.qmail@minotaur.apache.org>
	 <1a5b6c410612120232x22eff7a0te31c712d0e87f8fe@mail.gmail.com>
	 <19e0530f0612120601k3c8da1dbodfede2702491a8e4@mail.gmail.com>
	 <1a5b6c410612121211y16ddbcf8mbde0df0346041192@mail.gmail.com>
	 <19e0530f0612121235s2302789cl264cbc5dbafaf657@mail.gmail.com>
	 <1a5b6c410612121254x21d4bafcw69f3beebf7878e18@mail.gmail.com>
	 <19e0530f0612121306i3a1ccacbq31020d8924e703d@mail.gmail.com>
	 <c84a50780612121330u52b6e864wf51b87591c1a944b@mail.gmail.com>
	 <31cc37360612121345k1010a06crdb08ea83377a582b@mail.gmail.com>
	 <768dcb2e0612220756w428f380ejeef679837980f705@mail.gmail.com>

On 22/12/06, Trustin Lee <trustin@gmail.com> wrote:

>
> > That's a current rule (?) enforcement being the key.
> >
> > >   -POMs have schema declaration and are valid against the schema
> > >   -POMs have no unexpanded ${project.version} values
> > >   -all dependencies resolve. You cannot depend on sun stuff that
> > > doesnt at least have a stub.
> > >   -dependency graph is acyclic and no ambiguities (conflicting
> > > artifacts at the same depth)
>
>
> What would happen we develop a compiler?  There's a chicken and an egg
> problem with developing a compiler.  Even if a project is not a compiler, a
> project can have this kind of acyclic dependencies.  A very careful rule on
> approving releasing an artifact with an acycle dependency though.

There already is an implicit loop in the build, as ant depends on an
XML compiler, and xerces depends on Ant.

So I wouldnt ban stuff, just look closely at the dependency chain.

>
> > >   -until we have an automated solution, all artifacts will be held in
> > > staging until hand audited. That means scanning the artifact looking
> > > for common-troublespots (testing artifacts non-optional, etc)
> > >   -checksums exist and are correct.
> > >   -MD includes license and POM author info.
> > >
> > > In an ideal world we'd audit the JARs and look for trouble there too.
> > >  -Java1.5+ class files (warn, dont reject :)
> >
> > Yeah, as highly likely this could be intentional.

of course

> >
> > >  -copied in class files from other JARs
> > > I dont have any stats on how much of an issue this is, yet.
>
>
> Does this mean that we can't provide an all-in-one artifact with all
> dependencies included even if all of them are licensed under ASL?

no, I just think we ought to recognise whenever the situation arises
and check that it is the right thing to do, and/or encourage the
releasers to release a copy of the artifact without all the merged in
files. Case in point, I have my own copy of jython.jar, with the
ora-regexp files stripped out.