cleanup Ivy DependencyResolver interface

View: New views
2 Messages — Rating Filter:   Alert me  

cleanup Ivy DependencyResolver interface

by Maarten Coene :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

after my changes to fix IVY-716, the following methods on DependencyResolver are no longer used:

String[] listTokenValues(String token, Map otherTokenValues);
 OrganisationEntry[] listOrganisations();
ModuleEntry[] listModules(OrganisationEntry org);
RevisionEntry[] listRevisions(ModuleEntry module);

Shall I start removing these methods (and all related code), or will we keep them (maybe deprecated) to avoid breaking external code that is using the DependencyResolver interface directly?

Maarten




      ____________________________________________________________________________________
OMG, Sweet deal for Yahoo! users/friends:Get A Month of Blockbuster Total Access, No Cost. W00t
http://tc.deals.yahoo.com/tc/blockbuster/text2.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


Re: cleanup Ivy DependencyResolver interface

by Xavier Hanin :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, Mar 28, 2008 at 11:23 PM, Maarten Coene <maarten_coene@...>
wrote:

> Hi,
>
> after my changes to fix IVY-716, the following methods on
> DependencyResolver are no longer used:
>
> String[] listTokenValues(String token, Map otherTokenValues);
>  OrganisationEntry[] listOrganisations();
> ModuleEntry[] listModules(OrganisationEntry org);
> RevisionEntry[] listRevisions(ModuleEntry module);
>
> Shall I start removing these methods (and all related code), or will we
> keep them (maybe deprecated) to avoid breaking external code that is using
> the DependencyResolver interface directly?

I think 2.0 is a unique opportunity to remove them, so I'd remove them.
Maybe to ease migration we can still keep and deprecate them in resolvers
implementation (AbstractResolver and subclasses), so that people who really
want to use them can still cast their resolver in AbstractResolver.

BTW it seems that some of these methods are still used by
SearchEngine#findModuleRevisionIds(DependencyResolver, ModuleRevisionId,
PatternMatcher), which in turn is not used. I think we should remove this
method too (it has been introduced in 2.0 anyway, so there's no BC contract
at all).

Xavier

>
>
> Maarten
>
>
>
>
>
>  ____________________________________________________________________________________
> OMG, Sweet deal for Yahoo! users/friends:Get A Month of Blockbuster Total
> Access, No Cost. W00t
> http://tc.deals.yahoo.com/tc/blockbuster/text2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>


--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/