[jira] [Created] (SLING-7050) Parser fails with trailing comments

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-7050:
---

 Summary: Parser fails with trailing comments
 Key: SLING-7050
 URL: https://issues.apache.org/jira/browse/SLING-7050
 Project: Sling
  Issue Type: Bug
  Components: Repoinit
Affects Versions: Repoinit Parser 1.1.0
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Repoinit Parser 1.1.2


If the input has a comment as the last line (no CR at the end), the parser 
fails.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128281#comment-16128281
 ] 

Chetan Mehrotra edited comment on SLING-7043 at 8/16/17 4:21 AM:
-

I still do not think that current status is having a problem (but that can be 
just me!). As said earlier. Client code can bind to 

# Sling Commons Metrics API - Get some added benefits and stable package 
version. Majority of code needs would be fullfilled by this api. It also allows 
us to disable metrics collection anytime without affecting the application 
functionality just like logging 
# Dropwizzard Metrics API - Get access MetricRegistry and access to actual 
metrics value

Note that Dropwizzard binds package export to release version and some of the 
exported interfaces are Consumer type. So if code in Sling uses that we need to 
update such bundles when upgrading Metrics bundle (SLING-7047).

Even if we go for option #A above we would still need to export the 
MetricRegistry as services as quite a bit of existing reporters provided by 
Metrics itself work with that service. It does not make sense to wrap all such 
reporters. So access to MetricRegistry by reporter should be fine


was (Author: chetanm):
I still do not think that current status is having a problem (but that can be 
just me!). As said earlier. Client code can bind to 

# Sling Commons Metrics API - Get some added benefits and stable package 
version. Majority of code needs would be fullfilled by this api
# Dropwizzard Metrics API - Get access MetricRegistry and access to actual 
metrics value

Note that Dropwizzard binds package export to release version and some of the 
exported interfaces are Consumer type. So if code in Sling uses that we need to 
update such bundles when upgrading Metrics bundle (SLING-7047).

Even if we go for option #A above we would still need to export the 
MetricRegistry as services as quite a bit of existing reporters provided by 
Metrics itself work with that service. It does not make sense to wrap all such 
reporters. So access to MetricRegistry by reporter should be fine

> Exporting  com.codahale.metrics.MetricRegistry is breaking the abstraction
> --
>
> Key: SLING-7043
> URL: https://issues.apache.org/jira/browse/SLING-7043
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Commons Metrics 1.0.0
>Reporter: Carsten Ziegeler
>Priority: Blocker
> Fix For: commons metrics 1.2.4
>
>
> commons metrics provides a nice abstraction over  com.codahale.metrics - 
> however it is exporting  com.codahale.metrics.MetricRegistry which seems to 
> be the only way to get at registered metrics objects. Which in turn is 
> completely breaking the purpose of this bundle.
> So we should
> a) drop exporting that service and avoid leaking internal implementation 
> details
> b) create our own version of the registry service



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128281#comment-16128281
 ] 

Chetan Mehrotra commented on SLING-7043:


I still do not think that current status is having a problem (but that can be 
just me!). As said earlier. Client code can bind to 

# Sling Commons Metrics API - Get some added benefits and stable package 
version. Majority of code needs would be fullfilled by this api
# Dropwizzard Metrics API - Get access MetricRegistry and access to actual 
metrics value

Note that Dropwizzard binds package export to release version and some of the 
exported interfaces are Consumer type. So if code in Sling uses that we need to 
update such bundles when upgrading Metrics bundle (SLING-7047).

Even if we go for option #A above we would still need to export the 
MetricRegistry as services as quite a bit of existing reporters provided by 
Metrics itself work with that service. It does not make sense to wrap all such 
reporters. So access to MetricRegistry by reporter should be fine

