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. [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. > > >
