On Thursday 15 March 2007 12:00, Daniel Kulp wrote:
> 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.

Just to quantify this.   Yesterday, there were 70957 GET requests from 
the m2-incubating-repository.     Of those, 64309 were 404s.  Obviously, 
as more incubator projects start using maven and deploying artifacts, 
this number should rise.

The m2 snapshot repository (which includes most of the incubator 
snapshots as well as snapshots for all the apache maven 2 stuff) 
generated 213634 GET requests, but only 65108 were 404's.   FYI: those 
two directories account for 1/2 the hits on p.a.o.


Dan



>
> 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]

Reply via email to