Conversely and more defendable, we could decide that anything with a transitive dependency hull that is not completely contained by central cannot be hosted in central. This is yet another approach to nuking the issue. The unfortunate side-effect would be to exclude all apache (and other) artifacts that happen to depend on sun, incubator etc.
It's nearly pointless and quite frustrating to the users to host something in central that can't be used without a bunch of manual work arounds. That means we either attempt to include these transitive dependencies, or we simply don't allow anything that uses them. -----Original Message----- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2008 1:31 PM To: general@incubator.apache.org Subject: Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository] point taken. -- dims On Thu, Sep 18, 2008 at 1:26 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > On Thursday 18 September 2008 1:14:53 pm Davanum Srinivas wrote: >> "but they cannot require third parties to not sync it into their >> repos." --> Is this something Maven PMC is >> thinking-about/voted-on/discussing? basically overriding the current >> un-written policy of the incubator? Please let us know. > > Not yet. But my point is if Maven was NOT an Apache project, what COULD we > do? > > Well, I guess one option would be to follow the java.net example and pollute > the m2-incubator-repository with a bunch of crap and overwrite releases and > add snapshots and stuff. Then they wouldn't want it. :-) > > > Dan > > >> >> thanks, >> dims >> >> On Thu, Sep 18, 2008 at 11:17 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote: >> > On Wednesday 17 September 2008 8:05:40 pm Henning Schmiedehausen wrote: >> >> > Thus: >> >> > If the central maven repository maintainers (Maven PMC) decide to put >> >> > incubator artifacts into their repository without a click through >> >> > "this is incubator code" disclaimer, we'd have no legal reason to say >> >> > no. The Apache License allows them to do so. >> >> >> >> The Incubator PMC controls the policy on how podlings release. Not the >> >> upstream policy. And this policy says: "You keep your releases separated >> >> from the official releases". >> > >> > I'm not disputing that. Currently, podling maven artifacts go to: >> > /www/people.apache.org/repo/m2-incubating-repository >> > and non-podling releases go to: >> > /www/people.apache.org/repo/m2-ibiblio-rsync-repository >> > (which is now a completely inaccurate name :-( Should be >> > m2-release-repository or similar) >> > They are separate. >> > >> > The difference right now is that a non-incubator third party (Maven PMC) >> > has decided to sync one of those trees into their repository. From >> > what I can see, there is no way an INCUBATOR policy could prevent another >> > third party from deciding to also sync the other tree in as well. >> > Projects don't release to central. They release to one of the above >> > directories and Maven pulls those into central. (as part of that, the >> > maven team checks the sigs to make sure they are OK, etc...) >> > >> > Another example.... My friend sets up a Nexus repository manager for >> > his users. He adds the incubator repo to the nexus config as he needs a >> > single thing out of there. Then, any users using my Nexus instance will >> > get incubator artifacts without setting the incubator repository in their >> > settings.xml. My friend is a third party, incubator definitely cannot >> > tell him not to do that. >> > >> >> Allowing the usage of a maven repo for >> >> publishing these is a privilege, not a right. >> > >> > OK. What "RIGHT" does the Incubator PMC have to tell the Maven PMC (or >> > RedHat or Debian or CPAN or ....) to not put incubator artifacts in their >> > repo? Infrastructure probably would have the right if the method maven >> > used caused bandwith issues or similar. Block IP type thing. They do >> > the same thing for "svn abuse". >> > >> > I re-iterate: projects do NOT release to central. They deploy to a >> > project or organization specific location and the MAVEN folks sync that >> > into central if that location meets their requirements and the needs of >> > their users. Basically, do the maven folks "trust" that location to not >> > be full of crap? (and can they trust that the stuff in that repo has a >> > license compatible with putting it in central?) >> > >> > One example of that NOT being the case is the java.net repo. Sun is >> > notoriously bad at putting crap in the repo. Thus, the Maven folks do >> > not sync that repo in anymore. They tried at one point, but it caused >> > too many issues. So they don't now. >> > >> > That's basically why I think the vote is relatively irrelevant. I voted >> > +1 cause I personally think the "policy" is bad for the incubator and >> > makes it harder for podlings to develop their communities and thus >> > graduate, but I also think the "policy" is completely irrelevant as it's >> > not enforceable by the Incubator PMC. The Incubator PMC CAN require the >> > podlings to keep their releases in a separate repo on people.apache.org, >> > but they cannot require third parties to not sync it into their repos. >> > >> > -- >> > Daniel Kulp >> > [EMAIL PROTECTED] >> > http://www.dankulp.com/blog >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas :: http://davanum.wordpress.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
