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 >
