Re: [VOTE] Release Sling Hypermedia API client-side tools 1.0.0 - take TWO

[Andrei Dulvac]

Thanks Everyone.
We have 5 +1's. Could someone in the PMC finalize the release?

- Andrei


On Tue, Aug 16, 2016 at 11:50 PM Karl Pauls  wrote:

> +1
>
> regards,
>
> Karl
>
> On Fri, Aug 12, 2016 at 11:02 AM, Andrei Dulvac  wrote:
>
> > Hi,
> >
> > We solved 3 issues for this initial
> > release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12337959
> > Staging repository:
> >
> > https://repository.apache.org/content/repositories/orgapachesling-1499/
> >
> > 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 1499 /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.
> >
> > Thanks,
> > - Andrei
> >
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>

RE: Build failed in Jenkins: sling-trunk-1.8 #3788

[Stefan Seifert]

updated to maven-jar-plugin 3.0.2 in the sling-mock project in rev. 1756581  
let's see if this helps on jenkins.

stefan

>-Original Message-
>From: Konrad Windszus [mailto:konra...@gmx.de]
>Sent: Wednesday, August 17, 2016 8:55 AM
>To: dev@sling.apache.org
>Subject: Re: Build failed in Jenkins: sling-trunk-1.8 #3788
>
>Probably it is related to https://issues.apache.org/jira/browse/MJAR-227
> and
>https://github.com/codehaus-plexus/plexus-archiver/issues/5
> which is only
>fixed with maven-jar-plugin 3.0.0.
>Try if upgrading to 3.0.1 helps in your case.
>Konrad
>
>> On 17 Aug 2016, at 08:43, Stefan Seifert  wrote:
>>
>>
>>> [INFO] Apache Sling Testing Sling Mock  FAILURE [
>>> 54.843 s]
>> ...
>>> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-
>>> plugin:3.0.0:test-jar (default) on project
>org.apache.sling.testing.sling-
>>> mock: Error assembling JAR: Problem creating jar: Execution exception:
>Java
>>> heap space -> [Help 1]
>>
>>
>> hmm... this happens since i updated to sling parent pom 28 yesterday on
>this project.
>>
>> can anyone reproduce this heap space problem on building locally? (i
>cannot currently)
>>
>> is 512MB heap space not engough for the maven build?
>>
>> stefan

[jira] [Updated] (SLING-5888) Health Check for detecting not-installed configurations/bundles from the OSGi installer

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5888:
---
Description: 
We faced an issue in the past that configurations (or bundles) being deployed 
in the repository are not effective (i.e. not installed in Apache Felix).

The reason for that is that the OSGi configuration was either manually modified 
in the Web Console (and therefore takes precedence over the version of the 
configuration being deployed in the repository) or in case of bundles, that the 
same bundle has already been deployed in that or a newer version (manually or 
through some other path in the repository/filesystem).

Both states may lead to issues at run time, so it would be good to have an 
automated check for it.

  was:
We faced an issue in the past that configurations (or bundles) being deployed 
in the repository are not effective (i.e. not installed in Apache Felix).

The reason for that is that the OSGi configuration was either manually modified 
in the Web Console (and therefore takes precedence over the version of the 
configuration being deployed in the repository) or in case of bundles, that the 
same bundle has already been deployed in that or a newer version (manually or 
through some other path in the repository).

Both states may lead to issues at run time, so it would be good to have an 
automated check for it.


> Health Check for detecting not-installed configurations/bundles from the OSGi 
> installer
> ---
>
> Key: SLING-5888
> URL: https://issues.apache.org/jira/browse/SLING-5888
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check, Installer
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Attachments: SLING-5888-v01.patch
>
>
> We faced an issue in the past that configurations (or bundles) being deployed 
> in the repository are not effective (i.e. not installed in Apache Felix).
> The reason for that is that the OSGi configuration was either manually 
> modified in the Web Console (and therefore takes precedence over the version 
> of the configuration being deployed in the repository) or in case of bundles, 
> that the same bundle has already been deployed in that or a newer version 
> (manually or through some other path in the repository/filesystem).
> Both states may lead to issues at run time, so it would be good to have an 
> automated check for it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Input on https://issues.apache.org/jira/browse/SLING-5888

[Konrad Windszus]

Hi,
in https://issues.apache.org/jira/browse/SLING-5888 I came up with a new 
healthcheck for the OSGi installer. I would appreciate if you could take a look 
at the comments in 
https://issues.apache.org/jira/browse/SLING-5888?focusedCommentId=15389655&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15389655
 as well as at the patch itself and share your opinion.
Thanks in advance,
Konrad

[jira] [Commented] (SLING-5888) Health Check for detecting not-installed configurations/bundles from the OSGi installer

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5888:


I much prefer keeping {{hc}} as the well known abbreviation for {{healthcheck}} 
if that works for you.

Could you briefly explain here (or on our dev list) the logic of your health 
check? I could read the code but I think it's good to collectively validate the 
logic, and we can reuse those explanations later to document the bundle.

> Health Check for detecting not-installed configurations/bundles from the OSGi 
> installer
> ---
>
> Key: SLING-5888
> URL: https://issues.apache.org/jira/browse/SLING-5888
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check, Installer
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Attachments: SLING-5888-v01.patch
>
>
> We faced an issue in the past that configurations (or bundles) being deployed 
> in the repository are not effective (i.e. not installed in Apache Felix).
> The reason for that is that the OSGi configuration was either manually 
> modified in the Web Console (and therefore takes precedence over the version 
> of the configuration being deployed in the repository) or in case of bundles, 
> that the same bundle has already been deployed in that or a newer version 
> (manually or through some other path in the repository/filesystem).
> Both states may lead to issues at run time, so it would be good to have an 
> automated check for it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5888) Health Check for detecting not-installed configurations/bundles from the OSGi installer

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5888:


