Thanks for the informative reply. I thought I was missing something
on the nearness thing and was hoping for a revelation that made me
excited but alas not. I am glad to see there is action on resolving
this as it could be a pretty major issue with adoption of Maven as
dependencies come and go and randomly downgrade with out a clear
indication that it has happened. We sometimes run for a day or two
before hitting the run time error. I have voted and watched the two
incidents that you pointed me to and in the meantime I will just have
to be more diligent with my dependencies.
I think it might be valuable to include it in the depedency
resolution report that is generated when running reports. Maybe with
a red flag that indicates that the dependency was downgraded. Today
that report is pretty useless for us cause we use a lot of snapshots
before our final release and the report just reports that we are
using snapshots and does nothing else beyond that.
Again thanks for the input and I have my finger crossed it will be
addressed soon.
Scott
On Mar 2, 2007, at 2:56 AM, Mark Hobson wrote:
Hi Scott,
On 02/03/07, Scott Ryan <[EMAIL PROTECTED]> wrote:
Why was the "nearness" process chosen and what does it buy me over
using the most current compatible version out of my entire dependency
list?
Yep, nearness has never made much sense to me either. The proper fix
for the more natural highest-wins strategy is covered in
http://jira.codehaus.org/browse/MNG-612. I hope to allocate some time
to implement this in the not-to-distant future.
How can I insure that I don't get my dependencies randomly downgraded
so that I get runtime errors with no indication until I use the
application?
Dependency management would help you here, although it's broke for
transitive dependencies ;) See
http://jira.codehaus.org/browse/MNG-1577.
Is there a report or process I can use to locate these downgrades so
I can deal with them during build time and not runtime?
Unfortunately, only mvn -X compile currently shows these conflicts.
I've got plans to incorporate this very useful conflict information
into the help:dependencies dependency tree via an optional flag.
Alternatively, a separate dependency:conflicts goal could make more
sense, but nothing is implemented as yet.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Scott Ryan
CTO Soaring Eagle L.L.C.
Denver, Co. 80129
www.soaringeagleco.com
www.theryansplace.com
(303) 263-3044
[EMAIL PROTECTED]
