Cool! I've been wanting to do that for a while. I'll take a look.
On 02/09/2007, at 5:14 AM, Jason van Zyl (JIRA) wrote:
[ http://jira.codehaus.org/browse/MARTIFACT-3?
page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason van Zyl closed MARTIFACT-3.
---------------------------------
Resolution: Fixed
First pass implemented.
Remove the fail-fast behavior in the core as it makes providing
useful client feedback to correct problems
---------------------------------------------------------------------
-------------------------------------
Key: MARTIFACT-3
URL: http://jira.codehaus.org/browse/MARTIFACT-3
Project: Maven Artifact
Issue Type: Improvement
Affects Versions: 3.0-alpha-1
Reporter: Jason van Zyl
Assignee: Jason van Zyl
Fix For: 3.0-alpha-1
The second part was to collect absolutely everything that can
possibly go wrong during the resolution and collect all exceptions
instead of blowing up when something is missing.
The current behavior has lead to many integrators like Milos to
have to reimplement large parts of the artifact resolution
mechanism because the mechanism is essentially
fail-fast which is pretty much useless in an integrated
environment.
So the ArtifactResolutionResult tries to capture what has gone
wrong and currently this is what I tried to categorize:
- metadata missing
- metadata retrieval problems
- version range violation
- circular dependencies
- artifacts missing
- artifact retrieval problems
These are the primary set of problems (there may be more, but
this is a first pass) and there is no reason we can't tell the
user exactly what went wrong. The current
method of spewing out pile of mostly incomprehensible text
(this is based on feedback from many clients I've worked with who
look at the standard out put for missing
artifacts and have a very difficult time understanding what the
actual problem is) is not good. Instead the exact problem should
be determined and by looking at
the ArtifactResolutionResult client code like our CLI or more
importantly in IDE integration we can very much help the user.
So the code now goes as far as it possibly can to find all
problems and is exposed via this one method that uses a request.
All existing methods I have preserved and
I wrapped new code in the old signatures and throw exceptions
prematurely to mimic the old behavior. Nothing changes for most of
the code. All these changes are
currently only used by the project builder and ultimately the
embedder.buildWithDependencies() method that needs to know
everything that went wrong in order to
provide useful information.
Milos, Vlad, Eugene, you should soon be able to use this code
instead of your local modifications. The one thing that needs to
be added is method for mixing in local
reactor dependencies so that within an IDE projects can be
resolved from the module list in IDEA, the workspace in Eclipse,
and the workspace in Netbeans. I made
every attempt to be backward compatible but jardiff/clirr will
be the arbiter of that.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/
software/jira
--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
