On Thursday 15 March 2007 11:33, Davanum Srinivas wrote: > Could you please summarize the "difficulties"/"inconvenience" in the > current status quo?
There are a few main issues: 1) Finding stuff - when a user is searching for the groupId/artifactId of something, they generally just go look in central. There are a couple of maven repository search engines that just index central. For example, if I KNOW I need an orb, I know Yoko has an orb, I know it's org.apache.yoko for the groupId, but I don't know it's yoko-core for the artifactId, it turns up empty if I try a search. 2) It REALLY slows down the builds for everyone that takes an incubator dependency. When you define a repository in your pom, maven looks there FIRST for EVERY artifact. Thus, if you add the incubator repository to grab a single incubator artifact, your build will get a LOT slower as it looks there for EVERYTHING. For me, pings to p.a.o are ~90ms. Pings to central are ~42ms. You're basically adding at least a 1/10 of a second for every artifact in my builds that's NOT in the incubator repository. 3) Load on p.a.o. Because of (2), it can be a lot of traffic on p.a.o. Most will result in 404 errors, but still, that's a lot of uneeded connections. 4) Because the incubator repository is not mirrored, if p.a.o goes down or the link to apache goes down, a lot of projects will be unable to even build. If central goes down, there are several mirrors on the net, like ibiblio, that people can redirect central to. 5) Having them separate from central really only annoys those who actually want to use the official apache versions. For my customers, I could easily create a com.dankulp:orb:1.0 pom that just depends on yoko from the incubator repository. That can be put in central and my customers can depend on that and not even know they are getting the stuff from incubator. They would still be using the actual apache incubator jars, but they wouldn't have to know about it. Do I need to continue? Dan > > thanks, > dims > > On 3/15/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > On Thursday 15 March 2007 11:12, Noel J. Bergman wrote: > > > Martijn Dashorst wrote: > > > > > Jochen Wiedmann wrote: > > > > > > My personal opinion is that an "incubator" in the groupId or > > > > > > artifactId would be more than sufficient to mark the > > > > > > Incubator status > > > > > > > > The version attribute is more appropriate IMO, and what was > > > > agreed upon in an earlier thread on this list. > > > > > > As I understand it, so please correct me if I am wrong, if I > > > download a program that builds using Maven, and it has > > > dependencies in its pom.xml on Incubator artifiacts, then if > > > Incubator artifacts are conflated with ASF artifacts, then when I > > > built the program, it will automatically download the Incubator > > > artifacts from the repository without my being aware of the > > > dependency. However, if the Incubator artifacts are segregated > > > into a separate repository, then Maven will not download them > > > until I, the downstream user, add that repository to Maven. Is > > > that correct or incorrect? > > > > Semi correct. > > > > If my project directly depends on incubator artifacts, I would need > > to put the incubator repository in my pom. However, if I depend on > > another project that depends on incubator artifacts, I wouldn't > > because most likely, their poms have a repository entry for the > > incubator. > > > > As an example. Let's say I am writing a project that depends on > > geronimo 1.2-beta. Geronimo 1.2-beta depends on several incubator > > artifacts (yoko, openejb, some active mq stuff, etc..). The > > geronimo pom defines the incubator repository. Thus, anything from > > the incubator that it needs will automatically be grabbed without me > > knowing about it. > > > > The only time a user is forced to acknowledge it by defining the > > incubator repository is if they take a DIRECT dependency. > > > > > > -- > > J. Daniel Kulp > > Principal Engineer > > IONA > > P: 781-902-8727 C: 508-380-7194 > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog > > > > -------------------------------------------------------------------- > >- To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
