Hi Julian, I'm happy to switch to some other technique if oak has some "considered public" way to determine if the current user has been granted the necessary permissions that would be needed in order to create new users. Just let me know what that would be. No one complained about the code changes when they were done nearly 2 years ago.
However, in this use case, I don't see how the dependency and integration could cause any troubles since we are only referencing a few string constants and a service interface class. All of those originate in 2 packages that the oak-core bundle declared as exported packages which to me means those are declared as public and available to use. Also, since all of the classes I referenced have subsequently been moved from oak-core to the oak-security-spi bundle in version 1.8 and later, do you consider them public now? Regards, Eric On Tue, Jul 28, 2020 at 12:29 AM Julian Reschke <[email protected]> wrote: > Am 27.07.2020 um 20:51 schrieb Eric Norman: > > Hi Julian, > > > > In reviewing the history, it looks like the dependency on oak-core was > > first introduced to resolve SLING-7886 and SLING-7887 via the commit at > > [3]. If I recall correctly, that 1.6.x version of oak was the version > that > > was being used in the sling starter (version 10'ish) at the time so I > chose > > that as the minimum version to depend on. As far as I can tell, the code > > being utilized here is still compatible with the latest version of oak so > > there hasn't been any reason to change the minimum version yet. > > > > I suppose we could now change that dependency > > to org.apache.jackrabbit:oak-security-spi instead as long as everyone is > > comfortable with moving the minimum version of oak up to version 1.8 or > > later? > > ... > > AFAIU, nobody should have direct references on oak-core other than other > Oak components. These APIs are not considered public. > > If there's a problem with that, we should fix that in Oak. > > Best regards, Julian >