> Exporting  com.codahale.metrics.MetricRegistry is breaking the abstraction
> --
>
> Key: SLING-7043
> URL: https://issues.apache.org/jira/browse/SLING-7043
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Commons Metrics 1.0.0
>Reporter: Carsten Ziegeler
>Priority: Blocker
> Fix For: commons metrics 1.2.4
>
>
> commons metrics provides a nice abstraction over  com.codahale.metrics - 
> however it is exporting  com.codahale.metrics.MetricRegistry which seems to 
> be the only way to get at registered metrics objects. Which in turn is 
> completely breaking the purpose of this bundle.
> So we should
> a) drop exporting that service and avoid leaking internal implementation 
> details
> b) create our own version of the registry service



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-7027) Progress ETA seems to be calculated incorrectly and not to be updated on update.

[Karl Pauls (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Pauls closed SLING-7027.
-

> Progress ETA seems to be calculated incorrectly and not to be updated on 
> update.
> 
>
> Key: SLING-7027
> URL: https://issues.apache.org/jira/browse/SLING-7027
> Project: Sling
>  Issue Type: Bug
>  Components: Event
>Affects Versions: Event 4.2.4
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>Priority: Minor
> Fix For: Event 4.2.6
>
> Attachments: eta.patch
>
>
> It looks to me like the eta is not correctly calculated in 
> JobImpl.setProgress and not set correctly in JobImp.update. 
> I would like to apply the attached patch to fix it. Does that look correct to 
> others?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-6739) split sling.event into event.api and event.resource (was: event.impl)

[Karl Pauls (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Pauls closed SLING-6739.
-

> split sling.event into event.api and event.resource (was: event.impl)
> -
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Event API 1.0.0, Event 4.2.6
>
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event/api
> bundles/extensions/event/resource
> and to remove the current
> bundles/extensions/event



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SLING-7039) Clean up jobs in state dropped and errors

[Karl Pauls (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Pauls closed SLING-7039.
-

> Clean up jobs in state dropped and errors
> -
>
> Key: SLING-7039
> URL: https://issues.apache.org/jira/browse/SLING-7039
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Karl Pauls
> Fix For: Event 4.2.6
>
> Attachments: SLING-7039.patch
>
>
> Currently, whenever a job is removed by a user (or client code), the job is 
> kept as a dropped job - regardless of whether a history should be kept for 
> these types of jobs. The same happens if the job can't be scheduled (error).
> This information is useful for trouble shooting (to find out if a particular 
> job has been created at all or not).
> Now, as the job impl is keeping track of these things, I think it also should 
> be the job impl which cleans this up. The configuration for this would be a 
> time period during which these jobs are kept (like 48h or something). All 
> older jobs are removed.
> Or in other words: the job impl should periodically run the 
> HistoryCleanUpTask to remove jobs in state DROPPED and ERROR which are older 
> than the configured time.
> I think the time would be a global configuration of the job handling, 
> defaulting to 48h



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [RESULT][VOTE] Release Apache Sling Event 4.2.6

[Karl Pauls]

Time to call the vote on the  Apache Sling Event 4.2.6 release.

* +1 votes from Carsten Ziegeler, Robert Munteanu, Daniel Klco, and Karl Pauls.
* +0 vote from Stefan Egli
* No other votes.

The vote is successful. I will make the artifacts available as soon as possible.

Re: [VOTE] Release Apache Sling Event 4.2.6

[Karl Pauls]

On Mon, Aug 14, 2017 at 2:11 PM, Stefan Egli  wrote:
> +0
>
> Note that this also releases SLING-6739 for which the original idea was to
> increase the version to 4.3.0 to stress that internally it embeds and
> re-exports event.api now. But technically I don't see a reason why it
> can't be released as 4.2.6 .. just saying. We can adjust fixversion of
> SLING-6739 accordingly too.

Yes, you are absolutely correct. I should have seen that. Sorry I
missed it (I guess I need a vacation).

Thanks for resolving SLING-6739 - as you say, there isn't really a
need for a minor version increase so solving it this way makes the
most sense.

regards,

Karl

> Cheers,
> Stefan
>
> On 10/08/17 11:59, "Karl Pauls"  wrote:
>
>>I would like to call a vote on the following release,
>>
>>Apache Sling Event 4.2.6
>>
>>We solved 2 issue in this release:
>>https://issues.apache.org/jira/projects/SLING/versions/12341306
>>
>>Staging repository:
>>https://repository.apache.org/content/repositories/orgapachesling-1764/
>>
>>You can use this UNIX script to download the release and verify the
>>signatures:
>>http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>>
>>Usage:
>>sh check_staged_release.sh 1764 /tmp/sling-staging
>>
>>Please vote to approve these releases:
>>
>>  [ ] +1 Approve the releases
>>  [ ]  0 Don't care
>>  [ ] -1 Don't release, because ...
>
>



-- 
Karl Pauls
karlpa...@gmail.com

Re: [VOTE] Release Apache Sling Event 4.2.6

[Karl Pauls]

+1

regards,

Karl

On Wed, Aug 16, 2017 at 12:11 AM, Karl Pauls  wrote:
> On Mon, Aug 14, 2017 at 2:11 PM, Stefan Egli  wrote:
>> +0
>>
>> Note that this also releases SLING-6739 for which the original idea was to
>> increase the version to 4.3.0 to stress that internally it embeds and
>> re-exports event.api now. But technically I don't see a reason why it
>> can't be released as 4.2.6 .. just saying. We can adjust fixversion of
>> SLING-6739 accordingly too.
>
> Yes, you are absolutely correct. I should have seen that. Sorry I
> missed it (I guess I need a vacation).
>
> Thanks for resolving SLING-6739 - as you say, there isn't really a
> need for a minor version increase so solving it this way makes the
> most sense.
>
> regards,
>
> Karl
>
>> Cheers,
>> Stefan
>>
>> On 10/08/17 11:59, "Karl Pauls"  wrote:
>>
>>>I would like to call a vote on the following release,
>>>
>>>Apache Sling Event 4.2.6
>>>
>>>We solved 2 issue in this release:
>>>https://issues.apache.org/jira/projects/SLING/versions/12341306
>>>
>>>Staging repository:
>>>https://repository.apache.org/content/repositories/orgapachesling-1764/
>>>
>>>You can use this UNIX script to download the release and verify the
>>>signatures:
>>>http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>>>
>>>Usage:
>>>sh check_staged_release.sh 1764 /tmp/sling-staging
>>>
>>>Please vote to approve these releases:
>>>
>>>  [ ] +1 Approve the releases
>>>  [ ]  0 Don't care
>>>  [ ] -1 Don't release, because ...
>>
>>
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Assigned] (SLING-6984) Allow to disable service user

[Timothee Maret (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothee Maret reassigned SLING-6984:
-

Assignee: Timothee Maret

> Allow to disable service user
> -
>
> Key: SLING-6984
> URL: https://issues.apache.org/jira/browse/SLING-6984
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.1.0, Repoinit JCR 1.1.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>
> Currently the repoinit module does not support -removing- disabling service 
> users.
> Disbling -Removing- service user is required when one user is no longer 
> needed due to service user sharing among components.
> The syntax could be the one proposed by [~anchela]
> {code}
> disable service user  
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6984) Allow to disable service user

[Timothee Maret (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127382#comment-16127382
 ] 

Timothee Maret commented on SLING-6984:
---

[~anchela] I have updated the description and title. Thanks for your insight!

> Allow to disable service user
> -
>
> Key: SLING-6984
> URL: https://issues.apache.org/jira/browse/SLING-6984
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.1.0, Repoinit JCR 1.1.4
>Reporter: Timothee Maret
>
> Currently the repoinit module does not support -removing- disabling service 
> users.
> Disbling -Removing- service user is required when one user is no longer 
> needed due to service user sharing among components.
> The syntax could be the one proposed by [~anchela]
> {code}
> disable service user  
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-6984) Allow to disable service user

[Timothee Maret (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothee Maret updated SLING-6984:
--
Description: 
Currently the repoinit module does not support -removing- disabling service 
users.
Disbling -Removing- service user is required when one user is no longer needed 
due to service user sharing among components.

The syntax could be the one proposed by [~anchela]
{code}
remove service user 
{code}

  was:
Currently the repoinit module does not support removing service users.
Removing service user is required when one user is no longer needed due to 
service user sharing among components.

The syntax could be
{code}
remove service user 
{code}


> Allow to disable service user
> -
>
> Key: SLING-6984
> URL: https://issues.apache.org/jira/browse/SLING-6984
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.1.0, Repoinit JCR 1.1.4
>Reporter: Timothee Maret
>
> Currently the repoinit module does not support -removing- disabling service 
> users.
> Disbling -Removing- service user is required when one user is no longer 
> needed due to service user sharing among components.
> The syntax could be the one proposed by [~anchela]
> {code}
> remove service user 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-6984) Allow to disable service user

[Timothee Maret (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothee Maret updated SLING-6984:
--
Description: 
Currently the repoinit module does not support -removing- disabling service 
users.
Disbling -Removing- service user is required when one user is no longer needed 
due to service user sharing among components.

The syntax could be the one proposed by [~anchela]
{code}
disable service user  
{code}

  was:
Currently the repoinit module does not support -removing- disabling service 
users.
Disbling -Removing- service user is required when one user is no longer needed 
due to service user sharing among components.

The syntax could be the one proposed by [~anchela]
{code}
remove service user 
{code}


> Allow to disable service user
> -
>
> Key: SLING-6984
> URL: https://issues.apache.org/jira/browse/SLING-6984
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.1.0, Repoinit JCR 1.1.4
>Reporter: Timothee Maret
>
> Currently the repoinit module does not support -removing- disabling service 
> users.
> Disbling -Removing- service user is required when one user is no longer 
> needed due to service user sharing among components.
> The syntax could be the one proposed by [~anchela]
> {code}
> disable service user  
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-6984) Allow to disable service user

[Timothee Maret (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothee Maret updated SLING-6984:
--
Summary: Allow to disable service user  (was: Allow to remove service user)

> Allow to disable service user
> -
>
> Key: SLING-6984
> URL: https://issues.apache.org/jira/browse/SLING-6984
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.1.0, Repoinit JCR 1.1.4
>Reporter: Timothee Maret
>
> Currently the repoinit module does not support removing service users.
> Removing service user is required when one user is no longer needed due to 
> service user sharing among components.
> The syntax could be
> {code}
> remove service user 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (SLING-6984) Allow to remove service user

[angela (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127348#comment-16127348
 ] 

angela edited comment on SLING-6984 at 8/15/17 3:10 PM:


also, there should be the ability to disable a service user with a message... 
for backwards compatibility it is usually preferable to disable users than to 
remove them.
format could be something like 

{code}
disable service user  
{code}

[~marett], would be able to adjust the subject accordingly? thanks


was (Author: anchela):
also, there should be the ability to disable a service user with a message... 
for backwards compatibility it is usually preferable to disable users than to 
remove them.
format could be something like 

{code}
disable service user  
{code}

> Allow to remove service user
> 
>
> Key: SLING-6984
> URL: https://issues.apache.org/jira/browse/SLING-6984
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.1.0, Repoinit JCR 1.1.4
>Reporter: Timothee Maret
>
> Currently the repoinit module does not support removing service users.
> Removing service user is required when one user is no longer needed due to 
> service user sharing among components.
> The syntax could be
> {code}
> remove service user 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (SLING-6984) Allow to remove service user

[angela (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127348#comment-16127348
 ] 

angela edited comment on SLING-6984 at 8/15/17 3:09 PM:


also, there should be the ability to disable a service user with a message... 
for backwards compatibility it is usually preferable to disable users than to 
remove them.
format could be something like 

{code}
disable service user  
{code}


was (Author: anchela):
also, there should be the ability to disable a service user with a message... 
for backwards compatibility it is usually preferable to disable users than to 
remove them.
format could be something like 

disable service user  

> Allow to remove service user
> 
>
> Key: SLING-6984
> URL: https://issues.apache.org/jira/browse/SLING-6984
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.1.0, Repoinit JCR 1.1.4
>Reporter: Timothee Maret
>
> Currently the repoinit module does not support removing service users.
> Removing service user is required when one user is no longer needed due to 
> service user sharing among components.
> The syntax could be
> {code}
> remove service user 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6984) Allow to remove service user

[angela (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127348#comment-16127348
 ] 

angela commented on SLING-6984:
---

also, there should be the ability to disable a service user with a message... 
for backwards compatibility it is usually preferable to disable users than to 
remove them.
format could be something like 

disable service user  

> Allow to remove service user
> 
>
> Key: SLING-6984
> URL: https://issues.apache.org/jira/browse/SLING-6984
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit Parser 1.1.0, Repoinit JCR 1.1.4
>Reporter: Timothee Maret
>
> Currently the repoinit module does not support removing service users.
> Removing service user is required when one user is no longer needed due to 
> service user sharing among components.
> The syntax could be
> {code}
> remove service user 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (SLING-6423) Allow for specifying ACL merge mode (ACHandling) in repoinit

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler reassigned SLING-6423:
---

Assignee: Bertrand Delacretaz

[~bdelacretaz] This seems to be committed, so can we close this issue?

> Allow for specifying ACL merge mode (ACHandling) in repoinit
> 
>
> Key: SLING-6423
> URL: https://issues.apache.org/jira/browse/SLING-6423
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
>Assignee: Bertrand Delacretaz
> Fix For: Repoinit Parser 1.1.2
>
> Attachments: SLING-6423_parser_changes.patch, 
> SLING-6423_testcases.patch, SLING_6423_testcasesV2.patch
>
>
> Repoinit by default just add new ACLs if they are not already present.
> By contract package manager provides various strategies for ACL merging
> Extend repoinit to allow specifying these strategies 
> https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.html#MERGE



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-6423) Allow for specifying ACL merge mode (ACHandling) in repoinit

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-6423:

Fix Version/s: Repoinit Parser 1.1.2

> Allow for specifying ACL merge mode (ACHandling) in repoinit
> 
>
> Key: SLING-6423
> URL: https://issues.apache.org/jira/browse/SLING-6423
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
> Fix For: Repoinit Parser 1.1.2
>
> Attachments: SLING-6423_parser_changes.patch, 
> SLING-6423_testcases.patch, SLING_6423_testcasesV2.patch
>
>
> Repoinit by default just add new ACLs if they are not already present.
> By contract package manager provides various strategies for ACL merging
> Extend repoinit to allow specifying these strategies 
> https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.html#MERGE



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-6422) Allow for specifying oak restrictions with repoinit

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-6422:

Fix Version/s: Repoinit Parser 1.1.2

> Allow for specifying oak restrictions with repoinit
> ---
>
> Key: SLING-6422
> URL: https://issues.apache.org/jira/browse/SLING-6422
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
>Assignee: Bertrand Delacretaz
> Fix For: Repoinit Parser 1.1.2, Repoinit JCR 1.1.6
>
> Attachments: SLING6422ApplyRestrictionsV2.patch, 
> SLING6422ApplyRestrictionsV3.patch, 
> SLING6422_interpretparsedrestrictionclause.patch, SLING-6422.patch
>
>
> Allow for specifying oak restrictions with repoinit. Currently repoinit 
> allows one to ADD remove ACLs but there is no way to specify oak restrictions.
> http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-6739) split sling.event into event.api and event.resource (was: event.impl)

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved SLING-6739.

   Resolution: Fixed
Fix Version/s: (was: Event 4.3.0)
   Event 4.2.6

As [mentioned on the list|http://markmail.org/message/x7dkth3t622xzm4y] the 
original idea was to release this as 4.3.0 but as it was now already released 
as 4.2.6 that is also fine. Whether to use 4.2.6 or 4.3.0 is really more a 
_cosmetic_ question. The minor version bump would have indicated something more 
than just on the patch level to have changed. But we shall leave it at 4.2.6 
for now. Hence adjusted the fix version accordingly.
/cc [~karlpauls]

> split sling.event into event.api and event.resource (was: event.impl)
> -
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Event API 1.0.0, Event 4.2.6
>
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event/api
> bundles/extensions/event/resource
> and to remove the current
> bundles/extensions/event



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)