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
