[
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
