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