The problem I have with using the IvyContext to pass data around is that we shouldn't populate it with data in extensible code, like resolvers. The reason is that it becomes very difficult for people who are writing their own resolver to know which data has to be set on the IvyContext. And if they forget it, they will probably get strange exceptions making it difficult to find out where it goes wrong.
Maarten ----- Original Message ---- From: Xavier Hanin <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, November 28, 2007 2:34:29 AM Subject: latest compatible conflict manager Hi there, Today I've worked on a new conflict manager, latest compatible conflict manager, which helps to solve problem of compatibilities between modules. I had to make some changes in Ivy resolution engine to handle that, I hope it won't be too troublesome for you to catch up with these changes. The two main changes are the following: - a node can now be blacklisted, to indicate we want to do the resolve process as if it didn't even exist in the repository - RestartResolveProcess (which is actually an Exception) can be thrown during the resolve process to ask to the resolve engine to restart the resolution process I've tried to document how I use these two new features to implement the latest compatible conflict manager in the implementation class itself. Feel free to ask questions if you want details. I've also had to make more use of the IvyContext, adding some stuff in the context like the resolve data or the dependency descriptor currently resolved. This may be the first steps toward putting more context in IvyContext, to decrease the number of parameters we pass away in some situations, ending with a very large number of parameters (especially in resolvers). Moreover during this implementation I've also experimented with the new text representations, and added some tooling which I think can be pretty useful, and it's only the beginning. For example the unit test for the latest compatible conflict manager take advantage of the text representation and end up with tests like this: /* Test data: #A;1-> { #B;1.4 #C;[2.0,2.5] } #B;1.4->#D;1.5 #C;2.5->#D;[1.0,1.6] */ resolveAndAssert("ivy-latest-compatible-1.xml", "#B;1.4, #C;2.5, #D;1.5"); This is pretty easy to read from my point of view, and easy to write too. The assertion parsing the text representation is very productive, but what would be even better would be to able to convert the description of the test data in real test data, so that setting up a test case would be really easy. It'd be kind of a DSL for describing dependencies. Something like: resolveAndAssert("#B;1.4, #C;2.5, #D;1.5", "#A;1-> { #B;1.4 #C;[2.0,2.5] } " + "#B;1.4->#D;1.5 " + "#C;2.5->#D;[1.0,1.6]"); Too bad we don't have text constants spanning multiple lines to make this more readable in Java (Groovy does), but it would already be very nice, no need to maintain and analyze test data in separate repositories anymore... Not sure I'll find time to implement that any time soon, but I just wanted to share this idea with you. Xavier -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/ ____________________________________________________________________________________ Get easy, one-click access to your favorites. Make Yahoo! your homepage. http://www.yahoo.com/r/hs