The logic of the attached patch is as follows:
# It lists all the processed resources of the OSGi installer. 
# If the resource's location starts with one of the given prefixes (only 
{{jcrinstall:/apps}}) by default it will check if the given resource was 
successfully installed. 
# If that is not the case and there is no other resource matching the prefix in 
the same resource group which was successfully installed it makes the health 
check emit a warning.

As far as I understood the healthcheck will only fail in case
# there is another bundle with the same symbolic name provided by some other 
provider (not the JCR Installer from /apps) with higher priority or with a 
newer version. This is also triggered in case the bundle was uploaded manually 
through the web console.
# there is another configuration with the same PID provided by some other 
provider (not the JCR Installer from /apps) with higher priority. This is also 
triggered in case the configuration was manually overwritten in the Felix Web 
Console.

> Health Check for detecting not-installed configurations/bundles from the OSGi 
> installer
> ---
>
> Key: SLING-5888
> URL: https://issues.apache.org/jira/browse/SLING-5888
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check, Installer
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Attachments: SLING-5888-v01.patch
>
>
> We faced an issue in the past that configurations (or bundles) being deployed 
> in the repository are not effective (i.e. not installed in Apache Felix).
> The reason for that is that the OSGi configuration was either manually 
> modified in the Web Console (and therefore takes precedence over the version 
> of the configuration being deployed in the repository) or in case of bundles, 
> that the same bundle has already been deployed in that or a newer version 
> (manually or through some other path in the repository/filesystem).
> Both states may lead to issues at run time, so it would be good to have an 
> automated check for it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-5888) Health Check for detecting not-installed configurations/bundles from the OSGi installer

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-5888 at 8/17/16 8:01 AM:
-

The logic of the attached patch is as follows:
# It lists all the processed resources of the OSGi installer. 
# If the resource's location starts with one of the given prefixes 
({{jcrinstall:/apps}} by default) it will check if the given resource was 
successfully installed. 
# If that is not the case and there is no other resource matching the prefix in 
the same resource group which was successfully installed it makes the health 
check emit a warning.

As far as I understood the healthcheck will only fail in case
# there is another bundle with the same symbolic name provided by some other 
provider (not the JCR Installer from /apps) with higher priority or with a 
newer version. This is also triggered in case the bundle was uploaded manually 
through the web console.
# there is another configuration with the same PID provided by some other 
provider (not the JCR Installer from /apps) with higher priority. This is also 
triggered in case the configuration was manually overwritten in the Felix Web 
Console.


was (Author: kwin):
The logic of the attached patch is as follows:
# It lists all the processed resources of the OSGi installer. 
# If the resource's location starts with one of the given prefixes (only 
{{jcrinstall:/apps}}) by default it will check if the given resource was 
successfully installed. 
# If that is not the case and there is no other resource matching the prefix in 
the same resource group which was successfully installed it makes the health 
check emit a warning.

As far as I understood the healthcheck will only fail in case
# there is another bundle with the same symbolic name provided by some other 
provider (not the JCR Installer from /apps) with higher priority or with a 
newer version. This is also triggered in case the bundle was uploaded manually 
through the web console.
# there is another configuration with the same PID provided by some other 
provider (not the JCR Installer from /apps) with higher priority. This is also 
triggered in case the configuration was manually overwritten in the Felix Web 
Console.

> Health Check for detecting not-installed configurations/bundles from the OSGi 
> installer
> ---
>
> Key: SLING-5888
> URL: https://issues.apache.org/jira/browse/SLING-5888
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check, Installer
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Attachments: SLING-5888-v01.patch
>
>
> We faced an issue in the past that configurations (or bundles) being deployed 
> in the repository are not effective (i.e. not installed in Apache Felix).
> The reason for that is that the OSGi configuration was either manually 
> modified in the Web Console (and therefore takes precedence over the version 
> of the configuration being deployed in the repository) or in case of bundles, 
> that the same bundle has already been deployed in that or a newer version 
> (manually or through some other path in the repository/filesystem).
> Both states may lead to issues at run time, so it would be good to have an 
> automated check for it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5888) Health Check for detecting not-installed configurations/bundles from the OSGi installer

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5888:


Thanks for your quick reply - how do you check that the given resource was 
successfully installed for configs, especially for the ones that use config 
factories?

I think good log messages are key to understanding what the HC does, maybe the 
failed HC result should be something like "the resource FOO does not seem to be 
successfully installed because there is no config with PID xyz...".

> Health Check for detecting not-installed configurations/bundles from the OSGi 
> installer
> ---
>
> Key: SLING-5888
> URL: https://issues.apache.org/jira/browse/SLING-5888
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check, Installer
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Attachments: SLING-5888-v01.patch
>
>
> We faced an issue in the past that configurations (or bundles) being deployed 
> in the repository are not effective (i.e. not installed in Apache Felix).
> The reason for that is that the OSGi configuration was either manually 
> modified in the Web Console (and therefore takes precedence over the version 
> of the configuration being deployed in the repository) or in case of bundles, 
> that the same bundle has already been deployed in that or a newer version 
> (manually or through some other path in the repository/filesystem).
> Both states may lead to issues at run time, so it would be good to have an 
> automated check for it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5888) Health Check for detecting not-installed configurations/bundles from the OSGi installer

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-5888:


The check is the same for bundles and configs. It will evaluate 
{{resource.getState()}}.
Both {{ResourceState.IGNORED}} and {{ResourceState.INSTALL}} mean that this 
resource was not installed successfully.

> Health Check for detecting not-installed configurations/bundles from the OSGi 
> installer
> ---
>
> Key: SLING-5888
> URL: https://issues.apache.org/jira/browse/SLING-5888
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check, Installer
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Attachments: SLING-5888-v01.patch
>
>
> We faced an issue in the past that configurations (or bundles) being deployed 
> in the repository are not effective (i.e. not installed in Apache Felix).
> The reason for that is that the OSGi configuration was either manually 
> modified in the Web Console (and therefore takes precedence over the version 
> of the configuration being deployed in the repository) or in case of bundles, 
> that the same bundle has already been deployed in that or a newer version 
> (manually or through some other path in the repository/filesystem).
> Both states may lead to issues at run time, so it would be good to have an 
> automated check for it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5888) Health Check for detecting not-installed configurations/bundles from the OSGi installer

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5888:


