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
