Re: [Proposal] fix http.getFileList()

2008-05-28 Thread Brett Porter
Joakim? Down to just 5 open issues (and I'm considering moving some of them out), so if you want to get this in, now would be the time :) - Brett On 20/05/2008, at 8:30 AM, Brett Porter wrote: Any thoughts with moving forward with this Joakim? - Brett On 14/04/2008, at 9:42 AM, Brett

Re: dependency version conflict resolution

2008-05-28 Thread Gilles Scokart
There are actually plenty of conflict resolution strategy. Every users may preffer its own style based on the characteristics of its project, depending on what level of control he want to have versus the effort he want to give, depending of the size of its project, depending on the typical

integration test failures in 2.0.9 / 2.0.x

2008-05-28 Thread Brett Porter
Hi, I'm getting these failing on 2.0.9 and 2.0.10-SNAPSHOT - anyone else seen the problem? Clean repo, nothing in the settings. Tests in error: testitMNG3221a (org.apache.maven.integrationtests.MavenITmng3221InfiniteForking) testitMNG2861

Re: dependency version conflict resolution

2008-05-28 Thread Paul Gier
Not much to add other than I agree. I think maven should take an approach similar to Ivy. Allow users to choose from some common conflict resolution strategies, or implement their own if none of the standard ones meet their needs. Gilles Scokart wrote: There are actually plenty of conflict

Re: dependency version conflict resolution

2008-05-28 Thread Michael McCallum
I concur with John, The key problem with plugable conflict resolution is that in my case I use hundreds of open source artifacts that all have interdepdencies that work based on the current maven conflict resolution model... If you make it pluggable where do you start and end with any

RE: integration test failures in 2.0.9 / 2.0.x

2008-05-28 Thread Brian E. Fox
These are the failures I'm getting: Failed tests: testDeactivateDefaultProfilesDash(org.apache.maven.integrationtests.Mave nITmng3545ProfileDeactivation) testDeactivateDefaultProfilesExclamation(org.apache.maven.integrationtes ts.MavenITmng3545ProfileDeactivation )

RE: dependency version conflict resolution

2008-05-28 Thread Brian E. Fox
My concern is the same, but I'll take it a step further. Custom conflict resolution strategies reduce the overall ability to jump in and understand any Maven build. -Original Message- From: Michael McCallum [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2008 9:45 AM To: Maven

Re: dependency version conflict resolution

2008-05-28 Thread Mark Hobson
Ideally conflict resolvers would be local to a project, so that they wouldn't have an impact on transitive dependencies. This would be something for the maven-artifact graph-based rewrite, I certainly wouldn't like to patch the current event-based version to achieve this! Mark 2008/5/28 Brian

RE: dependency version conflict resolution

2008-05-28 Thread Brian E. Fox
How can it not affect transitive dependencies? It is in fact the transitives that cause the conflicts in the first place. -Original Message- From: Mark Hobson [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2008 10:45 AM To: Maven Developers List Subject: Re: dependency version

Re: dependency version conflict resolution

2008-05-28 Thread Mark Hobson
I meant that if your project declared a different conflict resolver, then it wouldn't necessarily be used when resolving its dependencies' conflicts. For example, if Hibernate's pom declared nearest-wins, but your project that depended upon Hibernate declared highest-wins, then nearest-wins would

Re: dependency version conflict resolution

2008-05-28 Thread Gilles Scokart
For the record, note that I didn't argue that maven should do the same than ivy. Ivy has a general philosophy of flexibility. Maven has a philosophy of promoting good practices. I guess that both should be consistent with their general pholosophy... But I didn't answered to the question Is it

Re: dependency version conflict resolution

2008-05-28 Thread John Williams
Sorry about the tangent, but has any work been done yet for graph-based dependency resolution? If I find the time to work on Maven that's the first thing I'd want to work on. Aside from being able to implement conflict resolution strategies more easily, I think a graph-based approach could have

Re: dependency version conflict resolution

2008-05-28 Thread Jason van Zyl
On 28-May-08, at 8:58 AM, John Williams wrote: Sorry about the tangent, but has any work been done yet for graph-based dependency resolution? Yes, the first iteration of it has been in the maven-artifact trunk for quite some time. Oleg Gusakov worked on the first iteration. This has

Re: integration test failures in 2.0.9 / 2.0.x

2008-05-28 Thread Brett Porter
Doesn't the maven version force these to be skipped? Anyway, I'll try another machine and see if those other two tests pass there. - Brett On 28/05/2008, at 11:31 PM, Brian E. Fox wrote: These are the failures I'm getting: Failed tests: testDeactivateDefaultProfilesDash

Re: integration test failures in 2.0.9 / 2.0.x

2008-05-28 Thread Brett Porter
0111 passed on windows, 3221a still fails. John, do you know any more about this? - Brett On 29/05/2008, at 9:02 AM, Brett Porter wrote: Doesn't the maven version force these to be skipped? Anyway, I'll try another machine and see if those other two tests pass there. - Brett On