On Thursday, 15 June 2023 16:25:47 CEST Stefan Seifert wrote: > it's also difficult for me to validate the release (and it seems the staging > repo is no longer available). > i'm missing a bit context here, and the READMEs in the two repos and the > related tickets SLING-11341, SLING-11688 do not contain much content. can > you give an outline of the planed use case for this tiny API? and the > implementation? > the term "permission" is already used in JCR/oak context [1], but obviously > your are targeting at a different type of permission although also to be > managed by nodes in the repository if the "sling" implementation is used. > still this can be confusing for the users and should be described in the > documentation or readme. See also the discussion "[security] new use case for a checkPermission API" from August 2020:
https://lists.apache.org/thread/h61q4d8r2cdmo49q4npnt5rmcl4zxc29 O. > > [1] https://jackrabbit.apache.org/oak/docs/security/permission.html > > > > > -----Original Message----- > > From: Oliver Lietz <apa...@oliverlietz.de> > > Sent: Friday, June 2, 2023 7:25 PM > > To: dev@sling.apache.org > > Cc: Daniel Klco <dk...@apache.org>; k...@apache.org; Eric Norman > > <enor...@apache.org> > > Subject: Re: [VOTE] Release Apache Sling Commons Permissions 1.0.0 > > > > On Saturday, 11 March 2023 18:56:36 CEST Daniel Klco wrote: > > > > > Beyond the name, I am struggling to understand the value of this > > > module. It seems like a lot of extra effort and artifacts to have two > > > additional modules to perform what is essentially a Resource > > > permissions > > > > check. > > > > > Especially considering that it seems (at least from what I see in the > > > tickets) the only consumer is Sling Pipes. > > > > > > > > > > > > Is there something I'm missing? > > > > > > Most probably. What is wrong with the name? > > > > Two dedicated modules: One contains the API and could be extended later > > by > > support classes (therefore it's not named Permissions *API*) and the > > other > > contains an implementation using Sling and JCR APIs. > > The clean separation makes it unnecessary to deal with optional > > dependencies and optional package imports. > > > > Sling Pipes, Sling Clam and its successor are (possible) consumers. > > > > The single module Commons Crypto on the other hand contains API, support > > classes and an implementation with no intent for a further > > implementation. > > But the package layout and module name allow a later split without > > breaking changes. > > > > So please vote +1 to unblock further development. > > > > Thanks, > > O. > > > > > > > > > On Fri, Mar 10, 2023 at 6:07 AM Oliver Lietz <apa...@oliverlietz.de> > > > > wrote: > > > > > > On Friday, 10 March 2023 02:01:31 CET Eric Norman wrote: > > > > > > > > > Hi Oliver, > > > > > > > > > > > > > > > > Hi Eric, > > > > > > > > > > > > > > > > > Ok, if you think it is likely that there would be non-sling > > > > > > > > > > > > > > > > implementations > > > > > > > > > > > > > > > > > then I won't complain further if "Commons" is left there. But to > > > > > me that is the least relevant part of the artifact name and it is > > > > > right at the beginning. I would probably just include a "commons" > > > > > segment somewhere > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > the groupId if it is not exclusive to sling, but if that has > > > > > already been decided I don't intend to argue any further. > > > > > > > > > > > > > > > > The o.a.s.commons pattern was established very early in the project. > > > > See the list of old and new modules here: > > > > > > > > > > > > > > > > > > > > https://github.com/orgs/apache/repositories?language=&page=1&q=+slin > > > > g-org-> > apache-sling-commons&sort=&type=all > > > > > > > > > > > > > > > > And as example Commons Scheduler from 2009: > > > > https://github.com/apache/sling-org-apache-sling-commons-scheduler > > > > > > > > > > > > > > > > I cannot promise an open source module in our Sling project which > > > > provides a non-Sling implementation. > > > > AEM is the only system in our landscape which works with resource > > > > permissions. > > > > Most (all?) other systems are task/action-based and connect to a > > > > customized proprietary IAM/ARM solution. So it will be most probably > > > > a closed source custom module. > > > > > > > > > > > > > > > > O. > > > > > > > > > > > > > > > > > Regards, > > > > > Eric > > > > > > > > > > > > > > > > > > > > On Thu, Mar 9, 2023 at 11:46 AM Oliver Lietz > > > > > <apa...@oliverlietz.de> > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > On Thursday, 9 March 2023 19:25:37 CET Eric Norman wrote: > > > > > > > > > > > > > +0 for me. I don't have any blocking objections to this, just > > > > > > > +some > > > > > > > nitpicks about the name. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Does adding the "Commons" prefix to the name add any value > > > > > > > here? If > > > > > > > > > > > > > > > > I > > > > > > > > > > > > > > > > > > > understand the approach correctly, then another bundle will > > > > > > > contain a JCR (and/or Resource) specific implementation of the > > > > > > > interface. Since > > > > > > > > > > > > > > > > this > > > > > > > > > > > > > > > > > > > artifact appears to be just the service interface, perhaps > > > > > > > "Apache > > > > > > > > > > > > > > > > Sling > > > > > > > > > > > > > > > > > > > Permissions API" would be a more descriptive name for what is > > > > > > > in > > > > > > > > > > > > > > > > there? > > > > > > > > > > > > > > > > > > Commons (org.apache.sling.commons.) indicates that a module does > > > > > > not depend on Apache Sling. > > > > > > An implementation could get the permissions information from > > > > > > anywhere, also not depending on Sling. > > > > > > > > > > > > > > > > > > > > > > > > O. > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > Eric > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 9, 2023 at 8:30 AM Oliver Lietz > > > > > > > <apa...@oliverlietz.de> > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > We solved 2 issue in this release: > > > > > > > > https://issues.apache.org/jira/browse/SLING/fixforversion/123525564 > > > > > > > > > > > > > > > > > > > > This is the initial release of the API module: > > > > > > > > https://github.com/apache/sling-org-apache-sling-commons-permissions > > > > > > > > > > > > > > > > > > > > And implementation module can be found here: > > > > > > > > https://github.com/apache/sling-org-apache-sling-commons-permissions > > > > -sling > > > > > > > > > > > > > > > > > > > > Staging repository: > > > > > > > > https://repository.apache.org/content/repositories/orgapachesling-27 > > > > 23 > > > > > > > > > > > > > > > > > > > > You can use this UNIX script to download the release and > > > > > > > > verify the > > > > > > > > > > > > > > > > > > > > signatures: > > > > > > > > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=bl > > > > ob;f=c > > > > > > > > > > > > > > > > > > > > heck_staged_release.sh;hb=HEAD > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usage: > > > > > > > > sh check_staged_release.sh 2723 /tmp/sling-staging > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please vote to approve this release: > > > > > > > > > > > > > > > > [ ] +1 Approve the release > > > > > > > > [ ] 0 Don't care > > > > > > > > [ ] -1 Don't release, because ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This majority vote is open for at least 72 hours. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > O. > > > > > > > > > >
