Sorry, for entering this late (too much travel makes it hard to keep up-to-date)...
On Tue, Jul 8, 2008 at 9:38 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > Davanum Srinivas wrote: >> I doubt we will get much help from the maven team to support this use >> case. They would rather get the central repo and get it done! What >> bugs me is that in this whole discussion, no one even mentions how >> easy it is to add another repo in the poms or the settings. Well, there is a general Central Repo requirement that you are not allowed to have <repository> in artifacts deployed to central. Not sure if someone is ensuring this, but becomes an issue if incubator artifacts are not mirrored to "central". > Look, Maven serves packages. Websites describe projects. Yes, every > project dependent on an incubating artifact should provide *website* > disclaimers that a piece of their project could fall off the earth. The "fall off the earth" for dependencies is a really weird argument for end-users. (Which I think Bill is trying to say). Let's say Apache TLP Flooba depends on Splinka, which is a SF hosted project. Noone is discussing here that we should have processes warning users that Splinka may fall off the earth, yet it is just as likely. Instead (I am convinced) that the user will "depend on" Flooba community toe deal with that if and when necessary. Sometimes when I hear this argument of community dissolution, one easily get the impression that the code vanishes from the planet and a black hole in my software appears. That is not the case... So, taking Roy's statement into account of "Incubator Releases are 100% ASF releases", then I see no reason why other projects can't depend on podlings, why there are disclaimers and being worried that the user is misled. Example; Felix have a dependency on Jetty. No one thinks twice about it. Jetty goes into Incubation (now they chose CodeHaus but could have been here), and suddenly we need to warn people, disclaimers that Jetty community might fall of the earth, it is not fully endorsed by ASF and what not. When there is no material change in code nor community. The user will make the conscious decision to have his/her own direct dependency on any project, and if that happens to be an Incubating project, it happens either from a download via the website (/dist/incubator/splinka) or via entering <groupId>org.apache.incubator.splinka</groupId> in the pom.xml. IMNSHO, all other indirect dependencies are irrelevant, considering the PMCs fairly strict vetting (making the legal aspect at least as good as any SF/CodeHaus/Berlios/OW2/... project) of podling releases. And so on for each level... While being on the topic; IMHO, podlings that are Sponsored by other PMCs, expected to become sub-projects there, should all be fast-tracked through the Incubator. Import -> Vett Legal -> Release -> Out to TLP. No reason to "educate" the new folks into be able to sustain a life on their own. The PMC where they are going will be responsible. If the receiving PMC don't want that, then they should not Sponsor and we get a natural valve in the intake, and a better ability to scale as work is distributed out of the Incubator. Now I crawl back under my seat, put on the life jacket and fly back to Malaysia. ;o) Cheers Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
