You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Oliver Lietz <ap...@oliverlietz.de> on 2023/03/09 16:29:55 UTC
[VOTE] Release Apache Sling Commons Permissions 1.0.0
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=check_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.
[VOTE][CANCELED] Release Apache Sling Commons Permissions 1.0.0
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Thursday, 9 March 2023 17:29:55 CEST Oliver Lietz 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
[...]
No consent.
O.
Re: [VOTE] Release Apache Sling Commons Permissions 1.0.0
Posted by Konrad Windszus <kw...@apache.org>.
IIRC Commons is used as name infix for all bundles not having a dependency on other Sling bundles (i.e. are not really Sling-specific)
As long as the only implementation is not fulfilling that requirement (due to https://github.com/apache/sling-org-apache-sling-commons-permissions-sling/blob/a3169947676fe267f47219446e72f9c204591d8a/pom.xml#L210) I agree that we should leave out “Commons” from the name and also add the suffix API, so +1 to the proposal from Eric.
At the same time the implementation should be renamed accordingly as well.
Konrad
> On 9. Mar 2023, at 19:25, Eric Norman <er...@gmail.com> 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?
>
> Regards,
> Eric
>
>
> On Thu, Mar 9, 2023 at 8:30 AM Oliver Lietz <ap...@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=check_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.
>>
>>
>>
>>
>>
Re: [VOTE] Release Apache Sling Commons Permissions 1.0.0
Posted by Oliver Lietz <ap...@oliverlietz.de>.
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?
See SLING-9644 for Sling Pipes and SLING-11254 for Sling Clam which are the
causing issues for SLING-11341.
In 3ab1317² you can see the use case of Commons Permissions and the Sling
implementation in the test configuration for Sling Clam.
> 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.
I guess it's because permissions are required everywhere. The term is also
used by Java Security. The Commons Permissions module could be used outside of
Sling not using Sling/JCR APIs but something else. The README for the Sling
implementation states:
"The Sling Permissions Service maps permissions to JCR items and checks if
given Principal has read access via Session#itemExists($permission)."
The Oak permissions are resource related while Commons Permissions aims at
tasks/actions (see below).
O.
>
> [1] https://jackrabbit.apache.org/oak/docs/security/permission.html
[2] https://github.com/apache/sling-org-apache-sling-clam/commit/
3ab1317b5dc31b14c35e4c5755b98ddeca46253b
> > -----Original Message-----
> > From: Oliver Lietz <ap...@oliverlietz.de>
> > Sent: Friday, June 2, 2023 7:25 PM
> > To: dev@sling.apache.org
> > Cc: Daniel Klco <dk...@apache.org>; kwin@apache.org; Eric Norman
> > <en...@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 <ap...@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
> > > > > <ap...@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
> > > > > > > <ap...@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.
> >
> >
> >
> >
>
>
RE: [VOTE] Release Apache Sling Commons Permissions 1.0.0
Posted by Stefan Seifert <St...@diva-e.com.INVALID>.
ok, thanks for the information, it's fine from my side.
maybe a bit more context could be added to the README to avoid to having to dig this all up in mailing lists.
for a vote you need to restart the voting process because the nexus repo is no longer available.
stefan
> -----Original Message-----
> From: Oliver Lietz <ap...@oliverlietz.de>
> Sent: Sunday, June 18, 2023 10:14 AM
> To: dev@sling.apache.org
> Subject: Re: [VOTE] Release Apache Sling Commons Permissions 1.0.0
>
> 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 <ap...@oliverlietz.de>
> > > Sent: Friday, June 2, 2023 7:25 PM
> > > To: dev@sling.apache.org
> > > Cc: Daniel Klco <dk...@apache.org>; kwin@apache.org; Eric Norman
> > > <en...@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
> > > > <ap...@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-schedul
> > > > > er
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > > > <ap...@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
> > > > > > > > <ap...@oliverlietz.de>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > > Hi,
> > > > >
> > > > >
> > > > >
> > > > > > > > > We solved 2 issue in this release:
> > > > >
> > > > > https://issues.apache.org/jira/browse/SLING/fixforversion/123525
> > > > > 564
> > > > >
> > > > >
> > > > >
> > > > > > > > > This is the initial release of the API module:
> > > > >
> > > > > https://github.com/apache/sling-org-apache-sling-commons-permiss
> > > > > ions
> > > > >
> > > > >
> > > > >
> > > > > > > > > And implementation module can be found here:
> > > > >
> > > > > https://github.com/apache/sling-org-apache-sling-commons-permiss
> > > > > ions
> > > > > -sling
> > > > >
> > > > >
> > > > >
> > > > > > > > > Staging repository:
> > > > >
> > > > > https://repository.apache.org/content/repositories/orgapacheslin
> > > > > g-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.
> > >
> > >
> > >
> > >
> >
> >
>
>
>
Re: [VOTE] Release Apache Sling Commons Permissions 1.0.0
Posted by Oliver Lietz <ap...@oliverlietz.de>.
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 <ap...@oliverlietz.de>
> > Sent: Friday, June 2, 2023 7:25 PM
> > To: dev@sling.apache.org
> > Cc: Daniel Klco <dk...@apache.org>; kwin@apache.org; Eric Norman
> > <en...@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 <ap...@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
> > > > > <ap...@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
> > > > > > > <ap...@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.
> >
> >
> >
> >
>
>
RE: [VOTE] Release Apache Sling Commons Permissions 1.0.0
Posted by Stefan Seifert <St...@diva-e.com.INVALID>.
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 <ap...@oliverlietz.de>
> Sent: Friday, June 2, 2023 7:25 PM
> To: dev@sling.apache.org
> Cc: Daniel Klco <dk...@apache.org>; kwin@apache.org; Eric Norman
> <en...@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 <ap...@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
> > > > <ap...@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
> > > > > > <ap...@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.
>
>
>
Re: [VOTE] Release Apache Sling Commons Permissions 1.0.0
Posted by Oliver Lietz <ap...@oliverlietz.de>.
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 <ap...@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=+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 <ap...@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 <ap...@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.
Re: [VOTE] Release Apache Sling Commons Permissions 1.0.0
Posted by Daniel Klco <dk...@apache.org>.
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 <ap...@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=+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 <ap...@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 <ap...@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.
>
>
>
>
>
Re: [VOTE] Release Apache Sling Commons Permissions 1.0.0
Posted by Oliver Lietz <ap...@oliverlietz.de>.
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 <ap...@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 <ap...@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.
Re: [VOTE] Release Apache Sling Commons Permissions 1.0.0
Posted by Eric Norman <en...@apache.org>.
Hi Oliver,
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.
Regards,
Eric
On Thu, Mar 9, 2023 at 11:46 AM Oliver Lietz <ap...@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 <ap...@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.
>
>
>
>
>
Re: [VOTE] Release Apache Sling Commons Permissions 1.0.0
Posted by Oliver Lietz <ap...@oliverlietz.de>.
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 <ap...@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.
Re: [VOTE] Release Apache Sling Commons Permissions 1.0.0
Posted by Eric Norman <er...@gmail.com>.
+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?
Regards,
Eric
On Thu, Mar 9, 2023 at 8:30 AM Oliver Lietz <ap...@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=check_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.
>
>
>
>
>