Ah ok got it, you're checking that the installer thinks the resource is 
installed - I had something more complex in mind, that would probably not work 
;-)

> Health Check for detecting not-installed configurations/bundles from the OSGi 
> installer
> ---
>
> Key: SLING-5888
> URL: https://issues.apache.org/jira/browse/SLING-5888
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check, Installer
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Attachments: SLING-5888-v01.patch
>
>
> We faced an issue in the past that configurations (or bundles) being deployed 
> in the repository are not effective (i.e. not installed in Apache Felix).
> The reason for that is that the OSGi configuration was either manually 
> modified in the Web Console (and therefore takes precedence over the version 
> of the configuration being deployed in the repository) or in case of bundles, 
> that the same bundle has already been deployed in that or a newer version 
> (manually or through some other path in the repository/filesystem).
> Both states may lead to issues at run time, so it would be good to have an 
> automated check for it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5888) Health Check for detecting not-installed configurations/bundles from the OSGi installer

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5888:


Now that I understand the principle better, I think the messages sent to the HC 
log should more directly expose the installer state, so that someone 
troubleshooting their instance becomes more familiar with how the installer 
works and to help make the whole thing more transparent.

For example instead of saying "The OSGi bundle for '{}' was not installed" I'd 
prefer "The installer state of the OSGi bundle resource {} is {}, probably 
because a later version of that bundle is already installed" or something like 
that - exposing the {{ResourceState.IGNORED}} and {{ResourceState.INSTALL}} 
values, to help users relate to other webconsole pages which show those values.

And for configs something like "The installer state of the OSGi config resource 
{} is {}, config might have been manually overwritten".

And maybe refer to "the {{org.apache.sling.installer.healthcheck}} 's Sling 
documentation page" for details and hints? It's easier to enhance that page 
rather than try to include too much info in the log messages. That might be an 
additional HC log message emitted only if there are other "red flag" messages.

(BTW the use of both {{log.}} and {{LOG.}} variables is not my favorite ;-) 
maybe use hcLog. for the HC log)

Does that make sense?

Sorry to be picky on this but I think the general problem is far from obvious 
for someone who's not familiar with the installer internals, so providing 
precise information and good documentation will help.

> Health Check for detecting not-installed configurations/bundles from the OSGi 
> installer
> ---
>
> Key: SLING-5888
> URL: https://issues.apache.org/jira/browse/SLING-5888
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check, Installer
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Attachments: SLING-5888-v01.patch
>
>
> We faced an issue in the past that configurations (or bundles) being deployed 
> in the repository are not effective (i.e. not installed in Apache Felix).
> The reason for that is that the OSGi configuration was either manually 
> modified in the Web Console (and therefore takes precedence over the version 
> of the configuration being deployed in the repository) or in case of bundles, 
> that the same bundle has already been deployed in that or a newer version 
> (manually or through some other path in the repository/filesystem).
> Both states may lead to issues at run time, so it would be good to have an 
> automated check for it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling JCR Oak Server 1.1.0

[Oliver Lietz]

On Tuesday 16 August 2016 13:00:59 Daniel Klco wrote:
> +1 -- Signatures check and it builds fine, however, it will not run within
> the latest Sling Launchpad.

hi Dan,

you mean Launchpad 8? That's quite old and several new bundles will not run on 
8. Current Launchpad (upcoming 9) is fine.

Regards,
O.

> On Tue, Aug 16, 2016 at 9:18 AM, Stefan Seifert 
> 
> wrote:
> > +1

[jira] [Commented] (SLING-5868) API to define and retrieve login path with along with authentication requirements

[angela (JIRA)]

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

angela commented on SLING-5868:
---

latest adjustment to final version of SLING-5792 at 
https://github.com/anchela/sling/commit/5cad189dda683f2b713009678636e9a1fde7


> API to define and retrieve login path with along with authentication 
> requirements
> -
>
> Key: SLING-5868
> URL: https://issues.apache.org/jira/browse/SLING-5868
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: angela
>
> When defining parts of the hierarchy that require authentication it would be 
> handy to also be able to defined an optional, individual login path for that 
> particular subtree.
> This functionality could additionally come with an API that would allow to 
> identify the login path that corresponds to a given sling request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5868) API to define and retrieve login path with along with authentication requirements

[angela (JIRA)]

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

angela commented on SLING-5868:
---

[~cziegeler], I would appreciate if you could take a look at this contribution 
making use of the new API introduced with SLING-5792. Obviously it would be 
cool if that would make into the Sling contributions.

> API to define and retrieve login path with along with authentication 
> requirements
> -
>
> Key: SLING-5868
> URL: https://issues.apache.org/jira/browse/SLING-5868
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: angela
>
> When defining parts of the hierarchy that require authentication it would be 
> handy to also be able to defined an optional, individual login path for that 
> particular subtree.
> This functionality could additionally come with an API that would allow to 
> identify the login path that corresponds to a given sling request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5965) Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-5965:


What I meant that for health check you may not need Gauge API and instead just 
use a Gauge like API. Gauge would just improve the reporting over JMX. So 
support for Gauge should not block this

> Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs
> ---
>
> Key: SLING-5965
> URL: https://issues.apache.org/jira/browse/SLING-5965
> Project: Sling
>  Issue Type: New Feature
>  Components: Commons
>Affects Versions: Commons Scheduler 2.5.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Commons Scheduler 2.5.2
>
> Attachments: SLING-5965.patch
>
>
> Sling Scheduler jobs (aka Quartz-Jobs) should typically be fast running jobs. 
> They are served from a thread-pool and should occupy that thread only for a 
> short amount of time.
> If there are 'misbehaving' quartz-jobs that run for a very long time, they 
> start to occupy threads from that thread-pool, thus have an influence on the 
> performance of other scheduled/quartz-jobs.
> We should have metrics (using 
> [sling.commons.metrics|https://sling.apache.org/documentation/bundles/metrics.html])
>  that provide information about internas of Sling Scheduler, such as average, 
> max etc duration of scheduled jobs, as well as how many jobs are currently 
> running and since when was the oldest job running.
> Based on this, a Health-Check can monitor the 'oldest job running' metric and 
> flag {{critical}} when eg the oldest job is older than {{60'000ms}} 
> (configurable, default).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: Build failed in Jenkins: sling-trunk-1.8 #3788

[Stefan Seifert]

this solved the problem in sling-mock.
still failing because the same problem occurred in sling-mock-oak, should be 
fixed in rev. 1756606

i will create a ticket for updating to the latest maven-jar-plugin in our 
parent pom.

the reason it failed only in sling-mock is that there a tests jar is 
additionally published as artifact. may affect other projects as well where 
this is the case.

stefan

>-Original Message-
>From: Stefan Seifert [mailto:sseif...@pro-vision.de]
>Sent: Wednesday, August 17, 2016 9:17 AM
>To: dev@sling.apache.org
>Subject: RE: Build failed in Jenkins: sling-trunk-1.8 #3788
>
>updated to maven-jar-plugin 3.0.2 in the sling-mock project in rev.
>1756581
>let's see if this helps on jenkins.
>
>stefan
>
>>-Original Message-
>>From: Konrad Windszus [mailto:konra...@gmx.de]
>>Sent: Wednesday, August 17, 2016 8:55 AM
>>To: dev@sling.apache.org
>>Subject: Re: Build failed in Jenkins: sling-trunk-1.8 #3788
>>
>>Probably it is related to https://issues.apache.org/jira/browse/MJAR-
>227
>> and
>>https://github.com/codehaus-plexus/plexus-archiver/issues/5
>> which is
>only
>>fixed with maven-jar-plugin 3.0.0.
>>Try if upgrading to 3.0.1 helps in your case.
>>Konrad
>>
>>> On 17 Aug 2016, at 08:43, Stefan Seifert 
>wrote:
>>>
>>>
 [INFO] Apache Sling Testing Sling Mock  FAILURE
>[
 54.843 s]
>>> ...
 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-
 plugin:3.0.0:test-jar (default) on project
>>org.apache.sling.testing.sling-
 mock: Error assembling JAR: Problem creating jar: Execution
>exception:
>>Java
 heap space -> [Help 1]
>>>
>>>
>>> hmm... this happens since i updated to sling parent pom 28 yesterday
>on
>>this project.
>>>
>>> can anyone reproduce this heap space problem on building locally? (i
>>cannot currently)
>>>
>>> is 512MB heap space not engough for the maven build?
>>>
>>> stefan
>
>

[jira] [Created] (SLING-5972) Update to maven-jar-plugin 3.0.2

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-5972:
-

 Summary: Update to maven-jar-plugin 3.0.2
 Key: SLING-5972
 URL: https://issues.apache.org/jira/browse/SLING-5972
 Project: Sling
  Issue Type: Improvement
  Components: General
Affects Versions: Parent 28
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Priority: Critical
 Fix For: Parent 29


another variant of failing build on jenkins with heap space error is occuring 
in projects that publish tests jar artifacts e.g. sling-mock, similar to 
SLING-5953.

updating to maven-jar-plugin 3.0.2 should help.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5972) Update to maven-jar-plugin 3.0.2

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-5972.
---
Resolution: Fixed

Completed: At revision: 1756610  


> Update to maven-jar-plugin 3.0.2
> 
>
> Key: SLING-5972
> URL: https://issues.apache.org/jira/browse/SLING-5972
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Parent 28
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Critical
> Fix For: Parent 29
>
>
> another variant of failing build on jenkins with heap space error is occuring 
> in projects that publish tests jar artifacts e.g. sling-mock, similar to 
> SLING-5953.
> updating to maven-jar-plugin 3.0.2 should help.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5888) Health Check for detecting not-installed configurations/bundles from the OSGi installer

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-5888.

   Resolution: Fixed
Fix Version/s: Installer Health Checks 1.0.0

Contributed initial version in [r1756614|https://svn.apache.org/r1756614] 
considering the feedback from [~bdelacretaz]. In addition extended the 
documentation at 
https://sling.apache.org/documentation/bundles/osgi-installer.html in 
[r1756615|https://svn.apache.org/r1756615].

> Health Check for detecting not-installed configurations/bundles from the OSGi 
> installer
> ---
>
> Key: SLING-5888
> URL: https://issues.apache.org/jira/browse/SLING-5888
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check, Installer
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Installer Health Checks 1.0.0
>
> Attachments: SLING-5888-v01.patch
>
>
> We faced an issue in the past that configurations (or bundles) being deployed 
> in the repository are not effective (i.e. not installed in Apache Felix).
> The reason for that is that the OSGi configuration was either manually 
> modified in the Web Console (and therefore takes precedence over the version 
> of the configuration being deployed in the repository) or in case of bundles, 
> that the same bundle has already been deployed in that or a newer version 
> (manually or through some other path in the repository/filesystem).
> Both states may lead to issues at run time, so it would be good to have an 
> automated check for it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5965) Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5965:
-

[~egli] Looks basically ok to me, however I think we should move the HC to a 
separate bundle, otherwise everyone using the scheduler has a dependency on HC

> Metrics and a Health-Check for Scheduler to detect long-running Quartz-Jobs
> ---
>
> Key: SLING-5965
> URL: https://issues.apache.org/jira/browse/SLING-5965
> Project: Sling
>  Issue Type: New Feature
>  Components: Commons
>Affects Versions: Commons Scheduler 2.5.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Commons Scheduler 2.5.2
>
> Attachments: SLING-5965.patch
>
>
> Sling Scheduler jobs (aka Quartz-Jobs) should typically be fast running jobs. 
> They are served from a thread-pool and should occupy that thread only for a 
> short amount of time.
> If there are 'misbehaving' quartz-jobs that run for a very long time, they 
> start to occupy threads from that thread-pool, thus have an influence on the 
> performance of other scheduled/quartz-jobs.
> We should have metrics (using 
> [sling.commons.metrics|https://sling.apache.org/documentation/bundles/metrics.html])
>  that provide information about internas of Sling Scheduler, such as average, 
> max etc duration of scheduled jobs, as well as how many jobs are currently 
> running and since when was the oldest job running.
> Based on this, a Health-Check can monitor the 'oldest job running' metric and 
> flag {{critical}} when eg the oldest job is older than {{60'000ms}} 
> (configurable, default).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5868) API to define and retrieve login path with along with authentication requirements

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5868:
-

[~anchela] Thanks for your contribution - I think it would make sense to split 
the public API from the implementation as the impl is tied to Oak - that's not 
bad by itself but if someone wants to provide a different implementation for 
the API, it will depend on this bundle which depends on Oak.
Would it make sense to move the public API to auth.core?

> API to define and retrieve login path with along with authentication 
> requirements
> -
>
> Key: SLING-5868
> URL: https://issues.apache.org/jira/browse/SLING-5868
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: angela
>
> When defining parts of the hierarchy that require authentication it would be 
> handy to also be able to defined an optional, individual login path for that 
> particular subtree.
> This functionality could additionally come with an API that would allow to 
> identify the login path that corresponds to a given sling request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: [VOTE] Release Apache Sling Testing PaxExam 0.0.2

[Oliver Lietz]

On Tuesday 16 August 2016 13:14:57 Stefan Seifert wrote:
> +1

hi Stefan,

> i stumbled upon one thing (not blocking the release, we can change it later
> as well)
> 
> why is the folder named
>   testing/org.apache.sling.testing.paxexam
> and not just
>   testing/paxexam
> ?
> 
> this is inconsistent with the other modules there.

we don't have a consistent scheme across the project but I prefer the simple 
pattern (rule)

root Java package == artifact id == bundle symbolic name == module name

This makes it much, much easier to find code and projects (modules).

Following this pattern makes module names unique also (we have several api, 
base and core modules) and you don't have to come up with workarounds like 
prefix or additional "parent" directory.

I'm not happy with our nested repo layout and often wish a flat list of 
modules (where short names would not work of course).

Regards,
O. 

> stefan

Re: [VOTE] Release Apache Sling Testing PaxExam 0.0.2

[Oliver Lietz]

On Sunday 14 August 2016 09:27:46 Oliver Lietz wrote:
> Hi,
> 
> we solved 8 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12336948

+1

O.

Re: [VOTE] Release Apache Sling JCR Oak Server 1.1.0

[Oliver Lietz]

On Saturday 13 August 2016 10:10:59 Oliver Lietz wrote:
> Hi,
> 
> we solved 11 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12337894

+1

O.

[jira] [Commented] (SLING-5868) API to define and retrieve login path with along with authentication requirements

[angela (JIRA)]

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

angela commented on SLING-5868:
---

sure... if that makes sense for a broader Sling audience, I am more than happy 
to have the public API part in auth.core. 
in an initial step i just wanted to keep and discuss this new feature clearly 
separated from the other enhancements. 

> API to define and retrieve login path with along with authentication 
> requirements
> -
>
> Key: SLING-5868
> URL: https://issues.apache.org/jira/browse/SLING-5868
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: angela
>
> When defining parts of the hierarchy that require authentication it would be 
> handy to also be able to defined an optional, individual login path for that 
> particular subtree.
> This functionality could additionally come with an API that would allow to 
> identify the login path that corresponds to a given sling request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5868) API to define and retrieve login path with along with authentication requirements

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5868:
-

What would be a typical client of the new interface?

> API to define and retrieve login path with along with authentication 
> requirements
> -
>
> Key: SLING-5868
> URL: https://issues.apache.org/jira/browse/SLING-5868
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: angela
>
> When defining parts of the hierarchy that require authentication it would be 
> handy to also be able to defined an optional, individual login path for that 
> particular subtree.
> This functionality could additionally come with an API that would allow to 
> identify the login path that corresponds to a given sling request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling JCR Oak Server 1.1.0

[Daniel Klco]

Nope, I'm testing against Launchpad 9, specifically:

org.apache.sling.launchpad-9-20160801.071219-1574.jar

On Wed, Aug 17, 2016 at 4:58 AM, Oliver Lietz  wrote:

> On Tuesday 16 August 2016 13:00:59 Daniel Klco wrote:
> > +1 -- Signatures check and it builds fine, however, it will not run
> within
> > the latest Sling Launchpad.
>
> hi Dan,
>
> you mean Launchpad 8? That's quite old and several new bundles will not
> run on
> 8. Current Launchpad (upcoming 9) is fine.
>
> Regards,
> O.
>
> > On Tue, Aug 16, 2016 at 9:18 AM, Stefan Seifert 
> >
> > wrote:
> > > +1
>
>
>

Re: [VOTE] Release Apache Sling JCR Oak Server 1.1.0

[Oliver Lietz]

On Wednesday 17 August 2016 08:34:58 Daniel Klco wrote:
> Nope, I'm testing against Launchpad 9, specifically:
> 
> org.apache.sling.launchpad-9-20160801.071219-1574.jar

Can you give some details?

O.

> On Wed, Aug 17, 2016 at 4:58 AM, Oliver Lietz  wrote:
> > On Tuesday 16 August 2016 13:00:59 Daniel Klco wrote:
> > > +1 -- Signatures check and it builds fine, however, it will not run
> > 
> > within
> > 
> > > the latest Sling Launchpad.
> > 
> > hi Dan,
> > 
> > you mean Launchpad 8? That's quite old and several new bundles will not
> > run on
> > 8. Current Launchpad (upcoming 9) is fine.
> > 
> > Regards,
> > O.
> > 
> > > On Tue, Aug 16, 2016 at 9:18 AM, Stefan Seifert 
> > > 
> > > wrote:
> > > > +1

Re: [VOTE] Release Apache Sling JCR Oak Server 1.1.0

[Daniel Klco]

The bundle compiles file, however when I install it into the latest Sling
Launchpad I get the following missing import:
http://imgur.com/a/yUfG7

It looks like org.apache.jackrabbit.commons.jackrabbit.authorization is the
problem:

com.mongodb -- Cannot be resolved but is not required
org.apache.jackrabbit.commons.jackrabbit.authorization,version=[2.13,3) --
Cannot be resolved
org.apache.jackrabbit.oak.security.user -- Cannot be resolved but is not
required
org.apache.jackrabbit.test -- Cannot be resolved but is not required

On Wed, Aug 17, 2016 at 8:44 AM, Oliver Lietz  wrote:

> On Wednesday 17 August 2016 08:34:58 Daniel Klco wrote:
> > Nope, I'm testing against Launchpad 9, specifically:
> >
> > org.apache.sling.launchpad-9-20160801.071219-1574.jar
>
> Can you give some details?
>
> O.
>
> > On Wed, Aug 17, 2016 at 4:58 AM, Oliver Lietz 
> wrote:
> > > On Tuesday 16 August 2016 13:00:59 Daniel Klco wrote:
> > > > +1 -- Signatures check and it builds fine, however, it will not run
> > >
> > > within
> > >
> > > > the latest Sling Launchpad.
> > >
> > > hi Dan,
> > >
> > > you mean Launchpad 8? That's quite old and several new bundles will not
> > > run on
> > > 8. Current Launchpad (upcoming 9) is fine.
> > >
> > > Regards,
> > > O.
> > >
> > > > On Tue, Aug 16, 2016 at 9:18 AM, Stefan Seifert <
> sseif...@pro-vision.de>
> > > >
> > > > wrote:
> > > > > +1
>
>

[jira] [Commented] (SLING-5868) API to define and retrieve login path with along with authentication requirements

[angela (JIRA)]

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

angela commented on SLING-5868:
---

we would use it at Adobe with a dedicated {{AuthenticationHandler}} 
implementation that upon unsuccessful 
{{AuthenticationHandler.requestCredentials}} tries to determine a login 
resource and redirect the client instead of simply failing the authentication.

> API to define and retrieve login path with along with authentication 
> requirements
> -
>
> Key: SLING-5868
> URL: https://issues.apache.org/jira/browse/SLING-5868
> Project: Sling
>  Issue Type: Sub-task
>  Components: Authentication
>Reporter: angela
>
> When defining parts of the hierarchy that require authentication it would be 
> handy to also be able to defined an optional, individual login path for that 
> particular subtree.
> This functionality could additionally come with an API that would allow to 
> identify the login path that corresponds to a given sling request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling JCR Oak Server 1.1.0

[Oliver Lietz]

On Wednesday 17 August 2016 08:55:43 Daniel Klco wrote:
> The bundle compiles file, however when I install it into the latest Sling
> Launchpad I get the following missing import:
> http://imgur.com/a/yUfG7
> 
> It looks like org.apache.jackrabbit.commons.jackrabbit.authorization is the
> problem:
> 
> com.mongodb -- Cannot be resolved but is not required
> org.apache.jackrabbit.commons.jackrabbit.authorization,version=[2.13,3) --
> Cannot be resolved
> org.apache.jackrabbit.oak.security.user -- Cannot be resolved but is not
> required
> org.apache.jackrabbit.test -- Cannot be resolved but is not required

You need a newer version due to SLING-5958 and SLING-5959, so *latest* 
Launchpad is fine (which I checked during release). Robert added some basic 
smoke tests to builder which ensure Launchpad is usable. See ITs in Oak Server 
also (SLING-5956).

Regards,
O.

[...]

[jira] [Resolved] (SLING-5941) [SCD] Verify the uploaded distribution packages integrity via checksums

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili resolved SLING-5941.

Resolution: Fixed

fixed in r1756640, thanks [~simone.tripodi] for your patch! (I had to take the 
{{DigestUtils}} class from the _.2.patch_ as I could not find it in _.3.patch_).

> [SCD] Verify the uploaded distribution packages integrity via checksums
> ---
>
> Key: SLING-5941
> URL: https://issues.apache.org/jira/browse/SLING-5941
> Project: Sling
>  Issue Type: New Feature
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Simone Tripodi
>Assignee: Tommaso Teofili
>Priority: Minor
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5941.1.patch, SLING-5941.2.patch, 
> SLING-5941.3.patch, SLING-5941.patch
>
>
> Currently, there is no way to understand if a received package is (not) 
> corrupted when transported, so adding a checksum generation/validation would 
> be a solution to this problem



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: [VOTE] Release Sling Hypermedia API client-side tools 1.0.0 - take TWO

[Stefan Seifert]

hello andrei.

i can help. please execute all steps from [1] yourself:
- "Wait for the Results" (official [RESULT] [VOTE] mail)
- "Promoting the Release"
- "Update JIRA"

the only step you cannot do yourself is "Push the release to 
https://dist.apache.org/repos/dist/release/sling/"; - i've completed this step 
just now (rev. 14852)

stefan

[1] http://sling.apache.org/documentation/development/release-management.html


>-Original Message-
>From: Andrei Dulvac [mailto:andrei.dul...@gmail.com]
>Sent: Wednesday, August 17, 2016 8:59 AM
>To: dev@sling.apache.org
>Subject: Re: [VOTE] Release Sling Hypermedia API client-side tools 1.0.0 -
>take TWO
>
>Thanks Everyone.
>We have 5 +1's. Could someone in the PMC finalize the release?
>
>- Andrei
>
>
>On Tue, Aug 16, 2016 at 11:50 PM Karl Pauls  wrote:
>
>> +1
>>
>> regards,
>>
>> Karl
>>
>> On Fri, Aug 12, 2016 at 11:02 AM, Andrei Dulvac 
>wrote:
>>
>> > Hi,
>> >
>> > We solved 3 issues for this initial
>> > release:
>> https://issues.apache.org/jira/browse/SLING/fixforversion/12337959
>> > Staging repository:
>> >
>> > https://repository.apache.org/content/repositories/orgapachesling-1499/
>> >
>> > 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 1499 /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.
>> >
>> > Thanks,
>> > - Andrei
>> >
>>
>>
>>
>> --
>> Karl Pauls
>> karlpa...@gmail.com
>>

[jira] [Updated] (SLING-5906) Allow to filter resource by properties

[Timothee Maret (JIRA)]

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

Timothee Maret updated SLING-5906:
--
Attachment: SLING-5906.patch

> Allow to filter resource by properties
> --
>
> Key: SLING-5906
> URL: https://issues.apache.org/jira/browse/SLING-5906
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: SLING-5906.patch
>
>
> In some scenarios, it is useful to allow filtering out some properties when 
> importing content. Those properties may be used to filter out ACLs (e.g. 
> {{jcr:primaryType=rep:ACL}} or more generally properties that are instance 
> specific.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5941) [SCD] Verify the uploaded distribution packages integrity via checksums

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-5941:
---

Commit the {{DigestUtils}} in ee0b7f162063fc968dc308de8f2c31b8948cc7d0 (seems 
it was not in for some reason)

> [SCD] Verify the uploaded distribution packages integrity via checksums
> ---
>
> Key: SLING-5941
> URL: https://issues.apache.org/jira/browse/SLING-5941
> Project: Sling
>  Issue Type: New Feature
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Simone Tripodi
>Assignee: Tommaso Teofili
>Priority: Minor
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5941.1.patch, SLING-5941.2.patch, 
> SLING-5941.3.patch, SLING-5941.patch
>
>
> Currently, there is no way to understand if a received package is (not) 
> corrupted when transported, so adding a checksum generation/validation would 
> be a solution to this problem



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5906) Allow to filter resource by properties

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-5906:
---

Done in {{r1756657}} 
https://github.com/apache/sling/commit/6c51f05fc61ba3e69f890706afb181214b2f52ce

> Allow to filter resource by properties
> --
>
> Key: SLING-5906
> URL: https://issues.apache.org/jira/browse/SLING-5906
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: SLING-5906.patch
>
>
> In some scenarios, it is useful to allow filtering out some properties when 
> importing content. Those properties may be used to filter out ACLs (e.g. 
> {{jcr:primaryType=rep:ACL}} or more generally properties that are instance 
> specific.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5906) Allow to filter resource by properties

[Timothee Maret (JIRA)]

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

Timothee Maret updated SLING-5906:
--
Fix Version/s: Content Distribution 0.2.0

> Allow to filter resource by properties
> --
>
> Key: SLING-5906
> URL: https://issues.apache.org/jira/browse/SLING-5906
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5906.patch
>
>
> In some scenarios, it is useful to allow filtering out some properties when 
> importing content. Those properties may be used to filter out ACLs (e.g. 
> {{jcr:primaryType=rep:ACL}} or more generally properties that are instance 
> specific.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5906) Allow to filter resource by properties

[Timothee Maret (JIRA)]

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

Timothee Maret resolved SLING-5906.
---
Resolution: Fixed

> Allow to filter resource by properties
> --
>
> Key: SLING-5906
> URL: https://issues.apache.org/jira/browse/SLING-5906
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Affects Versions: Content Distribution Core 0.1.18
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-5906.patch
>
>
> In some scenarios, it is useful to allow filtering out some properties when 
> importing content. Those properties may be used to filter out ACLs (e.g. 
> {{jcr:primaryType=rep:ACL}} or more generally properties that are instance 
> specific.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[RESULT] [VOTE] Release Apache Sling Testing PaxExam 0.0.2

[Oliver Lietz]

Hi,

the vote has passed with the following result:

+1 (binding): Stefan Egli, Stefan Seifert, Daniel Klco, Oliver Lietz

I will copy this release to the Sling dist directory and promote the artifacts 
to the central Maven repository.

Thanks for voting!

O.

[RESULT] [VOTE] Release Apache Sling JCR Oak Server 1.1.0

[Oliver Lietz]

Hi,

the vote has passed with the following result:

+1 (binding): Carsten Ziegeler, Stefan Egli, Stefan Seifert, Daniel Klco, 
Oliver Lietz

I will copy this release to the Sling dist directory and promote the artifacts 
to the central Maven repository.

Thanks for voting!

O.

[jira] [Closed] (SLING-5777) Stop embedding oak-jcr in the o.a.s.jcr.oak.server bundle

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5777.
---

> Stop embedding oak-jcr in the o.a.s.jcr.oak.server bundle
> -
>
> Key: SLING-5777
> URL: https://issues.apache.org/jira/browse/SLING-5777
> Project: Sling
>  Issue Type: Bug
>  Components: Oak
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: JCR Oak Server 1.1.0
>
>
> We should no longer embed the oak-jcr bundle, as it makes upgrading new Oak 
> version harder, since we need to update both the oak-server bundle and the 
> launchpad.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5956) Move Oak ITs from org.apache.sling.jcr.repository.it-jackrabbit-oak into org.apache.sling.jcr.oak.server

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5956.
---

> Move Oak ITs from org.apache.sling.jcr.repository.it-jackrabbit-oak into 
> org.apache.sling.jcr.oak.server
> 
>
> Key: SLING-5956
> URL: https://issues.apache.org/jira/browse/SLING-5956
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Oak
>Affects Versions: JCR Oak Server 1.0.0
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR Oak Server 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5955) Refactor configuration of OakSlingRepositoryManager

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5955.
---

> Refactor configuration of OakSlingRepositoryManager
> ---
>
> Key: SLING-5955
> URL: https://issues.apache.org/jira/browse/SLING-5955
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Oak
>Affects Versions: JCR Oak Server 1.0.0
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR Oak Server 1.1.0
>
>
> * use R6 Metatype annotations
> * drop framework/system property support 
> ({{oak.observation.limit-commit-rate}} and {{oak.observation.queue-length}})
> * use {{adminId}} from {{SecurityProvider}} only



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5893) Provide a default Launchpad Oak Tar configuration as Option for Pax Exam

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5893.
---

> Provide a default Launchpad Oak Tar configuration as Option for Pax Exam
> 
>
> Key: SLING-5893
> URL: https://issues.apache.org/jira/browse/SLING-5893
> Project: Sling
>  Issue Type: New Feature
>  Components: Testing
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Testing Pax Exam 0.0.2
>
>
> * {{org.apache.felix.http}}: {{org.osgi.service.http.port}}
> * {{org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService}}: 
> {{repository.home}}, {{name}}
> * 
> {{org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService}}:
>  {{localIndexDir}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5809) Provide Sling's Karaf Features as Options for Pax Exam

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5809.
---

> Provide Sling's Karaf Features as Options for Pax Exam
> --
>
> Key: SLING-5809
> URL: https://issues.apache.org/jira/browse/SLING-5809
> Project: Sling
>  Issue Type: New Feature
>  Components: Testing
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Testing Pax Exam 0.0.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5894) Provide test support with common functions for use with Pax Exam

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5894.
---

> Provide test support with common functions for use with Pax Exam
> 
>
> Key: SLING-5894
> URL: https://issues.apache.org/jira/browse/SLING-5894
> Project: Sling
>  Issue Type: New Feature
>  Components: Testing
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Testing Pax Exam 0.0.2
>
>
> * definition of working directory (overridable)
> * a test base configuration
> * finding free port
> * getting configured {{org.osgi.service.http.port}} 
> ({{org.apache.felix.http}})



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5911) Make non-generated Options self-contained

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5911.
---

