ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jaikiran <>
Subject [GitHub] ant-ivy issue #57: fix last inconsistencies in generics
Date Wed, 02 Aug 2017 06:49:56 GMT
Github user jaikiran commented on the issue:
    Hi Gintas,
    To be clear - what I meant/proposed in the dev list was:
     - It's fine to have all the changes related to introducing that new method with Java
generics on the implementation classes, including the `AbstractResolver`. No objections to
     - However, I think we shouldn't yet introduce it on the `DependencyResolver` interface
in this release. 
     - Finally, as you note in the latest comment, we would need to do a type check in our
(internal) classes where we use the `DependencyResolver` interface's `listTokenValues` method
to see if it's of type `AbstractResolver` and if it is, then invoke the new generic method.
Else invoke the older method. We don't need to do a reflection check to see whether the resolver
has the generic listTokenValues method, since the other existing method should just function
as normal. So ultimately something like:
        if (resolver instanceof AbstractResolver) {
           Set<Map<String, String>> tokenVals = resolver.listTokenValues(...)
// the new generic method
        } else {
           // call the method that's exposed via the DependencyResolver interface - the one
which doesn't use generics
          Map<String, String>[] tokenVals = resolver.listTokenValues(...);
    In short, in this release, don't expose this as a new API on the interface but expose
it on the `AbstractResolver` with an internal implementation that will trickle down to all
external resolvers that extend the `AbstractResolver`. 
    Again, I'm being a bit extra cautious on this specific interface unlike some other interface/class
changes that we have been doing since this one acts as the central well known contract to
the developers who have extended Ivy. Plus the fact that we do have a way to do all the changes
being proposed in this PR without having to force the implementations of the DependencyResolver
to implement that new method in this specific release.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message