Re: [VOTE] Release Apache Sling Oak Restrictions version 1.0.0

2016-09-27 Thread Karl Pauls
> > It needs to be the key fingerprint I think - not the key id (just in
> > case
> > that isn't what you have set there).
> >
> > Otherwise, the release looks good to me.
>
> Good point, I updated it to be the full key fingerprint.
>
> I'll wait a bit for the .asc file to be updated, it's a batch process
> IIRC.
>
> Robert


It's there now!

+1 for the release.


regards,

Karl


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


RE: [VOTE] Release Apache Sling Discovery Commons 1.0.16 and Discovery Oak 1.2.14

2016-09-27 Thread Stefan Seifert
signatures and build are fine, but i've one question:

rev. 1761756 for SLING-5995 breaks the API compatibility and increases the 
package version of package 
org.apache.sling.discovery.commons.providers.spi.base to 2.0.0, forcing all 
existing implementations to recompile or adapt their version ranges. is this 
intended?
such a beacking change is not reflected in the bundle version (1.0.12 -> 1.0.16)

stefan


>-Original Message-
>From: Stefan Egli [mailto:stefane...@apache.org]
>Sent: Monday, September 26, 2016 12:09 PM
>To: dev@sling.apache.org
>Subject: [VOTE] Release Apache Sling Discovery Commons 1.0.16 and
>Discovery Oak 1.2.14
>
>Hi,
>
>We solved 4 issues in these 2 related releases:
>
>https://issues.apache.org/jira/browse/SLING/fixforversion/12338296
>https://issues.apache.org/jira/browse/SLING/fixforversion/12338297
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1526
>
>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 1526 /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.
>
>Cheers,
>Stefan
>
>




[jira] [Comment Edited] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

2016-09-27 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler edited comment on SLING-6056 at 9/28/16 5:59 AM:
--

[~egli] We can't make a major version change of that package, we introduced the 
new abstract class exactly for that reason: being able to add new functionality 
without requiring to update the major version number. If we would increase the 
major package version, we break all provder implementations.
I'm not 100% sure the API change is really needed, give me please some days to 
think about it.


was (Author: cziegeler):
[~egli] We can't make a major version change of that package, we introduced the 
new abstract class exactly for that reason. If we would increase the major 
package version, we break all implementations.
I'm not 100% sure the API change is really needed, give me please some days to 
think about it.

> achieve 1:1 mapping between observation and resource change listener
> 
>
> Key: SLING-6056
> URL: https://issues.apache.org/jira/browse/SLING-6056
> Project: Sling
>  Issue Type: Task
>  Components: ResourceResolver
>Affects Versions: JCR Resource 2.8.0, API 2.14.2, Resource Resolver 1.4.18
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Critical
> Fix For: JCR Resource 2.8.2, API 2.15.0, Resource Resolver 1.4.20
>
> Attachments: SLING-6056.patch
>
>
> At the moment it seems there is a 1:n mapping between 1 OakResourceListener 
> (and 1 BasicObservationReporter) and n ResourceChangeListeners. The idea 
> however is to get rid of such a bottleneck and have a 1:1 mapping (that might 
> or might not be in the BasicObservationReporter, that I don't know). We 
> should implement such a 1:1 mapping.
> See [thread on dev list|http://sling.markmail.org/thread/uwhda777psgklwo6]



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


[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

2016-09-27 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler commented on SLING-6056:
-

[~egli] We can't make a major version change of that package, we introduced the 
new abstract class exactly for that reason. If we would increase the major 
package version, we break all implementations.
I'm not 100% sure the API change is really needed, give me please some days to 
think about it.

> achieve 1:1 mapping between observation and resource change listener
> 
>
> Key: SLING-6056
> URL: https://issues.apache.org/jira/browse/SLING-6056
> Project: Sling
>  Issue Type: Task
>  Components: ResourceResolver
>Affects Versions: JCR Resource 2.8.0, API 2.14.2, Resource Resolver 1.4.18
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Critical
> Fix For: JCR Resource 2.8.2, API 2.15.0, Resource Resolver 1.4.20
>
> Attachments: SLING-6056.patch
>
>
> At the moment it seems there is a 1:n mapping between 1 OakResourceListener 
> (and 1 BasicObservationReporter) and n ResourceChangeListeners. The idea 
> however is to get rid of such a bottleneck and have a 1:1 mapping (that might 
> or might not be in the BasicObservationReporter, that I don't know). We 
> should implement such a 1:1 mapping.
> See [thread on dev list|http://sling.markmail.org/thread/uwhda777psgklwo6]



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


Re: [VOTE] Release Apache Sling Oak Restrictions version 1.0.0

2016-09-27 Thread Georg Henzler

+1 (and thanks for taking care of the release)

Georg


On 2016-09-27 23:17, Daniel Klco wrote:

+1

I updated my GPG keys as such:

wget https://people.apache.org/keys/group/sling.asc -q -O 
/tmp/sling.asc

gpg --import /tmp/sling.asc &> /dev/null

And the signatures look good.

On Tue, Sep 27, 2016 at 5:13 PM, Robert Munteanu  
wrote:



On Tue, 2016-09-27 at 22:50 +0200, Karl Pauls wrote:
> I'm getting bad sigs. I think i don't see your key in
> https://people.apache.org/keys/group/sling.asc - is it possible that
> you
> didn't add your gpg key id to your id.apache.org account (or that it
> is not
> available via a public server)?

Hm, that's weird.

My public key is set as 4F63EC54 via id.apache.org . Also

$ gpg --recv-keys 4F63EC54
gpg: key 339508654F63EC54: "Robert Munteanu " not
changed
gpg: Total number processed: 1
gpg:  unchanged: 1

Robert

>
> regards,
>
> Karl
>
> On Tue, Sep 27, 2016 at 10:32 PM, Robert Munteanu  >
> wrote:
>
> > Hi,
> >
> > We solved 4 issues in this release:
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12337877
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-1
> > 527
> >
> > 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 1527 /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.
> >
>
>
>
>
>




Re: [VOTE] Release Apache Sling Oak Restrictions version 1.0.0

2016-09-27 Thread Robert Munteanu
On Tue, 2016-09-27 at 23:24 +0200, Karl Pauls wrote:
> I
> 
> On Tue, Sep 27, 2016 at 11:13 PM, Robert Munteanu  >
> wrote:
> 
> > On Tue, 2016-09-27 at 22:50 +0200, Karl Pauls wrote:
> > > I'm getting bad sigs. I think i don't see your key in
> > > https://people.apache.org/keys/group/sling.asc - is it possible
> > > that
> > > you
> > > didn't add your gpg key id to your id.apache.org account (or that
> > > it
> > > is not
> > > available via a public server)?
> > 
> > 
> > Hm, that's weird.
> > 
> > My public key is set as 4F63EC54 via id.apache.org . Also
> > 
> 
> 
> It needs to be the key fingerprint I think - not the key id (just in
> case
> that isn't what you have set there).
> 
> Otherwise, the release looks good to me.

Good point, I updated it to be the full key fingerprint.

I'll wait a bit for the .asc file to be updated, it's a batch process
IIRC.

Robert

> 
> regards,
> 
> Karl
> 
> 
> > $ gpg --recv-keys 4F63EC54
> > gpg: key 339508654F63EC54: "Robert Munteanu "
> > not
> > changed
> > gpg: Total number processed: 1
> > gpg:  unchanged: 1
> > 
> > Robert
> > 
> > > 
> > > regards,
> > > 
> > > Karl
> > > 
> > > On Tue, Sep 27, 2016 at 10:32 PM, Robert Munteanu  > > .org
> > > > 
> > > 
> > > wrote:
> > > 
> > > > Hi,
> > > > 
> > > > We solved 4 issues in this release:
> > > > https://issues.apache.org/jira/browse/SLING/fixforversion/12337
> > > > 877
> > > > 
> > > > Staging repository:
> > > > https://repository.apache.org/content/repositories/orgapachesli
> > > > ng-1
> > > > 527
> > > > 
> > > > You can use this UNIX script to download the release and verify
> > > > the
> > > > signatures:
> > > > http://svn.apache.org/repos/asf/sling/trunk/check_staged_releas
> > > > e.sh
> > > > 
> > > > Usage:
> > > > sh check_staged_release.sh 1527 /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.
> > > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> 
> 
> 
> 



Re: [VOTE] Release Apache Sling Oak Restrictions version 1.0.0

2016-09-27 Thread Karl Pauls
I

On Tue, Sep 27, 2016 at 11:13 PM, Robert Munteanu 
wrote:

> On Tue, 2016-09-27 at 22:50 +0200, Karl Pauls wrote:
> > I'm getting bad sigs. I think i don't see your key in
> > https://people.apache.org/keys/group/sling.asc - is it possible that
> > you
> > didn't add your gpg key id to your id.apache.org account (or that it
> > is not
> > available via a public server)?
>
> Hm, that's weird.
>
> My public key is set as 4F63EC54 via id.apache.org . Also
>

It needs to be the key fingerprint I think - not the key id (just in case
that isn't what you have set there).

Otherwise, the release looks good to me.

regards,

Karl


> $ gpg --recv-keys 4F63EC54
> gpg: key 339508654F63EC54: "Robert Munteanu " not
> changed
> gpg: Total number processed: 1
> gpg:  unchanged: 1
>
> Robert
>
> >
> > regards,
> >
> > Karl
> >
> > On Tue, Sep 27, 2016 at 10:32 PM, Robert Munteanu  > >
> > wrote:
> >
> > > Hi,
> > >
> > > We solved 4 issues in this release:
> > > https://issues.apache.org/jira/browse/SLING/fixforversion/12337877
> > >
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/orgapachesling-1
> > > 527
> > >
> > > 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 1527 /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.
> > >
> >
> >
> >
> >
> >
>
>


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


Re: Build failed in Jenkins: sling-bundles-extensions-discovery-api-1.8 #1

2016-09-27 Thread Robert Munteanu
I've configured the jobs to not fail if no JUnit test results are
found, the build should be fixed on the next run.

Robert

On Tue, 2016-09-27 at 21:20 +, Apache Jenkins Server wrote:
> See  -api-1.8/1/>
> 
> --
> Started by an SCM change
> [EnvInject] - Loading node environment variables.
> Building remotely on H11 (Ubuntu yahoo-not-h2 ubuntu docker) in
> workspace  covery-api-1.8/ws/>
> Checking out a fresh workspace because there's no workspace at  ://builds.apache.org/job/sling-bundles-extensions-discovery-api-
> 1.8/ws/>
> Cleaning local Directory .
> Checking out https://svn.apache.org/repos/asf/sling/trunk/bundles/ext
> ensions/discovery/api at revision '2016-09-27T21:20:24.661 +'
> AUpom.xml
> A src
> A src/main
> A src/main/java
> A src/main/java/org
> A src/main/java/org/apache
> A src/main/java/org/apache/sling
> A src/main/java/org/apache/sling/discovery
> AUsrc/main/java/org/apache/sling/discovery/PropertyProvider.j
> ava
> AUsrc/main/java/org/apache/sling/discovery/TopologyEventListe
> ner.java
> AUsrc/main/java/org/apache/sling/discovery/package-info.java
> AUsrc/main/java/org/apache/sling/discovery/TopologyView.java
> AUsrc/main/java/org/apache/sling/discovery/DiscoveryService.j
> ava
> AUsrc/main/java/org/apache/sling/discovery/InstanceDescriptio
> n.java
> AUsrc/main/java/org/apache/sling/discovery/InstanceFilter.jav
> a
> AUsrc/main/java/org/apache/sling/discovery/ClusterView.java
> AUsrc/main/java/org/apache/sling/discovery/TopologyEvent.java
>  U.
> At revision 1762564
> 
> [sling-bundles-extensions-discovery-api-1.8] $
> /home/jenkins/tools/maven/apache-maven-3.3.9/bin/mvn clean verify
> [INFO] Scanning for projects...
> [INFO]   
>   
> [INFO] --
> --
> [INFO] Building Apache Sling Discovery API 1.0.5-SNAPSHOT
> [INFO] --
> --
> [INFO] 
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @
> org.apache.sling.discovery.api ---
> [INFO] 
> [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java) @
> org.apache.sling.discovery.api ---
> [INFO] 
> [INFO] --- maven-antrun-plugin:1.8:run (set-bundle-required-
> execution-environment) @ org.apache.sling.discovery.api ---
> [INFO] Executing tasks
> 
> main:
> [INFO] Executed tasks
> [INFO] 
> [INFO] --- maven-remote-resources-plugin:1.5:process (default) @
> org.apache.sling.discovery.api ---
> [INFO] 
> [INFO] --- maven-resources-plugin:2.7:resources (default-resources) @
> org.apache.sling.discovery.api ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory  /job/sling-bundles-extensions-discovery-api-1.8/ws/src/main/resources
> >
> [INFO] Copying 3 resources
> [INFO] 
> [INFO] --- maven-antrun-plugin:1.8:run (check-memory-task) @
> org.apache.sling.discovery.api ---
> [INFO] Executing tasks
> 
> main:
>  [echo]  WARNING (SLING-443/SLING-1782)
> **
>  [echo] On most platforms, you'll get OutOfMemoryErrors when
> building unless you set
>  [echo] on 32bit platforms: MAVEN_OPTS="-Xmx256M
> -XX:MaxPermSize=256M", see SLING-443
>  [echo] on 64bit platforms: MAVEN_OPTS="-Xmx512M
> -XX:MaxPermSize=512M", see SLING-1782
>  [echo]
> *
> *
> [INFO] Executed tasks
> [INFO] 
> [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @
> org.apache.sling.discovery.api ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 9 source files to  ng-bundles-extensions-discovery-api-1.8/ws/target/classes>
> [INFO] 
> [INFO] --- maven-resources-plugin:2.7:testResources (default-
> testResources) @ org.apache.sling.discovery.api ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory  /job/sling-bundles-extensions-discovery-api-1.8/ws/src/test/resources
> >
> [INFO] Copying 3 resources
> [INFO] 
> [INFO] --- maven-compiler-plugin:3.2:testCompile (default-
> testCompile) @ org.apache.sling.discovery.api ---
> [INFO] No sources to compile
> [INFO] 
> [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @
> org.apache.sling.discovery.api ---
> [INFO] 
> [INFO] --- animal-sniffer-maven-plugin:1.14:check (default) @
> org.apache.sling.discovery.api ---
> [INFO] Checking unresolved references to
> org.codehaus.mojo.signature:java16:1.0
> [INFO] 
> [INFO] --- maven-bundle-plug

Re: [VOTE] Release Apache Sling Oak Restrictions version 1.0.0

2016-09-27 Thread Robert Munteanu
On Tue, 2016-09-27 at 23:20 +0200, Karl Pauls wrote:
> On Tue, Sep 27, 2016 at 11:17 PM, Daniel Klco 
> wrote:
> 
> > +1
> > 
> > I updated my GPG keys as such:
> > 
> > wget https://people.apache.org/keys/group/sling.asc -q -O
> > /tmp/sling.asc
> > gpg --import /tmp/sling.asc &> /dev/null
> > 
> 
> 
> Are you sure you didn't have it imported before? Because I can't see
> it in
> sling.asc

Neither can I, but I'm positive it was there before.

Robert

> 
> regards,
> 
> Karl
> 
> 
> > And the signatures look good.
> > 
> > On Tue, Sep 27, 2016 at 5:13 PM, Robert Munteanu  > g>
> > wrote:
> > 
> > > On Tue, 2016-09-27 at 22:50 +0200, Karl Pauls wrote:
> > > > I'm getting bad sigs. I think i don't see your key in
> > > > https://people.apache.org/keys/group/sling.asc - is it possible
> > > > that
> > > > you
> > > > didn't add your gpg key id to your id.apache.org account (or
> > > > that it
> > > > is not
> > > > available via a public server)?
> > > 
> > > 
> > > Hm, that's weird.
> > > 
> > > My public key is set as 4F63EC54 via id.apache.org . Also
> > > 
> > > $ gpg --recv-keys 4F63EC54
> > > gpg: key 339508654F63EC54: "Robert Munteanu "
> > > not
> > > changed
> > > gpg: Total number processed: 1
> > > gpg:  unchanged: 1
> > > 
> > > Robert
> > > 
> > > > 
> > > > regards,
> > > > 
> > > > Karl
> > > > 
> > > > On Tue, Sep 27, 2016 at 10:32 PM, Robert Munteanu  > > > he.org
> > > > > 
> > > > 
> > > > wrote:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > We solved 4 issues in this release:
> > > > > https://issues.apache.org/jira/browse/SLING/fixforversion/123
> > > > > 37877
> > > > > 
> > > > > Staging repository:
> > > > > https://repository.apache.org/content/repositories/orgapaches
> > > > > ling-1
> > > > > 527
> > > > > 
> > > > > You can use this UNIX script to download the release and
> > > > > verify the
> > > > > signatures:
> > > > > http://svn.apache.org/repos/asf/sling/trunk/check_staged_rele
> > > > > ase.sh
> > > > > 
> > > > > Usage:
> > > > > sh check_staged_release.sh 1527 /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.
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > 
> > 
> 
> 
> 
> 
> 



Re: [VOTE] Release Apache Sling Oak Restrictions version 1.0.0

2016-09-27 Thread Karl Pauls
On Tue, Sep 27, 2016 at 11:17 PM, Daniel Klco  wrote:

> +1
>
> I updated my GPG keys as such:
>
> wget https://people.apache.org/keys/group/sling.asc -q -O /tmp/sling.asc
> gpg --import /tmp/sling.asc &> /dev/null
>

Are you sure you didn't have it imported before? Because I can't see it in
sling.asc

regards,

Karl


> And the signatures look good.
>
> On Tue, Sep 27, 2016 at 5:13 PM, Robert Munteanu 
> wrote:
>
> > On Tue, 2016-09-27 at 22:50 +0200, Karl Pauls wrote:
> > > I'm getting bad sigs. I think i don't see your key in
> > > https://people.apache.org/keys/group/sling.asc - is it possible that
> > > you
> > > didn't add your gpg key id to your id.apache.org account (or that it
> > > is not
> > > available via a public server)?
> >
> > Hm, that's weird.
> >
> > My public key is set as 4F63EC54 via id.apache.org . Also
> >
> > $ gpg --recv-keys 4F63EC54
> > gpg: key 339508654F63EC54: "Robert Munteanu " not
> > changed
> > gpg: Total number processed: 1
> > gpg:  unchanged: 1
> >
> > Robert
> >
> > >
> > > regards,
> > >
> > > Karl
> > >
> > > On Tue, Sep 27, 2016 at 10:32 PM, Robert Munteanu  > > >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > We solved 4 issues in this release:
> > > > https://issues.apache.org/jira/browse/SLING/fixforversion/12337877
> > > >
> > > > Staging repository:
> > > > https://repository.apache.org/content/repositories/orgapachesling-1
> > > > 527
> > > >
> > > > 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 1527 /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.
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>



-- 
Karl Pauls
karlpa...@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls


Re: [VOTE] Release Apache Sling Oak Restrictions version 1.0.0

2016-09-27 Thread Daniel Klco
+1

I updated my GPG keys as such:

wget https://people.apache.org/keys/group/sling.asc -q -O /tmp/sling.asc
gpg --import /tmp/sling.asc &> /dev/null

And the signatures look good.

On Tue, Sep 27, 2016 at 5:13 PM, Robert Munteanu  wrote:

> On Tue, 2016-09-27 at 22:50 +0200, Karl Pauls wrote:
> > I'm getting bad sigs. I think i don't see your key in
> > https://people.apache.org/keys/group/sling.asc - is it possible that
> > you
> > didn't add your gpg key id to your id.apache.org account (or that it
> > is not
> > available via a public server)?
>
> Hm, that's weird.
>
> My public key is set as 4F63EC54 via id.apache.org . Also
>
> $ gpg --recv-keys 4F63EC54
> gpg: key 339508654F63EC54: "Robert Munteanu " not
> changed
> gpg: Total number processed: 1
> gpg:  unchanged: 1
>
> Robert
>
> >
> > regards,
> >
> > Karl
> >
> > On Tue, Sep 27, 2016 at 10:32 PM, Robert Munteanu  > >
> > wrote:
> >
> > > Hi,
> > >
> > > We solved 4 issues in this release:
> > > https://issues.apache.org/jira/browse/SLING/fixforversion/12337877
> > >
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/orgapachesling-1
> > > 527
> > >
> > > 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 1527 /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.
> > >
> >
> >
> >
> >
> >
>
>


Re: [VOTE] Release Apache Sling Oak Restrictions version 1.0.0

2016-09-27 Thread Robert Munteanu
On Tue, 2016-09-27 at 22:50 +0200, Karl Pauls wrote:
> I'm getting bad sigs. I think i don't see your key in
> https://people.apache.org/keys/group/sling.asc - is it possible that
> you
> didn't add your gpg key id to your id.apache.org account (or that it
> is not
> available via a public server)?

Hm, that's weird.

My public key is set as 4F63EC54 via id.apache.org . Also

$ gpg --recv-keys 4F63EC54
gpg: key 339508654F63EC54: "Robert Munteanu " not
changed
gpg: Total number processed: 1
gpg:  unchanged: 1

Robert

> 
> regards,
> 
> Karl
> 
> On Tue, Sep 27, 2016 at 10:32 PM, Robert Munteanu  >
> wrote:
> 
> > Hi,
> > 
> > We solved 4 issues in this release:
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12337877
> > 
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-1
> > 527
> > 
> > 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 1527 /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.
> > 
> 
> 
> 
> 
> 



Re: [VOTE] Release Apache Sling Oak Restrictions version 1.0.0

2016-09-27 Thread Karl Pauls
I'm getting bad sigs. I think i don't see your key in
https://people.apache.org/keys/group/sling.asc - is it possible that you
didn't add your gpg key id to your id.apache.org account (or that it is not
available via a public server)?

regards,

Karl

On Tue, Sep 27, 2016 at 10:32 PM, Robert Munteanu 
wrote:

> Hi,
>
> We solved 4 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12337877
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1527
>
> 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 1527 /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.
>



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


[VOTE] Release Apache Sling Oak Restrictions version 1.0.0

2016-09-27 Thread Robert Munteanu
Hi,

We solved 4 issues in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12337877

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1527

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


[jira] [Updated] (SLING-6072) The testing rules do not call CloseableHttpClient.close()

2016-09-27 Thread Konrad Windszus (JIRA)

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

Konrad Windszus updated SLING-6072:
---
Assignee: Andrei Dulvac

> The testing rules do not call CloseableHttpClient.close()
> -
>
> Key: SLING-6072
> URL: https://issues.apache.org/jira/browse/SLING-6072
> Project: Sling
>  Issue Type: Bug
>  Components: Apache Sling Testing Clients
>Affects Versions: Apache Sling Testing Clients 1.0.0, Apache Sling Testing 
> Rules 1.0.0
>Reporter: Konrad Windszus
>Assignee: Andrei Dulvac
>
> The rules being provided by the sling testing rules do not automatically call 
> close on the underlying {{ClosableHttpClient}} which is necessary to close 
> the dangling http connections being managed by the underlying connection 
> manager (see 
> https://hc.apache.org/httpcomponents-client-ga/tutorial/html/fundamentals.html#d5e217).
>  Even custom code cannot call close, because the underlying 
> {{ClosableHttpClient}} is not really exposed.
> I guess there is also a change necessary in testing/http/client to expose 
> such a close method as well, and also clarify under which circumstances a new 
> HttpClient is created or when an existing one is reused.



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


[jira] [Created] (SLING-6072) The testing rules do not call CloseableHttpClient.close()

2016-09-27 Thread Konrad Windszus (JIRA)
Konrad Windszus created SLING-6072:
--

 Summary: The testing rules do not call CloseableHttpClient.close()
 Key: SLING-6072
 URL: https://issues.apache.org/jira/browse/SLING-6072
 Project: Sling
  Issue Type: Bug
  Components: Apache Sling Testing Clients
Affects Versions: Apache Sling Testing Rules 1.0.0, Apache Sling Testing 
Clients 1.0.0
Reporter: Konrad Windszus


The rules being provided by the sling testing rules do not automatically call 
close on the underlying {{ClosableHttpClient}} which is necessary to close the 
dangling http connections being managed by the underlying connection manager 
(see 
https://hc.apache.org/httpcomponents-client-ga/tutorial/html/fundamentals.html#d5e217).
 Even custom code cannot call close, because the underlying 
{{ClosableHttpClient}} is not really exposed.

I guess there is also a change necessary in testing/http/client to expose such 
a close method as well, and also clarify under which circumstances a new 
HttpClient is created or when an existing one is reused.



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


Failing distribution ITs (Was: Build failed in Jenkins: sling-contrib-extensions-distribution-1.8 #2)

2016-09-27 Thread Robert Munteanu
Hi,

Seems that the distribution ITs are failing, can someone please look
into it?

Thanks,

Robert

On Tue, 2016-09-27 at 17:37 +, Apache Jenkins Server wrote:
> See  ion-1.8/2/changes>
> 
> Changes:
> 
> [rombert] SLING-6061 - Create per-module Jenkins jobs
> 
> Build the distribution module using a reactor, to make it simpler to
> exclude it from the main Jenkins build.
> 
> --
> [...truncated 27102 lines...]
>   at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCal
> lable.java:12)
>   at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMe
> thod.java:44)
>   at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.ja
> va:33)
>   at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun
> ner.java:70)
>   at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun
> ner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provide
> r.java:283)
>   at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUni
> t4Provider.java:173)
>   at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4
> Provider.java:153)
>   at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider
> .java:128)
>   at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameCla
> ssLoader(ForkedBooter.java:203)
>   at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(Fork
> edBooter.java:155)
>   at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:
> 103)
> 
> Running org.apache.sling.distribution.it.DistributorTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 15.418 sec <<< FAILURE! - in
> org.apache.sling.distribution.it.DistributorTest
> testAddContent(org.apache.sling.distribution.it.DistributorTest)  Tim
> e elapsed: 9.19 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<1>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at
> org.apache.sling.distribution.it.DistributionUtils.assertEmptyFolder(
> DistributionUtils.java:300)
>   at
> org.apache.sling.distribution.it.DistributionIntegrationTestBase.chec
> kNoPackagesLeft(DistributionIntegrationTestBase.java:139)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(Framework
> Method.java:47)
>   at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCal
> lable.java:12)
>   at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMe
> thod.java:44)
>   at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.ja
> va:33)
>   at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun
> ner.java:70)
>   at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun
> ner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provide
> r.java:283)
>   at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUni
> t4Provider.java:173)
>   at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4
> Provider.java:153)
>   at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider
> .java:128)
>   at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameCla
> s

