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
