Indeed, you make a very good point. On the other hand some context
information like ResolveData for instance can be useful in multiple places,
but passing it around in parameters is cluttering the code. If I take the
example of the findResource method in AbstractResourceResolver, here is one
of its call hierarchy:
findResource(ResolvedResource[], String, LatestStrategy, VersionMatcher,
ResourceMDParser, ModuleRevisionId, Date) -
org.apache.ivy.plugins.resolver.AbstractResourceResolver
findDynamicResourceUsingPattern(String, Repository, LatestStrategy,
VersionMatcher, ResourceMDParser, ModuleRevisionId, String, Artifact, Date)
- org.apache.ivy.plugins.resolver.RepositoryResolver
findResourceUsingPattern(String, Repository, LatestStrategy,
VersionMatcher, ResourceMDParser, ModuleRevisionId, String, Artifact, Date,
boolean) - org.apache.ivy.plugins.resolver.RepositoryResolver (2 matches)
findResourceUsingPattern(ModuleRevisionId, String, Artifact,
ResourceMDParser, Date) - org.apache.ivy.plugins.resolver.RepositoryResolver
findResourceUsingPatterns(ModuleRevisionId, List, Artifact,
ResourceMDParser, Date) -
org.apache.ivy.plugins.resolver.AbstractResourceResolver
findIvyFileRef(DependencyDescriptor, ResolveData) -
org.apache.ivy.plugins.resolver.AbstractResourceResolver
getDependency(DependencyDescriptor, ResolveData) -
org.apache.ivy.plugins.resolver.BasicResolver
We need the resolve data in findResource, how should we pass it from the
getDependency method? For other parameters before having the IvyContext we
passed them all way long (like ResourceMDParser), cluttering the code and
the parameters. This is not a solution IMO. An alternative as Gilles
suggests is to group the contextual information in one object, and pass this
object around all methods. Then whenever we need a new contextual
information, all we need to do is add a new attribute to the object with
corresponding getters and setters. ResolveData itself has been introduced
for this kind of thing. Maybe we should put more details in it, I don't
know. What I like with using IvyContext is that any class involved in the
resolve process, no matter how deep it is involved, can access very useful
contextual data like ResolveData. But maybe a solution would be to keep
contextual data we put in IvyContext limited and properly documented, to
explain when some data should be set, when it is available, and maybe group
contextual information by concerns: like having a ResolveContext for
instance.
WDYT?
Xavier
On Nov 28, 2007 8:22 AM, Maarten Coene <[EMAIL PROTECTED]> wrote:
> 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
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