[GitHub] sling pull request #169: SLING-6045 Moving module to contrib/jcr

2016-09-27 Thread ghenzler
Github user ghenzler closed the pull request at:

https://github.com/apache/sling/pull/169


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (SLING-6045) Improve java package and GAV for oak restrictions

2016-09-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on SLING-6045:
---

Github user ghenzler closed the pull request at:

https://github.com/apache/sling/pull/169


> Improve java package and GAV for oak restrictions
> -
>
> Key: SLING-6045
> URL: https://issues.apache.org/jira/browse/SLING-6045
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Fix For: Oak Restrictions 1.0.0
>
>
> Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
> restrictions and it's placed under contrib/extensions . It should rather be 
> named org.apache.sling.oak.restrictions.



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


[jira] [Resolved] (SLING-6071) JcrModifiableValueMap#remove(key) breaks Map contract

2016-09-27 Thread Konrad Windszus (JIRA)

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

Konrad Windszus resolved SLING-6071.

   Resolution: Fixed
Fix Version/s: JCR Resource 2.8.2

Fixed in [r1762513|https://svn.apache.org/r1762513]. Thanks [~diru] for the 
contribution.

> JcrModifiableValueMap#remove(key) breaks Map contract
> -
>
> Key: SLING-6071
> URL: https://issues.apache.org/jira/browse/SLING-6071
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Resource 2.7.4
>Reporter: Dirk Rudolph
>Assignee: Konrad Windszus
> Fix For: JCR Resource 2.8.2
>
>
> From the contract of Map
> {quote}
> Returns the value to which this map previously associated the key, or null if 
> the map contained no mapping for the key.
> {quote}
> https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#remove-java.lang.Object-
> So my expectation is that I get the value object stored in the value map, but 
> the implementation returns an instance of JcrPropertyMapCacheEntry.
> Instead of returning this object the value from the internal valueCache 
> should be returned.



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


Re: Using FileSet in htl-maven-plugin

2016-09-27 Thread Konrad Windszus
Hi Radu,
I am no longer convinced this is a good idea: 
http://dev.eclipse.org/mhonarc/lists/m2e-users/msg05577.html 
.
Therefore I don't think it is worth the effort. Also I agree that dealing with 
default values is much harder then.
Sorry for the noise,
Konrad

> On 27 Sep 2016, at 18:06, Radu Cotescu  wrote:
> 
> Hi Konrad,
> 
> We could attempt to integrate FileSet into the HTL's plugin configuration,
> but what I don't like is that you're forced to specify a directory no
> matter what (or at least that's what I understand from the documentation).
> Could you send a patch? Then we could work together on this.
> 
> Thanks,
> Radu
> 
> On Mon, 26 Sep 2016 at 15:21 Konrad Windszus 
> wrote:
> 
>> Currently the goal "validate" of the htl-maven-plugin takes three
>> different parameters
>> 1. sourceDirectory
>> 2. includes
>> 3. excludes
>> 
>> That kind of triplet is already provided by the FileSet class (
>> http://maven.apache.org/shared/file-management/examples/mojo.html and
>> https://maven.apache.org/shared/file-management/fileset.html).
>> 
>> Quite some Maven Plugins use a file set already (e.g. Assembly descriptor,
>> at http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html or
>> maven-clean-plugin,
>> https://maven.apache.org/plugins/maven-clean-plugin/examples/delete_additional_files.html),
>> therefore I personally prefer to see the well-known FileSet type in a Maven
>> Site documentation rather than 3 different parameters, where I need to
>> figure out what kind of globbing is exactly supported.
>> 
>> Since we had a 1.0.0 release already what do you think about deprecating
>> the three previously mentioned parameters and instead just introduce a
>> Collection of FileSets?
>> That way you may provide multiple directories to be parsed and hopefully
>> more people will understand, how to use that properly.
>> 
>> Although not all properties from the FileSet are relevant to the
>> htl-maven-plugin and although the BuildContext.newScanner does not directly
>> take a FileSet as a parameter (
>> https://github.com/sonatype/sisu-build-api/blob/master/src/main/java/org/sonatype/plexus/build/incremental/BuildContext.java#L108)
>> I would still think that using the FileSet would make things clearer.
>> 
>> WDYT?
>> Thanks for your input,
>> Konrad



Re: Using FileSet in htl-maven-plugin

2016-09-27 Thread Radu Cotescu
Hi Konrad,

We could attempt to integrate FileSet into the HTL's plugin configuration,
but what I don't like is that you're forced to specify a directory no
matter what (or at least that's what I understand from the documentation).
Could you send a patch? Then we could work together on this.

Thanks,
Radu

On Mon, 26 Sep 2016 at 15:21 Konrad Windszus 
wrote:

> Currently the goal "validate" of the htl-maven-plugin takes three
> different parameters
> 1. sourceDirectory
> 2. includes
> 3. excludes
>
> That kind of triplet is already provided by the FileSet class (
> http://maven.apache.org/shared/file-management/examples/mojo.html and
> https://maven.apache.org/shared/file-management/fileset.html).
>
> Quite some Maven Plugins use a file set already (e.g. Assembly descriptor,
> at http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html or
> maven-clean-plugin,
> https://maven.apache.org/plugins/maven-clean-plugin/examples/delete_additional_files.html),
> therefore I personally prefer to see the well-known FileSet type in a Maven
> Site documentation rather than 3 different parameters, where I need to
> figure out what kind of globbing is exactly supported.
>
> Since we had a 1.0.0 release already what do you think about deprecating
> the three previously mentioned parameters and instead just introduce a
> Collection of FileSets?
> That way you may provide multiple directories to be parsed and hopefully
> more people will understand, how to use that properly.
>
> Although not all properties from the FileSet are relevant to the
> htl-maven-plugin and although the BuildContext.newScanner does not directly
> take a FileSet as a parameter (
> https://github.com/sonatype/sisu-build-api/blob/master/src/main/java/org/sonatype/plexus/build/incremental/BuildContext.java#L108)
> I would still think that using the FileSet would make things clearer.
>
> WDYT?
> Thanks for your input,
> Konrad


[jira] [Assigned] (SLING-6071) JcrModifiableValueMap#remove(key) breaks Map contract

2016-09-27 Thread Konrad Windszus (JIRA)

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

Konrad Windszus reassigned SLING-6071:
--

Assignee: Konrad Windszus

> JcrModifiableValueMap#remove(key) breaks Map contract
> -
>
> Key: SLING-6071
> URL: https://issues.apache.org/jira/browse/SLING-6071
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Resource 2.7.4
>Reporter: Dirk Rudolph
>Assignee: Konrad Windszus
>
> From the contract of Map
> {quote}
> Returns the value to which this map previously associated the key, or null if 
> the map contained no mapping for the key.
> {quote}
> https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#remove-java.lang.Object-
> So my expectation is that I get the value object stored in the value map, but 
> the implementation returns an instance of JcrPropertyMapCacheEntry.
> Instead of returning this object the value from the internal valueCache 
> should be returned.



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


[jira] [Commented] (SLING-6071) JcrModifiableValueMap#remove(key) breaks Map contract

2016-09-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on SLING-6071:
---

GitHub user Buuhuu opened a pull request:

https://github.com/apache/sling/pull/175

SLING-6071

 - returned value of valueCache instead of the one from cache
 - added unti test for the remove method

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Buuhuu/sling bugfix/SLING-6071(2)

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/175.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #175


commit 9cdb8538c22af469b80aecc0076367cc71d91045
Author: Dirk Rudolph 
Date:   2016-09-27T15:40:19Z

SLING-6071:
 - returned value of valueCache instead of the one from cache
 - added unti test for the remove method




> JcrModifiableValueMap#remove(key) breaks Map contract
> -
>
> Key: SLING-6071
> URL: https://issues.apache.org/jira/browse/SLING-6071
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Resource 2.7.4
>Reporter: Dirk Rudolph
>
> From the contract of Map
> {quote}
> Returns the value to which this map previously associated the key, or null if 
> the map contained no mapping for the key.
> {quote}
> https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#remove-java.lang.Object-
> So my expectation is that I get the value object stored in the value map, but 
> the implementation returns an instance of JcrPropertyMapCacheEntry.
> Instead of returning this object the value from the internal valueCache 
> should be returned.



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


[GitHub] sling pull request #175: SLING-6071

2016-09-27 Thread Buuhuu
GitHub user Buuhuu opened a pull request:

https://github.com/apache/sling/pull/175

SLING-6071

 - returned value of valueCache instead of the one from cache
 - added unti test for the remove method

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Buuhuu/sling bugfix/SLING-6071(2)

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/175.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #175


commit 9cdb8538c22af469b80aecc0076367cc71d91045
Author: Dirk Rudolph 
Date:   2016-09-27T15:40:19Z

SLING-6071:
 - returned value of valueCache instead of the one from cache
 - added unti test for the remove method




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Updated] (SLING-6071) JcrModifiableValueMap#remove(key) breaks Map contract

2016-09-27 Thread Dirk Rudolph (JIRA)

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

Dirk Rudolph updated SLING-6071:

Summary: JcrModifiableValueMap#remove(key) breaks Map 
contract  (was: JcrModifiableValueMap#remove(key) break Map 
contract)

> JcrModifiableValueMap#remove(key) breaks Map contract
> -
>
> Key: SLING-6071
> URL: https://issues.apache.org/jira/browse/SLING-6071
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Resource 2.7.4
>Reporter: Dirk Rudolph
>
> From the contract of Map
> {quote}
> Returns the value to which this map previously associated the key, or null if 
> the map contained no mapping for the key.
> {quote}
> https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#remove-java.lang.Object-
> So my expectation is that I get the value object stored in the value map, but 
> the implementation returns an instance of JcrPropertyMapCacheEntry.
> Instead of returning this object the value from the internal valueCache 
> should be returned.



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


[jira] [Created] (SLING-6071) JcrModifiableValueMap#remove(key) break Map contract

2016-09-27 Thread Dirk Rudolph (JIRA)
Dirk Rudolph created SLING-6071:
---

 Summary: JcrModifiableValueMap#remove(key) break Map contract
 Key: SLING-6071
 URL: https://issues.apache.org/jira/browse/SLING-6071
 Project: Sling
  Issue Type: Bug
Affects Versions: JCR Resource 2.7.4
Reporter: Dirk Rudolph


>From the contract of Map
{quote}
Returns the value to which this map previously associated the key, or null if 
the map contained no mapping for the key.
{quote}
https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#remove-java.lang.Object-

So my expectation is that I get the value object stored in the value map, but 
the implementation returns an instance of JcrPropertyMapCacheEntry.

Instead of returning this object the value from the internal valueCache should 
be returned.



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


[jira] [Commented] (SLING-6061) Create per-module Jenkins jobs

2016-09-27 Thread Robert Munteanu (JIRA)

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

Robert Munteanu commented on SLING-6061:


I've also migrated the distribution job from the contrib build since it 
currently fails. I think it's a good idea to separate out unstable or slow jobs 
first, as that gets us the best result in terms of CI performance / signal to 
noise ration.

> Create per-module Jenkins jobs
> --
>
> Key: SLING-6061
> URL: https://issues.apache.org/jira/browse/SLING-6061
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> As discussed on [dev@sling: CI alternatives for 
> Sling|http://markmail.org/message/mdn4anwe6kxqxa2z] we should investigate 
> generating per-module builds instead of having 'full' builds.
> The reason is that our currently large builds are slow and feedback is 
> useless since most of the times at least one module is failing.
> We will first prototype a build using the Jenkins [Job DSL 
> Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin], which 
> will allow us to programatically define what build jobs are generated and 
> their configuration.
> The proposed approach is to gradually transfer project from a large job to 
> per-module jobs, using the following mechanism ( details to be filled in ):
> * create a mechanism which will allow us to skip building some modules on 
> Jenkins
> * create a Jenkins DSL Job config in SVN which will generate builds for 
> specific modules ( the i18n module is a good candidate, since it is flaky on 
> Jenkins recently )
> * exclude the 'modularised' build modules from the main build
> In time, we will move out all bundle modules from the current reactor and we 
> should have the following main classes of build jobs:
> * bundles
> * launchpads ( main, contrib, etc )
> * utility modules ( testing )
> * integration tests
> * tooling/maven
> * tooling/ide
> Note that this does not exclude 'bigger' modules like for instance Sightly 
> which contain bundles, content and integration tests. At first I'd like to 
> get a feel of what solution is best for us.



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


Re: [VOTE] Release Apache Sling Discovery Commons 1.0.16 and Discovery Oak 1.2.14

2016-09-27 Thread Daniel Klco
+1

On Tue, Sep 27, 2016 at 8:47 AM, Stefan Egli  wrote:

> +1
>
> Cheers,
> Stefan
>
> On 26/09/16 12:08, "Stefan Egli"  wrote:
>
> >Hi,
> >
> >We solved 4 issues in these 2 related releases:
> >
> >https://issues.apache.org/jira/browse/SLING/fixforversion/12338296
> >https://issues.apache.org/jira/browse/SLING/fixforversion/12338297
> >
> >Staging repository:
> >https://repository.apache.org/content/repositories/orgapachesling-1526
> >
> >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 1526 /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.
> >
> >Cheers,
> >Stefan
> >
> >
>
>
>


[jira] [Resolved] (SLING-5309) Install OSGi subsystem through the maven-sling-plugin

2016-09-27 Thread Roy Teeuwen (JIRA)

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

Roy Teeuwen resolved SLING-5309.

Resolution: Won't Fix

No longer relevant seeing as AEM removed the subsystem feature

> Install OSGi subsystem through the maven-sling-plugin
> -
>
> Key: SLING-5309
> URL: https://issues.apache.org/jira/browse/SLING-5309
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Reporter: Roy Teeuwen
> Attachments: patch.diff
>
>
> Currently it is not possible to install OSGi subsystems through a maven 
> plugin. The maven-sling-plugin only supports bundles because it looks into 
> the MANIFEST.MF to check the bundle symbolic name



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


[jira] [Commented] (SLING-6061) Create per-module Jenkins jobs

2016-09-27 Thread Robert Munteanu (JIRA)

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

Robert Munteanu commented on SLING-6061:


I've excluded the i18n job from the main build. Nothing to do with the sling 
pipes build since it was not part of the contrib reactor.

> Create per-module Jenkins jobs
> --
>
> Key: SLING-6061
> URL: https://issues.apache.org/jira/browse/SLING-6061
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> As discussed on [dev@sling: CI alternatives for 
> Sling|http://markmail.org/message/mdn4anwe6kxqxa2z] we should investigate 
> generating per-module builds instead of having 'full' builds.
> The reason is that our currently large builds are slow and feedback is 
> useless since most of the times at least one module is failing.
> We will first prototype a build using the Jenkins [Job DSL 
> Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin], which 
> will allow us to programatically define what build jobs are generated and 
> their configuration.
> The proposed approach is to gradually transfer project from a large job to 
> per-module jobs, using the following mechanism ( details to be filled in ):
> * create a mechanism which will allow us to skip building some modules on 
> Jenkins
> * create a Jenkins DSL Job config in SVN which will generate builds for 
> specific modules ( the i18n module is a good candidate, since it is flaky on 
> Jenkins recently )
> * exclude the 'modularised' build modules from the main build
> In time, we will move out all bundle modules from the current reactor and we 
> should have the following main classes of build jobs:
> * bundles
> * launchpads ( main, contrib, etc )
> * utility modules ( testing )
> * integration tests
> * tooling/maven
> * tooling/ide
> Note that this does not exclude 'bigger' modules like for instance Sightly 
> which contain bundles, content and integration tests. At first I'd like to 
> get a feel of what solution is best for us.



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


Re: Error importing org.apache.sling.contextaware.config.impl into Eclipse

2016-09-27 Thread Konrad Windszus
I requested to remove the MavenBundlePluginConfigurator from the m2e-tycho 
extension (https://github.com/tesla/m2eclipse-tycho/issues/31 
). Hopefully they will 
update also the catalog listing to point to a newer release afterwards so that 
this extension does no longer conflict with Sling.

> On 27 Sep 2016, at 14:44, Konrad Windszus  wrote:
> 
> Thanks for that pointer. Indeed it seems related: 
> https://github.com/tesla/m2eclipse-tycho/blob/a096bd5549d46bbc7644a6e5f42938dd93336251/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/internal/OsgiBundleProjectConfigurator.java#L76
>  
> 
> In this case there seem to be two mojo executions for the maven-bundle-plugin.
> One is probably bundle (being configured through 
> https://github.com/apache/felix/blob/trunk/tools/maven-bundle-plugin/src/main/resources/META-INF/plexus/components.xml
>  
> ).
> and the other is goal "manifest" (for the generation of the manifest for 
> testing purposes).
> 
> I guess either we should recommend to uninstall the plugin or install a newer 
> version 
> (https://github.com/tesla/m2eclipse-tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/felix/internal/MavenBundlePluginConfigurator.java
>  
> ,
>  since the code has changed quite a bit since version 0.6.0). Installing 
> 0.9.0 from 
> https://repo1.maven.org/maven2/.m2e/connectors/m2eclipse-tycho/0.9.0/N/LATEST/
>  
> 
>  made the problem go away for me (but will still prefer the execution of the 
> m2e extension over the lifecycle binding from the plugin).
> 
> I couldn't find an easy way to update that within Eclipse without explicitly 
> trying the new p2 repo URL though.
> 
> 
>> On 27 Sep 2016, at 14:00, Robert Munteanu  wrote:
>> 
>> Hi Konrad,
>> 
>> On Tue, 2016-09-27 at 13:57 +0200, Konrad Windszus wrote:
>>> Whenever I import the Maven project from "https://github.com/apache/s
>>> ling/tree/trunk/contrib/extensions/contextaware-config/impl
>>> >> taware-config/impl>" I am getting an error in Eclipse:
>>> 
>>> java.lang.IllegalArgumentException
>>> at
>>> org.sonatype.tycho.m2e.internal.OsgiBundleProjectConfigurator.generat
>>> eBundleManifest(OsgiBundleProjectConfigurator.java:76)
>>> at
>>> 
>> 
>> (snip)
>> 
>> ISTR that this happened when duplicate executions or goals were
>> declared in the pom.xml, maybe check for that?
>> 
>> Robert
> 



[jira] [Commented] (SLING-6070) Reduce temporary storage required in JcrResourceListener, call reportChanges earlier

2016-09-27 Thread Stefan Egli (JIRA)

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

Stefan Egli commented on SLING-6070:


Depending on the outcome of OAK-4853 this might become obsolete

> Reduce temporary storage required in JcrResourceListener, call reportChanges 
> earlier
> 
>
> Key: SLING-6070
> URL: https://issues.apache.org/jira/browse/SLING-6070
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Resource 2.8.0
>Reporter: Stefan Egli
> Fix For: JCR Resource 2.8.2
>
>
> As noticed in OAK-4581 
> ([here|https://issues.apache.org/jira/browse/OAK-4581?focusedCommentId=15525601&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15525601])
>  one advantage of using OakResourceListener over JcrResourceListener (hence 
> the term 'optimize for oak' of the config parameter) is that 
> OakResourceListener uses a NodeObserver, which calls added/removed/changed 
> after each child traversal has finished. This will in turn be used by the 
> OakResourceListener to call ObservationReporter.reportChanges. In the 
> JcrResourceListener.onEvent case however this is not possible, as the events 
> are delivered for each node/property individually, and they first have to be 
> 'mapped' to ResourceChanges. This is currently done by keeping maps of 
> added/removed/changed ResourceChanges and only after all events (that are 
> passed in 1 onEvent) are processed is reportChanges invoked. This has the 
> downside of a potentially very large temporary memory usage (these maps can 
> get big).
> A suggested improvement is to follow the same pattern as is done in the 
> OakResourceListener/NodeObserver pair: to forward the events (by callling 
> reportChanges) as early as possible. Since Oak uses a breadth-first tree 
> traversal when compiling the jcr events, this fact can be used to detect the 
> earliest possible moment to forward events, which is as soon as a child 
> traversal has finished. That way, only parent changes need to be kept, not 
> the entire tree of changes.



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


[jira] [Resolved] (SLING-6045) Improve java package and GAV for oak restrictions

2016-09-27 Thread Robert Munteanu (JIRA)

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

Robert Munteanu resolved SLING-6045.

Resolution: Fixed

Applied in https://svn.apache.org/r1762476, thanks a lot for the contribution!

[~henzlerg] - what do you think about also renaming the directory from 
sling-oak-restrictions to oak-restrictions? The 'sling-' prefix is redundant now

> Improve java package and GAV for oak restrictions
> -
>
> Key: SLING-6045
> URL: https://issues.apache.org/jira/browse/SLING-6045
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Fix For: Oak Restrictions 1.0.0
>
>
> Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
> restrictions and it's placed under contrib/extensions . It should rather be 
> named org.apache.sling.oak.restrictions.



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


[jira] [Updated] (SLING-6045) Improve java package and GAV for oak restrictions

2016-09-27 Thread Robert Munteanu (JIRA)

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

Robert Munteanu updated SLING-6045:
---
Fix Version/s: Oak Restrictions 1.0.0

> Improve java package and GAV for oak restrictions
> -
>
> Key: SLING-6045
> URL: https://issues.apache.org/jira/browse/SLING-6045
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Fix For: Oak Restrictions 1.0.0
>
>
> Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
> restrictions and it's placed under contrib/extensions . It should rather be 
> named org.apache.sling.oak.restrictions.



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


Re: [VOTE] Release Apache Sling Discovery Commons 1.0.16 and Discovery Oak 1.2.14

2016-09-27 Thread Stefan Egli
+1

Cheers,
Stefan

On 26/09/16 12:08, "Stefan Egli"  wrote:

>Hi,
>
>We solved 4 issues in these 2 related releases:
>
>https://issues.apache.org/jira/browse/SLING/fixforversion/12338296
>https://issues.apache.org/jira/browse/SLING/fixforversion/12338297
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1526
>
>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 1526 /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.
>
>Cheers,
>Stefan
>
>




[jira] [Updated] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

2016-09-27 Thread Stefan Egli (JIRA)

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

Stefan Egli updated SLING-6056:
---
Fix Version/s: API 2.15.0
   JCR Resource 2.8.2

> achieve 1:1 mapping between observation and resource change listener
> 
>
> Key: SLING-6056
> URL: https://issues.apache.org/jira/browse/SLING-6056
> Project: Sling
>  Issue Type: Task
>  Components: ResourceResolver
>Affects Versions: JCR Resource 2.8.0, API 2.14.2, Resource Resolver 1.4.18
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Critical
> Fix For: JCR Resource 2.8.2, API 2.15.0, Resource Resolver 1.4.20
>
> Attachments: SLING-6056.patch
>
>
> At the moment it seems there is a 1:n mapping between 1 OakResourceListener 
> (and 1 BasicObservationReporter) and n ResourceChangeListeners. The idea 
> however is to get rid of such a bottleneck and have a 1:1 mapping (that might 
> or might not be in the BasicObservationReporter, that I don't know). We 
> should implement such a 1:1 mapping.
> See [thread on dev list|http://sling.markmail.org/thread/uwhda777psgklwo6]



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


Re: Error importing org.apache.sling.contextaware.config.impl into Eclipse

2016-09-27 Thread Konrad Windszus
Thanks for that pointer. Indeed it seems related: 
https://github.com/tesla/m2eclipse-tycho/blob/a096bd5549d46bbc7644a6e5f42938dd93336251/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/internal/OsgiBundleProjectConfigurator.java#L76
 

In this case there seem to be two mojo executions for the maven-bundle-plugin.
One is probably bundle (being configured through 
https://github.com/apache/felix/blob/trunk/tools/maven-bundle-plugin/src/main/resources/META-INF/plexus/components.xml
 
).
and the other is goal "manifest" (for the generation of the manifest for 
testing purposes).

I guess either we should recommend to uninstall the plugin or install a newer 
version 
(https://github.com/tesla/m2eclipse-tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/felix/internal/MavenBundlePluginConfigurator.java
 
,
 since the code has changed quite a bit since version 0.6.0). Installing 0.9.0 
from 
https://repo1.maven.org/maven2/.m2e/connectors/m2eclipse-tycho/0.9.0/N/LATEST/ 

 made the problem go away for me (but will still prefer the execution of the 
m2e extension over the lifecycle binding from the plugin).

I couldn't find an easy way to update that within Eclipse without explicitly 
trying the new p2 repo URL though.


> On 27 Sep 2016, at 14:00, Robert Munteanu  wrote:
> 
> Hi Konrad,
> 
> On Tue, 2016-09-27 at 13:57 +0200, Konrad Windszus wrote:
>> Whenever I import the Maven project from "https://github.com/apache/s
>> ling/tree/trunk/contrib/extensions/contextaware-config/impl
>> > taware-config/impl>" I am getting an error in Eclipse:
>> 
>> java.lang.IllegalArgumentException
>>  at
>> org.sonatype.tycho.m2e.internal.OsgiBundleProjectConfigurator.generat
>> eBundleManifest(OsgiBundleProjectConfigurator.java:76)
>>  at
>>  
> 
> (snip)
> 
> ISTR that this happened when duplicate executions or goals were
> declared in the pom.xml, maybe check for that?
> 
> Robert



[jira] [Updated] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

2016-09-27 Thread Stefan Egli (JIRA)

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

Stefan Egli updated SLING-6056:
---
Affects Version/s: JCR Resource 2.8.0
   API 2.14.2

> achieve 1:1 mapping between observation and resource change listener
> 
>
> Key: SLING-6056
> URL: https://issues.apache.org/jira/browse/SLING-6056
> Project: Sling
>  Issue Type: Task
>  Components: ResourceResolver
>Affects Versions: JCR Resource 2.8.0, API 2.14.2, Resource Resolver 1.4.18
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Critical
> Fix For: Resource Resolver 1.4.20
>
> Attachments: SLING-6056.patch
>
>
> At the moment it seems there is a 1:n mapping between 1 OakResourceListener 
> (and 1 BasicObservationReporter) and n ResourceChangeListeners. The idea 
> however is to get rid of such a bottleneck and have a 1:1 mapping (that might 
> or might not be in the BasicObservationReporter, that I don't know). We 
> should implement such a 1:1 mapping.
> See [thread on dev list|http://sling.markmail.org/thread/uwhda777psgklwo6]



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


[jira] [Commented] (SLING-6070) Reduce temporary storage required in JcrResourceListener, call reportChanges earlier

2016-09-27 Thread Stefan Egli (JIRA)

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

Stefan Egli commented on SLING-6070:


Open question here is: are we allowed to make this assumption that the events 
are ordered in a breadth-first manner? Or should we rather rewrite the 
OakResourceListener (or come up with a OakResourceListener2) that uses a Jcr 
EventListener and does this assumption? Perhaps doing it in the (theoretically) 
generic JcrResourceListener would be too tightly coupled with Oak

> Reduce temporary storage required in JcrResourceListener, call reportChanges 
> earlier
> 
>
> Key: SLING-6070
> URL: https://issues.apache.org/jira/browse/SLING-6070
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Resource 2.8.0
>Reporter: Stefan Egli
> Fix For: JCR Resource 2.8.2
>
>
> As noticed in OAK-4581 
> ([here|https://issues.apache.org/jira/browse/OAK-4581?focusedCommentId=15525601&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15525601])
>  one advantage of using OakResourceListener over JcrResourceListener (hence 
> the term 'optimize for oak' of the config parameter) is that 
> OakResourceListener uses a NodeObserver, which calls added/removed/changed 
> after each child traversal has finished. This will in turn be used by the 
> OakResourceListener to call ObservationReporter.reportChanges. In the 
> JcrResourceListener.onEvent case however this is not possible, as the events 
> are delivered for each node/property individually, and they first have to be 
> 'mapped' to ResourceChanges. This is currently done by keeping maps of 
> added/removed/changed ResourceChanges and only after all events (that are 
> passed in 1 onEvent) are processed is reportChanges invoked. This has the 
> downside of a potentially very large temporary memory usage (these maps can 
> get big).
> A suggested improvement is to follow the same pattern as is done in the 
> OakResourceListener/NodeObserver pair: to forward the events (by callling 
> reportChanges) as early as possible. Since Oak uses a breadth-first tree 
> traversal when compiling the jcr events, this fact can be used to detect the 
> earliest possible moment to forward events, which is as soon as a child 
> traversal has finished. That way, only parent changes need to be kept, not 
> the entire tree of changes.



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


[jira] [Created] (SLING-6070) Reduce temporary storage required in JcrResourceListener, call reportChanges earlier

2016-09-27 Thread Stefan Egli (JIRA)
Stefan Egli created SLING-6070:
--

 Summary: Reduce temporary storage required in JcrResourceListener, 
call reportChanges earlier
 Key: SLING-6070
 URL: https://issues.apache.org/jira/browse/SLING-6070
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Affects Versions: JCR Resource 2.8.0
Reporter: Stefan Egli
 Fix For: JCR Resource 2.8.2


As noticed in OAK-4581 
([here|https://issues.apache.org/jira/browse/OAK-4581?focusedCommentId=15525601&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15525601])
 one advantage of using OakResourceListener over JcrResourceListener (hence the 
term 'optimize for oak' of the config parameter) is that OakResourceListener 
uses a NodeObserver, which calls added/removed/changed after each child 
traversal has finished. This will in turn be used by the OakResourceListener to 
call ObservationReporter.reportChanges. In the JcrResourceListener.onEvent case 
however this is not possible, as the events are delivered for each 
node/property individually, and they first have to be 'mapped' to 
ResourceChanges. This is currently done by keeping maps of 
added/removed/changed ResourceChanges and only after all events (that are 
passed in 1 onEvent) are processed is reportChanges invoked. This has the 
downside of a potentially very large temporary memory usage (these maps can get 
big).

A suggested improvement is to follow the same pattern as is done in the 
OakResourceListener/NodeObserver pair: to forward the events (by callling 
reportChanges) as early as possible. Since Oak uses a breadth-first tree 
traversal when compiling the jcr events, this fact can be used to detect the 
earliest possible moment to forward events, which is as soon as a child 
traversal has finished. That way, only parent changes need to be kept, not the 
entire tree of changes.



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


[jira] [Created] (SLING-6069) Error: Multiple matches found for unary reference 'factory'

2016-09-27 Thread Christoph Thodte (JIRA)
Christoph Thodte created SLING-6069:
---

 Summary: Error: Multiple matches found for unary reference 
'factory' 
 Key: SLING-6069
 URL: https://issues.apache.org/jira/browse/SLING-6069
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: Testing Sling Mock Oak 2.0.2, Testing Sling Mock 2.1.0
Reporter: Christoph Thodte


When starting with a simple test using a the special rs type 
ResourceResolverType.JCR_OAK

{code:java}
public class FormularServiceTest {

@Rule
public final SlingContext slingContext = new 
SlingContext(ResourceResolverType.JCR_OAK);

@Test
public void testFormService() {
FormularService formularService = 
slingContext.registerInjectActivateService(new FormularService());
FormModel form = formularService.findFormByFormId("331");
Assert.assertNotNull(form);
}
...
{code}

I get the error 

org.apache.sling.testing.mock.osgi.ReferenceViolationException: Multiple 
matches found for unary reference 'factory' for class 
de.htsolutions.formver.service.FormularService

at 
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServiceReference(OsgiServiceUtil.java:416)
at 
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServices(OsgiServiceUtil.java:389)
at 
org.apache.sling.testing.mock.osgi.MockOsgi.injectServices(MockOsgi.java:146)

I debug the code and I find that the reason is that there are two 
resourceresolver in context not only one.

What's the problem here? Is it a bug? Problem in setup?




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


Re: Error importing org.apache.sling.contextaware.config.impl into Eclipse

2016-09-27 Thread Robert Munteanu
Hi Konrad,

On Tue, 2016-09-27 at 13:57 +0200, Konrad Windszus wrote:
> Whenever I import the Maven project from "https://github.com/apache/s
> ling/tree/trunk/contrib/extensions/contextaware-config/impl
>  taware-config/impl>" I am getting an error in Eclipse:
> 
> java.lang.IllegalArgumentException
>   at
> org.sonatype.tycho.m2e.internal.OsgiBundleProjectConfigurator.generat
> eBundleManifest(OsgiBundleProjectConfigurator.java:76)
>   at
> 

(snip)

ISTR that this happened when duplicate executions or goals were
declared in the pom.xml, maybe check for that?

Robert


Error importing org.apache.sling.contextaware.config.impl into Eclipse

2016-09-27 Thread Konrad Windszus
Whenever I import the Maven project from 
"https://github.com/apache/sling/tree/trunk/contrib/extensions/contextaware-config/impl
 
"
 I am getting an error in Eclipse:

java.lang.IllegalArgumentException
at 
org.sonatype.tycho.m2e.internal.OsgiBundleProjectConfigurator.generateBundleManifest(OsgiBundleProjectConfigurator.java:76)
at 
org.sonatype.tycho.m2e.internal.OsgiBundleProjectConfigurator.configureRawClasspath(OsgiBundleProjectConfigurator.java:178)
at 
org.eclipse.m2e.jdt.internal.AbstractJavaProjectConfigurator.invokeJavaProjectConfigurators(AbstractJavaProjectConfigurator.java:176)
at 
org.eclipse.m2e.jdt.internal.AbstractJavaProjectConfigurator.configure(AbstractJavaProjectConfigurator.java:132)
at 
org.eclipse.m2e.core.project.configurator.AbstractLifecycleMapping.configure(AbstractLifecycleMapping.java:120)
at 
org.eclipse.m2e.core.internal.project.ProjectConfigurationManager$3.call(ProjectConfigurationManager.java:501)
at 
org.eclipse.m2e.core.internal.project.ProjectConfigurationManager$3.call(ProjectConfigurationManager.java:1)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:151)
at 
org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:494)
at 
org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration0(ProjectConfigurationManager.java:432)
at 
org.eclipse.m2e.core.internal.project.ProjectConfigurationManager$2.call(ProjectConfigurationManager.java:345)
at 
org.eclipse.m2e.core.internal.project.ProjectConfigurationManager$2.call(ProjectConfigurationManager.java:1)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:151)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99)
at 
org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1351)
at 
org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:342)
at 
org.eclipse.m2e.core.ui.internal.UpdateMavenProjectJob.runInWorkspace(UpdateMavenProjectJob.java:77)
at 
org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Seems that the pom.xml is incompatible with m2eclipse-tycho 
(https://github.com/tesla/m2eclipse-tycho 
) in version 0.6.0.
Haven't looked into the details yet, but it would be good to come up with a 
workaround, as Eclipse will automatically try to install that m2e connector 
whenever it discovers a "bundle" packaging to be imported as this extension is 
listed in the catalog: 
https://github.com/takari/m2e-discovery-catalog/blob/master/org.eclipse.m2e.discovery.oss/src/main/resources-filtered/connectors.xml
 


Konrad

[jenkins] Per-module build jobs

2016-09-27 Thread Robert Munteanu
Hi,

I finished by POC for creating per-module build jobs, starting with

- bundles/extensions/i18n
- contrib/extensions/sling-pipes

These jobs are generated using the code from

  https://svn.apache.org/repos/asf/sling/trunk/tooling/jenkins/create_j
obs.groovy

This code in turn is invoked on Jenkins from a 'seed' job

  https://builds.apache.org/view/S-Z/view/Sling/job/sling-seed-build/

Given that the code is stored in SVN, it's enough to change the groovy
file to change the jobs managed by this seed job.

A few notes regarding job creation:

- jobs are created and updated as needed
- when a job is no longer found in the output it is disabled rather
than deleted, to make sure we retain history and are protected from
accidents

The resulting jobs are now at

- https://builds.apache.org/view/S-Z/view/Sling/job/sling-bundles-exten
sions-i18n-1.7/
- https://builds.apache.org/view/S-Z/view/Sling/job/sling-bundles-exten
sions-i18n-1.8/
- https://builds.apache.org/view/S-Z/view/Sling/job/sling-contrib-exten
sions-sling-pipes-1.8/

The i18n job is now excluded from the sling-trunk-1.{7,8} builds, to
prevent duplicate deployments and wasted time.

All the mechanisms are put into place to migrate to per-module builds
for bundles, we just need to decide if we want to go ahead with this
and whether we want to tweak the way the new jobs are configured at the
moment.

Thoughts?

Thanks,

Robert


[jira] [Commented] (SLING-920) Sling Jenkins setup

2016-09-27 Thread Robert Munteanu (JIRA)

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

Robert Munteanu commented on SLING-920:
---

The syntax is correct, but it seems that exclusions only work based on 
directory name, not on the artifact id, so I ended up using {{-pl 
!bundles/extensions/i18n}}

> Sling Jenkins setup
> ---
>
> Key: SLING-920
> URL: https://issues.apache.org/jira/browse/SLING-920
> Project: Sling
>  Issue Type: Task
>  Components: Testing
>Reporter: Bertrand Delacretaz
>
> Use this issue to record changes to the Jenkins setup at 
> https://builds.apache.org/view/S-Z/view/Sling/



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


[jira] [Commented] (SLING-920) Sling Jenkins setup

2016-09-27 Thread Robert Munteanu (JIRA)

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

Robert Munteanu commented on SLING-920:
---

Apparently the correct syntax is {{-pl !org.apache.sling.i18n}}

> Sling Jenkins setup
> ---
>
> Key: SLING-920
> URL: https://issues.apache.org/jira/browse/SLING-920
> Project: Sling
>  Issue Type: Task
>  Components: Testing
>Reporter: Bertrand Delacretaz
>
> Use this issue to record changes to the Jenkins setup at 
> https://builds.apache.org/view/S-Z/view/Sling/



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


Re: Build failed in Jenkins: sling-trunk-1.8 #4054

2016-09-27 Thread Robert Munteanu
On Tue, 2016-09-27 at 10:30 +, Apache Jenkins Server wrote:
> See 

...


> Waiting for Jenkins to finish collecting data[ERROR] Unknown
> lifecycle phase "l". You must specify a valid lifecycle phase or a
> goal in the format : or  id>:[:]:. Available
> lifecycle phases are: validate, initialize, generate-sources,
> process-sources, generate-resources, process-resources, compile,
> process-classes, generate-test-sources, process-test-sources,
> generate-test-resources, process-test-resources, test-compile,
> process-test-classes, test, prepare-package, package, pre-
> integration-test, integration-test, post-integration-test, verify,
> install, deploy, pre-clean, clean, post-clean, pre-site, site, post-
> site, site-deploy. -> [Help 1]

Sorry, that was my attempt to exclude modules from the reactor build,
I'll fix it.

Robert


[jira] [Updated] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

2016-09-27 Thread Stefan Egli (JIRA)

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

Stefan Egli updated SLING-6056:
---
Attachment: SLING-6056.patch

Attaching patch [^SLING-6056.patch] for review.
Note that I'm also suggesting to improve the consolidated listener stats with 
OAK-4855 and JCR-4032 such that the new ResourceChangeListeners become visible 
there.
/cc [~cziegeler], [~radu.cotescu]

> achieve 1:1 mapping between observation and resource change listener
> 
>
> Key: SLING-6056
> URL: https://issues.apache.org/jira/browse/SLING-6056
> Project: Sling
>  Issue Type: Task
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.4.18
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Critical
> Fix For: Resource Resolver 1.4.20
>
> Attachments: SLING-6056.patch
>
>
> At the moment it seems there is a 1:n mapping between 1 OakResourceListener 
> (and 1 BasicObservationReporter) and n ResourceChangeListeners. The idea 
> however is to get rid of such a bottleneck and have a 1:1 mapping (that might 
> or might not be in the BasicObservationReporter, that I don't know). We 
> should implement such a 1:1 mapping.
> See [thread on dev list|http://sling.markmail.org/thread/uwhda777psgklwo6]



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


[jira] [Commented] (SLING-920) Sling Jenkins setup

2016-09-27 Thread Robert Munteanu (JIRA)

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

Robert Munteanu commented on SLING-920:
---

Removed the org.apache.sling.i18n module from the sling-trunk-1.{7,8} jobs as 
it's being prototyped for an individual job.

This was done by adding {{-el org.apache.sling.i18n}} to the Maven invocation.

> Sling Jenkins setup
> ---
>
> Key: SLING-920
> URL: https://issues.apache.org/jira/browse/SLING-920
> Project: Sling
>  Issue Type: Task
>  Components: Testing
>Reporter: Bertrand Delacretaz
>
> Use this issue to record changes to the Jenkins setup at 
> https://builds.apache.org/view/S-Z/view/Sling/



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


[jira] [Commented] (SLING-920) Sling Jenkins setup

2016-09-27 Thread Robert Munteanu (JIRA)

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

Robert Munteanu commented on SLING-920:
---

Updated the Sling view to include all jobs whose name start with 'sling' to 
make it easy to include jobs generated by the Job DSL plugin

> Sling Jenkins setup
> ---
>
> Key: SLING-920
> URL: https://issues.apache.org/jira/browse/SLING-920
> Project: Sling
>  Issue Type: Task
>  Components: Testing
>Reporter: Bertrand Delacretaz
>
> Use this issue to record changes to the Jenkins setup at 
> https://builds.apache.org/view/S-Z/view/Sling/



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


[jira] [Commented] (SLING-6061) Create per-module Jenkins jobs

2016-09-27 Thread Robert Munteanu (JIRA)

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

Robert Munteanu commented on SLING-6061:


* Committed a initial version of the script in https://svn.apache.org/r1762420 .
* Linked this to a Jenkins job named 
https://builds.apache.org/view/S-Z/view/Sling/job/sling-seed-build/

This job has generated two jobs (for now, more will be added later)

* 
https://builds.apache.org/view/S-Z/view/Sling/job/sling-bundles-extensions-i18n/
* 
https://builds.apache.org/view/S-Z/view/Sling/job/sling-contrib-extensions-sling-pipes/

If these jobs work fine then I'll need to find a way to exclude them from their 
'reactor' builds.

> Create per-module Jenkins jobs
> --
>
> Key: SLING-6061
> URL: https://issues.apache.org/jira/browse/SLING-6061
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> As discussed on [dev@sling: CI alternatives for 
> Sling|http://markmail.org/message/mdn4anwe6kxqxa2z] we should investigate 
> generating per-module builds instead of having 'full' builds.
> The reason is that our currently large builds are slow and feedback is 
> useless since most of the times at least one module is failing.
> We will first prototype a build using the Jenkins [Job DSL 
> Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin], which 
> will allow us to programatically define what build jobs are generated and 
> their configuration.
> The proposed approach is to gradually transfer project from a large job to 
> per-module jobs, using the following mechanism ( details to be filled in ):
> * create a mechanism which will allow us to skip building some modules on 
> Jenkins
> * create a Jenkins DSL Job config in SVN which will generate builds for 
> specific modules ( the i18n module is a good candidate, since it is flaky on 
> Jenkins recently )
> * exclude the 'modularised' build modules from the main build
> In time, we will move out all bundle modules from the current reactor and we 
> should have the following main classes of build jobs:
> * bundles
> * launchpads ( main, contrib, etc )
> * utility modules ( testing )
> * integration tests
> * tooling/maven
> * tooling/ide
> Note that this does not exclude 'bigger' modules like for instance Sightly 
> which contain bundles, content and integration tests. At first I'd like to 
> get a feel of what solution is best for us.



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


[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

2016-09-27 Thread Stefan Egli (JIRA)

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

Stefan Egli commented on SLING-6056:


[~cziegeler], I can't see how it can be done isolated in sling.jcr.resource - I 
think it requires an api change in sling.api ({{List 
getObservationReporter()}}), which propagates to various other bundles as it 
means a version increase. But it is necessary since ObservationReporter is the 
one containing {{reportChanges}} - and the goal is to have the 
Jcr/OakResourceListener directly call the 'correct' reportChanges - ie a 1:1 
mapping between Jcr/OakResourceListener and ObservationReporter. And that can 
only be achieved (AFAICS) by changing the api..

> achieve 1:1 mapping between observation and resource change listener
> 
>
> Key: SLING-6056
> URL: https://issues.apache.org/jira/browse/SLING-6056
> Project: Sling
>  Issue Type: Task
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.4.18
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Critical
> Fix For: Resource Resolver 1.4.20
>
>
> At the moment it seems there is a 1:n mapping between 1 OakResourceListener 
> (and 1 BasicObservationReporter) and n ResourceChangeListeners. The idea 
> however is to get rid of such a bottleneck and have a 1:1 mapping (that might 
> or might not be in the BasicObservationReporter, that I don't know). We 
> should implement such a 1:1 mapping.
> See [thread on dev list|http://sling.markmail.org/thread/uwhda777psgklwo6]



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