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? On Fri, Mar 10, 2023 at 6:07 AM Oliver Lietz <[email protected]> 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=+sling-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 <[email protected]> > 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 <[email protected]> > > > > > > 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-2723 > > > > > > > > > > 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=blob;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. > > > > >
