I moved the new util methods regarding the resource type comparison to a private util class into the resource resolver bundle (in r1771688). The package version change still is necessary IMHO.
@Felix: Regarding backwards compatibility: There were not tests which had to be adjusted for the change, but in fact there is a semantical change. Please look at https://issues.apache.org/jira/browse/SLING-6327 for further details. Konrad > On 28 Nov 2016, at 09:42, Felix Meschberger <[email protected]> wrote: > > Hi Konrad > > Hmm, are these changed semantics backwards compatible ? > > I.e. what do existing callers have to expect ? > > Regards > Felix > >> Am 26.11.2016 um 17:18 schrieb Konrad Windszus <[email protected]>: >> >> Moving the Util methods somewhere else (and even making that Util private) >> is fine with me, but would not change anything about the minor version >> number increase in the o.a.s.resource package. >> With the change in SLING-6327 the behaviour of Resource.isResourceType and >> ResourceResolver.isResourceType has been changed (semantically) and >> therefore requires at least a minor version upgrade to allow consumers to >> specify a minimal version of that package (in case they rely on the new >> semantics of those methods). >> Konrad >> >>> Am 26.11.2016 um 16:17 schrieb Julian Sedding <[email protected]>: >>> >>> Thinking about this some more. I don't think the added method is >>> generally useful for an API user, because the search-paths are >>> normally not available. So I could imagine creating a ResourceTypeUtil >>> class in the resourceresolver project to hold these new methods. We >>> would thus not touch the Sling API and the utility could start out in >>> a private package until we identify other places where we would need >>> it. >>> >>> WDYT? >>> >>> Regards >>> Julian >>> >>> >>> On Fri, Nov 25, 2016 at 6:51 PM, Julian Sedding <[email protected]> wrote: >>>> I think the core problem is that we have provider-type classes and >>>> consumer-type classes mixed in packages of sling.api. Maybe we should >>>> start thinking about how to improve the situation there? >>>> >>>> For now, I think what we normally do is update everything to snapshots >>>> that needs it and then start releasing. >>>> >>>> Alternatively, we could stick with the lower dependency and duplicate >>>> the method you added until we want to update everything to the new >>>> api. >>>> >>>> Regards >>>> Julian >>>> >>>> On Fri, Nov 25, 2016 at 6:34 PM, Konrad Windszus >>>> <[email protected]> wrote: >>>>> With https://issues.apache.org/jira/browse/SLING-6327 I increased the >>>>> minor version of o.a.s.resource from 2.9.0 to 2.10.0 (because of added >>>>> methods to a ResourceUtil). That means that all provider bundles for this >>>>> package (namely o.a.s.jcr.resource and o.a.s.resourceresolver) need to be >>>>> recompiled with an updated dependency to the latest API snapshot, to make >>>>> the latest SNAPSHOTs of all bundles compatible with each other (and >>>>> generate the correct import-package version range in the provider >>>>> bundles). >>>>> What is the suggested approach for doing that? >>>>> Just increase the dependency to the latest API snapshot again in all >>>>> provider bundles for the according packages (although this will be >>>>> prevent those provider bundles from being easily releasable, because API >>>>> would need to be released first) or are there any other suggestions? >>>>> Thanks, >>>>> Konrad >> >