> Make non-generated Options self-contained
> -
>
> Key: SLING-5911
> URL: https://issues.apache.org/jira/browse/SLING-5911
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Testing Pax Exam 0.0.2
>
>
> Most non-generated Options are not usable separately.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5898) Point to the alternative repository if specified on the command-line

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5898.
---

> Point to the alternative repository if specified on the command-line
> 
>
> Key: SLING-5898
> URL: https://issues.apache.org/jira/browse/SLING-5898
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Robert Munteanu
>Assignee: Oliver Lietz
> Fix For: Testing Pax Exam 0.0.2
>
>
> This is basically SLING-2847 and SLING-2848 applied to the new module. 
> This will help with the situation where we have SNAPSHOT dependencies which 
> by design aren't resolved from the reactor by Pax-Exam.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5897) Fail the test by default if there are unresolved bundles

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5897.
---

> Fail the test by default if there are unresolved bundles
> 
>
> Key: SLING-5897
> URL: https://issues.apache.org/jira/browse/SLING-5897
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Robert Munteanu
>Assignee: Oliver Lietz
> Fix For: Testing Pax Exam 0.0.2
>
>
> TestOptions.baseConfiguration should by default ensure that the test fails 
> for unresolved bundles:
> {code:java}systemProperty("pax.exam.osgi.unresolved.fail").value("true"){code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5912) Add Integration Tests for non-generated Options

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5912.
---

