We could have this also for mirrors.Another thing we could have in mirror definition is to say if this is for releases, snapshots or both.
Arnaud On Thu, Jul 9, 2009 at 4:13 PM, Daniel Kulp <dk...@apache.org> wrote: > > I've long thought that the <repository> entry in the poms (or wherever it > moves to) and mirrors in settings.xml should have some sort of "filters" on > it. Like: > <repository> > <id>java.net</id> > <url>http://download.java.net/maven/1/</url> > <includes> > <include>com.sun.*:*</include> > </includes> > <excludes> > <exclude>javax.xml.*:*</exclude> > </excludes> > </repository> > > That would allow limiting searches there to very specific artifacts. > Currently, if I have that repository configured, it ALWAYS searches there > for > things like "org.apache" stuff and other things that I KNOW are not there. > That slows down the build, increases net traffic, and adds a BUNCH of 404 > errors in their httpd logs. > > Dan > > > On Thu July 9 2009 10:03:41 am Stan Devitt wrote: > > Here is some feedback on > > > > http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repositor > > y+discovery > > > > Of the 4 requirements listed: > > > > 1. ability to checkout and build with no prior setup (extremely > > important) > > 3. separate plugin dependency resolution from project dependency > > resolution. > > and > > 4. Use URL's as ids > > > > are clear. However, I have concerns about the requirement > > > > 2. bypass transitive resolution to depend directly on a jar > > > > It is apparently justified by concern over cost of searching a growing > > and unpredictable list of repositories, but I think it misses the real > > problem and is also (I believe) in direct conflict with 1. > > > > The real problem is not the cost, but the "risk" inherent in searching > > additional repositories. > > > > The main risk is that you may have two or more deployments of the same > > artifact and they may not be the same. In fact, this is almost > > guaranteed to happen in the presence of historic jar deployment policies > > forcing every user site to deploy on their own a copy or a rebuilt copy > > of certain artifacts. (At very least the poms will often differ.) > > > > So, the two extremely important missing requirements are: > > > > 5. "If inconsistent deployments of an artifact are encountered (and > > they will be) during the search (pom and/or jar) this must be flagged." > > > > And > > > > 6. "There must be reproducible way of choosing a specific repository > > for an artifact in such circumstances." > > > > Addressing this is hard but very important. Failing on conflict > > discovery is a good start. Attempts to solve it beyond that leads you > > directly into the territory of repository management.(so maybe you defer > > to the proxy/repo manager, or maybe you provide a way to specify an > > artifact specific "preferred repository" in the dependency management > > section ... ) > > > > Preventing the corrupt deployments is even harder. It is political. > > > > Stan > > > > > > > > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain confidential > > information, privileged material (including material protected by the > > solicitor-client or other applicable privileges), or constitute > non-public > > information. Any use of this information by anyone other than the > intended > > recipient is prohibited. If you have received this transmission in error, > > please immediately reply to the sender and delete this information from > > your system. Use, dissemination, distribution, or reproduction of this > > transmission by unintended recipients is not authorized and may be > > unlawful. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
