incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
Subject Re: Killing the incubator m2 repository
Date Thu, 15 Mar 2007 17:28:06 GMT
On Thursday 15 March 2007 12:26, Davanum Srinivas wrote:
> Also, are you advocating that all incubator snapshots go to the
> central repo??? you will have #2 and #3 anyways even if we publish the
> released artifacts to central repo.

God no.  SNAPSHOTs either stay at apache (but work with infrastructure to 
find an appropriate home) or get synced to repo1.maven.org, but in a 
separate location (other than /maven2) where deletes would actually 
occur.   

Maven treats SNAPSHOTS differently than releases.   If the repository 
entry is properly configured (big IF BTW), it will only look at the 
SNAPSHOT repository if you actually ask for a SNAPSHOT.   Since using 
SNAPSHOT's is usually discouraged, the hit count would be lower.     
That's why 404's are 80% of the incubator repository, but only 25% of 
the SNAPSHOT repository. 


> One more thing, If you are end user downloading a released incubator
> artifact, how many times does maven down load it into their local hard
> disk repo from p.a.o? please say just once.

Once.   But a lot of automated builds (cruisecontrol, etc...) may wipe 
out their ~/.m2/repository dir for each build for reliability checks.   
Also, a lot of developers periodically do the same to clean it out, 
remove old versions, etc...

SNAPSHOT's get downloaded once, but once a day it does check to see if 
there is a new version.

The other complication is that if there are artifacts in central that are 
missing their poms, it gets checked every build.   That IS a bug in 
maven that is logged in jira.   It's also a bug in the projects that 
supply those artifacts.

Dan

>
> thanks,
> dims
>
> On 3/15/07, Davanum Srinivas <davanum@gmail.com> wrote:
> > #1) This is by design. We don't want to make it easy.
> > #2 and #3) i don't really have anything to day.
> > #4) is a problem. We can address it say by asking infra to rsync it
> > to say the eu boxes
> > #5) I really hope you don't do this :)
> >
> > thanks,
> > dims
> >
> > On 3/15/07, Daniel Kulp <daniel.kulp@iona.com> wrote:
> > > 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 <daniel.kulp@iona.com> 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
> > > > > daniel.kulp@iona.com
> > > > > http://www.dankulp.com/blog
> > > > >
> > > > > --------------------------------------------------------------
> > > > >------ - To unsubscribe, e-mail:
> > > > > general-unsubscribe@incubator.apache.org For additional
> > > > > commands, e-mail: general-help@incubator.apache.org
> > >
> > > --
> > > J. Daniel Kulp
> > > Principal Engineer
> > > IONA
> > > P: 781-902-8727    C: 508-380-7194
> > > daniel.kulp@iona.com
> > > http://www.dankulp.com/blog
> > >
> > > ------------------------------------------------------------------
> > >--- To unsubscribe, e-mail:
> > > general-unsubscribe@incubator.apache.org For additional commands,
> > > e-mail: general-help@incubator.apache.org
> >
> > --
> > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services
> > Developers

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message