> Add Integration Tests for non-generated Options
> ---
>
> Key: SLING-5912
> URL: https://issues.apache.org/jira/browse/SLING-5912
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Testing Pax Exam 0.0.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SLING-5929) Provide Pax URL and Pax URL Classpath as Options for Pax Exam

[Oliver Lietz (JIRA)]

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

Oliver Lietz closed SLING-5929.
---

> Provide Pax URL and Pax URL Classpath as Options for Pax Exam
> -
>
> Key: SLING-5929
> URL: https://issues.apache.org/jira/browse/SLING-5929
> Project: Sling
>  Issue Type: New Feature
>  Components: Testing
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Testing Pax Exam 0.0.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-4411) Provide Oak features

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-4411.
-
Resolution: Done

using JCR Oak Server 1.1.0 ([r1756687|https://svn.apache.org/r1756687])

> Provide Oak features
> 
>
> Key: SLING-4411
> URL: https://issues.apache.org/jira/browse/SLING-4411
> Project: Sling
>  Issue Type: New Feature
>  Components: Karaf
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Karaf Features 0.2.0
>
>
> provide features for Oak as we have now for Jackrabbit:
> * {{oak-sling}}
> * {{sling-jcr-oak}}
> * {{sling-launchpad-oak}}
> * {{sling-launchpad-oak-tar}}
> * {{sling-launchpad-oak-mongo}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-4411) Provide Oak features

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-4411:

Description: 
provide features for Oak as we have now for Jackrabbit:
* -{{oak-sling}}-
* {{sling-jcr-oak}}
* {{sling-launchpad-oak}}
* {{sling-launchpad-oak-tar}}
* {{sling-launchpad-oak-mongo}}

  was:
provide features for Oak as we have now for Jackrabbit:
* {{oak-sling}}
* {{sling-jcr-oak}}
* {{sling-launchpad-oak}}
* {{sling-launchpad-oak-tar}}
* {{sling-launchpad-oak-mongo}}


> Provide Oak features
> 
>
> Key: SLING-4411
> URL: https://issues.apache.org/jira/browse/SLING-4411
> Project: Sling
>  Issue Type: New Feature
>  Components: Karaf
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Karaf Features 0.2.0
>
>
> provide features for Oak as we have now for Jackrabbit:
> * -{{oak-sling}}-
> * {{sling-jcr-oak}}
> * {{sling-launchpad-oak}}
> * {{sling-launchpad-oak-tar}}
> * {{sling-launchpad-oak-mongo}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[RESULT] [VOTE] Release Sling Hypermedia API client-side tools 1.0.0

[Andrei Dulvac]

Hi,
The vote has passed with the following result :
+5 (binding): Carsten Ziegler, Stefan Egli, Stefan Seifert, Daniel
Klco, Karl Pauls
I will copy this release to the Sling dist directory andpromote the
artifacts to the central Maven repository.