I agree, the IvyContext make it more difficult to debug. I agree that the huge amount of parameter is often a problem, but passing all the values it via a single object in Thread context make it more difficult to know which value is available and which value must be made available for the code we are calling.
I see to alternative aproach to reduce the amount of parameter. The first one consist in replacing every list of parameter by an interface and pass them explicetely. You can still have a single object (~ the ivy context) storing all these contextual information. But by using the interface in our code we will more explicitley express what is required. An other alternative is to use more command like object in which we create the instance, set all the parameter of the operation using setter methods and then invoke the real method. But concerning you idea to inline the dependency descriptor into the code : GREAT IDEA ! Gilles 2007/11/28, Maarten Coene <[EMAIL PROTECTED]>: > > 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 > -- Gilles Scokart
