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
             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

        

Reply via email to