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
