[Jenkins] Sling » sling-org-apache-sling-starter » master #101 is BROKEN

2020-01-10 Thread Apache Jenkins Server
Please see 
https://builds.apache.org/job/Sling/job/sling-org-apache-sling-starter/job/master/101/
 for details.

No further emails will be sent until the status of the build is changed.
Build log follows below:

[...truncated 497 lines...]
[INFO] Building zip: 
/home/jenkins/jenkins-slave/workspace/-org-apache-sling-starter_master/target/org.apache.sling.starter-12-SNAPSHOT.jar
[INFO] Packaging webapp...
[INFO] Building zip: 
/home/jenkins/jenkins-slave/workspace/-org-apache-sling-starter_master/target/org.apache.sling.starter-12-SNAPSHOT.war
[INFO] 
[INFO] >>> maven-source-plugin:3.0.1:jar (attach-sources) > generate-sources @ 
org.apache.sling.starter >>>
[INFO] 
[INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce (enforce-maven-version) @ 
org.apache.sling.starter ---
[INFO] 
[INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce (enforce-property-values) @ 
org.apache.sling.starter ---
[INFO] 
[INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce (enforce-java-version) @ 
org.apache.sling.starter ---
[INFO] 
[INFO] --- jacoco-maven-plugin:0.8.3:prepare-agent (prepare-agent) @ 
org.apache.sling.starter ---
[INFO] argLine set to 
-javaagent:/home/jenkins/.m2/repository/org/jacoco/org.jacoco.agent/0.8.3/org.jacoco.agent-0.8.3-runtime.jar=destfile=/home/jenkins/jenkins-slave/workspace/-org-apache-sling-starter_master/target/jacoco-unit.exec
[INFO] 
[INFO] <<< maven-source-plugin:3.0.1:jar (attach-sources) < generate-sources @ 
org.apache.sling.starter <<<
[INFO] 
[INFO] 
[INFO] --- maven-source-plugin:3.0.1:jar (attach-sources) @ 
org.apache.sling.starter ---
[INFO] Building jar: 
/home/jenkins/jenkins-slave/workspace/-org-apache-sling-starter_master/target/org.apache.sling.starter-12-SNAPSHOT-sources.jar
[INFO] 
[INFO] --- maven-site-plugin:3.7.1:attach-descriptor (attach-descriptor) @ 
org.apache.sling.starter ---
[INFO] Skipping because packaging 'slingstart' is not pom.
[INFO] 
[INFO] --- jacoco-maven-plugin:0.8.3:prepare-agent-integration 
(prepare-agent-integration) @ org.apache.sling.starter ---
[INFO] argLine set to 
-javaagent:/home/jenkins/.m2/repository/org/jacoco/org.jacoco.agent/0.8.3/org.jacoco.agent-0.8.3-runtime.jar=destfile=/home/jenkins/jenkins-slave/workspace/-org-apache-sling-starter_master/target/jacoco-it.exec
[INFO] 
[INFO] --- slingstart-maven-plugin:1.8.2:start (start-container) @ 
org.apache.sling.starter ---
[INFO] Using launchpad jar being generated as this project's primary artifact: 
'/home/jenkins/jenkins-slave/workspace/-org-apache-sling-starter_master/target/org.apache.sling.starter-12-SNAPSHOT.jar'!
[INFO] Starting Launchpad _-40019...
Picked up JAVA_TOOL_OPTIONS: 
-Dmaven.ext.class.path="/home/jenkins/jenkins-slave/workspace/-org-apache-sling-starter_master@tmp/withMaven0cb91327/pipeline-maven-spy.jar"
 
-Dorg.jenkinsci.plugins.pipeline.maven.reportsFolder="/home/jenkins/jenkins-slave/workspace/-org-apache-sling-starter_master@tmp/withMaven0cb91327"
 
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; 
support was removed in 8.0
---
Slingstart application: 
/home/jenkins/jenkins-slave/workspace/-org-apache-sling-starter_master/target/_-40019/org.apache.sling.starter-12-SNAPSHOT.jar
Main class: org.apache.sling.launchpad.app.Main
Listener Port: 36117
Arguments: [-p, 40019, -j, 42833]
---
11.01.2020 07:52:43.027 *INFO * [main] Setting sling.home=sling (default)
11.01.2020 07:52:43.028 *INFO * [main] Starting Apache Sling in 
/home/jenkins/jenkins-slave/workspace/-org-apache-sling-starter_master/target/_-40019/sling
11.01.2020 07:52:43.036 *INFO * [main] Sling  Extension Lib Home : 
/home/jenkins/jenkins-slave/workspace/-org-apache-sling-starter_master/target/_-40019/sling/ext
11.01.2020 07:52:43.036 *INFO * [main] Checking launcher JAR in folder 
/home/jenkins/jenkins-slave/workspace/-org-apache-sling-starter_master/target/_-40019/sling
11.01.2020 07:52:43.048 *INFO * [main] Installing new launcher: 
jar:file:/home/jenkins/jenkins-slave/workspace/-org-apache-sling-starter_master/target/_-40019/org.apache.sling.starter-12-SNAPSHOT.jar!/resources/org.apache.sling.launchpad.base.jar,
 6.0.2.2_6_36 (org.apache.sling.launchpad.base.jar.1578729163048)
11.01.2020 07:52:43.049 *INFO * [main] Loading launcher class 
org.apache.sling.launchpad.base.app.MainDelegate from 
org.apache.sling.launchpad.base.jar.1578729163048
11.01.2020 07:52:43.049 *INFO * [main] External Libs Home (ext) is null or does 
not exists.
11.01.2020 07:52:43.063 *INFO * [main] Setting 
sling.launchpad=/home/jenkins/jenkins-slave/workspace/-org-apache-sling-starter_master/target/_-40019/sling
11.01.2020 07:52:43.064 *INFO * [main] Setting org.osgi.service.http.port=40019
11.01.2020 07:52:43.064 *INFO * [main] Setting sling.control.socket=42833
11.01.2020 07:52:43.064 *INFO * [main] Starting launcher ...
11.01.2020 07:52:43.072 *INFO * [main] HTTP server port: 40019

[jira] [Commented] (SLING-8974) Shows a 200 OK for a delete operation even if the node does not exist.

2020-01-10 Thread Eric Norman (Jira)


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

Eric Norman commented on SLING-8974:


Obviously, the ChangeLog of the response shouldn't include deleted items that 
did not actually exist so that looks wrong, but is this a problem with the 
documentation or the implementation?

I would find it quite strange for the response to be different when the path to 
delete is supplied via a ":applyTo" parameter versus the inferred path when no 
":applyTo" request parameter is supplied.

In other words, wouldn't it would be more consistent for these two requests to 
return an identical response?
$ curl -F":operation=delete" http://slinghosturl.com/content/invalid_node
{code:java}
$ curl -F":operation=delete" -F":applyTo=/content/invalid_node" 
http://slinghosturl.com/content/invalid_node{code}
{color:#172b4d}So my question is should the "delete" operation always silently 
fail for any invalid paths or return an error when any of the paths where not 
valid?  For backward compatibility it should ignore invalid paths silently, but 
perhaps there is some interest in more "strict" interpretation of the request 
parameters?{color}

 

> Shows a 200 OK for a delete operation even if the node does not exist.
> --
>
> Key: SLING-8974
> URL: https://issues.apache.org/jira/browse/SLING-8974
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Anisha Narang
>Priority: Major
> Fix For: Servlets POST 2.3.38
>
>
> When you try any curl query for a 'delete' operation, it shows a 200 OK even 
> even the node does not exist.
> curl query:
> {code:java}
> $ curl -F":operation=delete" http://slinghosturl.com/content/invalid_node
> 
> 
> Content modified /content/invalid_node
> 
> 
> Content modified /content/invalid_node
> 
> 
> 
> Status
> 200
> 
> 
> Message
> OK
> 
> 
> Location
>  id="Location">/invalid_node
> 
> 
> Parent Location
> /content
> 
> 
> Path
> /content/invalid_node
> 
> 
> Referer
> 
> 
> 
> ChangeLog
>  id="ChangeLog">predeleted(/content/invalid_node);br//pre
> 
> 
> 
> Modified Resource
> Parent of Modified Resource
> 
> {code}
> So, even though this node does not exist, there is a 200 OK response for the 
> same which is not expected as per the documentation here -> 
> [https://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#content-removal]
> Expected result:
> The response should be 404 not found if the not does not exist.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (SLING-8974) Shows a 200 OK for a delete operation even if the node does not exist.

2020-01-10 Thread Eric Norman (Jira)


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

Eric Norman edited comment on SLING-8974 at 1/10/20 9:20 PM:
-

Obviously, the ChangeLog of the response shouldn't include deleted items that 
did not actually exist so that looks wrong, but is this a problem with the 
documentation or the implementation?

I would find it quite strange for the response to be different when the path to 
delete is supplied via a ":applyTo" parameter versus the inferred path when no 
":applyTo" request parameter is supplied.

In other words, wouldn't it would be more consistent for these two requests to 
return an identical response?
{code:java}
$ curl -F":operation=delete" http://slinghosturl.com/content/invalid_node
{code}
{code:java}
$ curl -F":operation=delete" -F":applyTo=/content/invalid_node" 
http://slinghosturl.com/content/invalid_node{code}
{color:#172b4d}So my question is should the "delete" operation always silently 
fail for any invalid paths or return an error when any of the paths where not 
valid?  For backward compatibility it should ignore invalid paths silently, but 
perhaps there is some interest in more "strict" interpretation of the request 
parameters?{color}

 


was (Author: enorman):
Obviously, the ChangeLog of the response shouldn't include deleted items that 
did not actually exist so that looks wrong, but is this a problem with the 
documentation or the implementation?

I would find it quite strange for the response to be different when the path to 
delete is supplied via a ":applyTo" parameter versus the inferred path when no 
":applyTo" request parameter is supplied.

In other words, wouldn't it would be more consistent for these two requests to 
return an identical response?
{code:java}
$ curl -F":operation=delete" http://slinghosturl.com/content/invalid_node
{code}
[|http://slinghosturl.com/content/invalid_node]
{code:java}
$ curl -F":operation=delete" -F":applyTo=/content/invalid_node" 
http://slinghosturl.com/content/invalid_node{code}
{color:#172b4d}So my question is should the "delete" operation always silently 
fail for any invalid paths or return an error when any of the paths where not 
valid?  For backward compatibility it should ignore invalid paths silently, but 
perhaps there is some interest in more "strict" interpretation of the request 
parameters?{color}

 

> Shows a 200 OK for a delete operation even if the node does not exist.
> --
>
> Key: SLING-8974
> URL: https://issues.apache.org/jira/browse/SLING-8974
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Anisha Narang
>Priority: Major
> Fix For: Servlets POST 2.3.38
>
>
> When you try any curl query for a 'delete' operation, it shows a 200 OK even 
> even the node does not exist.
> curl query:
> {code:java}
> $ curl -F":operation=delete" http://slinghosturl.com/content/invalid_node
> 
> 
> Content modified /content/invalid_node
> 
> 
> Content modified /content/invalid_node
> 
> 
> 
> Status
> 200
> 
> 
> Message
> OK
> 
> 
> Location
>  id="Location">/invalid_node
> 
> 
> Parent Location
> /content
> 
> 
> Path
> /content/invalid_node
> 
> 
> Referer
> 
> 
> 
> ChangeLog
>  id="ChangeLog">predeleted(/content/invalid_node);br//pre
> 
> 
> 
> Modified Resource
> Parent of Modified Resource
> 
> {code}
> So, even though this node does not exist, there is a 200 OK response for the 
> same which is not expected as per the documentation here -> 
> [https://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#content-removal]
> Expected result:
> The response should be 404 not found if the not does not exist.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (SLING-8974) Shows a 200 OK for a delete operation even if the node does not exist.

2020-01-10 Thread Eric Norman (Jira)


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

Eric Norman edited comment on SLING-8974 at 1/10/20 9:19 PM:
-

Obviously, the ChangeLog of the response shouldn't include deleted items that 
did not actually exist so that looks wrong, but is this a problem with the 
documentation or the implementation?

I would find it quite strange for the response to be different when the path to 
delete is supplied via a ":applyTo" parameter versus the inferred path when no 
":applyTo" request parameter is supplied.

In other words, wouldn't it would be more consistent for these two requests to 
return an identical response?
{code:java}
$ curl -F":operation=delete" http://slinghosturl.com/content/invalid_node
{code}
[|http://slinghosturl.com/content/invalid_node]
{code:java}
$ curl -F":operation=delete" -F":applyTo=/content/invalid_node" 
http://slinghosturl.com/content/invalid_node{code}
{color:#172b4d}So my question is should the "delete" operation always silently 
fail for any invalid paths or return an error when any of the paths where not 
valid?  For backward compatibility it should ignore invalid paths silently, but 
perhaps there is some interest in more "strict" interpretation of the request 
parameters?{color}

 


was (Author: enorman):
Obviously, the ChangeLog of the response shouldn't include deleted items that 
did not actually exist so that looks wrong, but is this a problem with the 
documentation or the implementation?

I would find it quite strange for the response to be different when the path to 
delete is supplied via a ":applyTo" parameter versus the inferred path when no 
":applyTo" request parameter is supplied.

In other words, wouldn't it would be more consistent for these two requests to 
return an identical response?
$ curl -F":operation=delete" http://slinghosturl.com/content/invalid_node
{code:java}
$ curl -F":operation=delete" -F":applyTo=/content/invalid_node" 
http://slinghosturl.com/content/invalid_node{code}
{color:#172b4d}So my question is should the "delete" operation always silently 
fail for any invalid paths or return an error when any of the paths where not 
valid?  For backward compatibility it should ignore invalid paths silently, but 
perhaps there is some interest in more "strict" interpretation of the request 
parameters?{color}

 

> Shows a 200 OK for a delete operation even if the node does not exist.
> --
>
> Key: SLING-8974
> URL: https://issues.apache.org/jira/browse/SLING-8974
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Anisha Narang
>Priority: Major
> Fix For: Servlets POST 2.3.38
>
>
> When you try any curl query for a 'delete' operation, it shows a 200 OK even 
> even the node does not exist.
> curl query:
> {code:java}
> $ curl -F":operation=delete" http://slinghosturl.com/content/invalid_node
> 
> 
> Content modified /content/invalid_node
> 
> 
> Content modified /content/invalid_node
> 
> 
> 
> Status
> 200
> 
> 
> Message
> OK
> 
> 
> Location
>  id="Location">/invalid_node
> 
> 
> Parent Location
> /content
> 
> 
> Path
> /content/invalid_node
> 
> 
> Referer
> 
> 
> 
> ChangeLog
>  id="ChangeLog">predeleted(/content/invalid_node);br//pre
> 
> 
> 
> Modified Resource
> Parent of Modified Resource
> 
> {code}
> So, even though this node does not exist, there is a 200 OK response for the 
> same which is not expected as per the documentation here -> 
> [https://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#content-removal]
> Expected result:
> The response should be 404 not found if the not does not exist.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (SLING-8974) Shows a 200 OK for a delete operation even if the node does not exist.

2020-01-10 Thread Eric Norman (Jira)


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

Eric Norman edited comment on SLING-8974 at 1/10/20 9:24 PM:
-

Obviously, the ChangeLog of the response shouldn't include deleted items that 
did not actually exist so that looks wrong, but is this a problem with the 
documentation or the implementation?

I would find it quite strange for the response to be different when the path to 
delete is supplied via a ":applyTo" parameter versus the inferred path when no 
":applyTo" request parameter is supplied.

In other words, wouldn't it would be more consistent for these two requests to 
return an identical response?
{code:java}
$ curl -F":operation=delete" http://slinghosturl.com/content/invalid_node
{code}
{code:java}
$ curl -F":operation=delete" -F":applyTo=/content/invalid_node" 
http://slinghosturl.com/content/invalid_node{code}
{color:#172b4d}So my question is should the "delete" operation always silently 
fail for any invalid paths or return an error when any of the paths were not 
valid?  For backward compatibility it should ignore invalid paths silently, but 
perhaps there is some interest in more "strict" interpretation of the request 
parameters?{color}

 


was (Author: enorman):
Obviously, the ChangeLog of the response shouldn't include deleted items that 
did not actually exist so that looks wrong, but is this a problem with the 
documentation or the implementation?

I would find it quite strange for the response to be different when the path to 
delete is supplied via a ":applyTo" parameter versus the inferred path when no 
":applyTo" request parameter is supplied.

In other words, wouldn't it would be more consistent for these two requests to 
return an identical response?
{code:java}
$ curl -F":operation=delete" http://slinghosturl.com/content/invalid_node
{code}
{code:java}
$ curl -F":operation=delete" -F":applyTo=/content/invalid_node" 
http://slinghosturl.com/content/invalid_node{code}
{color:#172b4d}So my question is should the "delete" operation always silently 
fail for any invalid paths or return an error when any of the paths where not 
valid?  For backward compatibility it should ignore invalid paths silently, but 
perhaps there is some interest in more "strict" interpretation of the request 
parameters?{color}

 

> Shows a 200 OK for a delete operation even if the node does not exist.
> --
>
> Key: SLING-8974
> URL: https://issues.apache.org/jira/browse/SLING-8974
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Anisha Narang
>Priority: Major
> Fix For: Servlets POST 2.3.38
>
>
> When you try any curl query for a 'delete' operation, it shows a 200 OK even 
> even the node does not exist.
> curl query:
> {code:java}
> $ curl -F":operation=delete" http://slinghosturl.com/content/invalid_node
> 
> 
> Content modified /content/invalid_node
> 
> 
> Content modified /content/invalid_node
> 
> 
> 
> Status
> 200
> 
> 
> Message
> OK
> 
> 
> Location
>  id="Location">/invalid_node
> 
> 
> Parent Location
> /content
> 
> 
> Path
> /content/invalid_node
> 
> 
> Referer
> 
> 
> 
> ChangeLog
>  id="ChangeLog">predeleted(/content/invalid_node);br//pre
> 
> 
> 
> Modified Resource
> Parent of Modified Resource
> 
> {code}
> So, even though this node does not exist, there is a 200 OK response for the 
> same which is not expected as per the documentation here -> 
> [https://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#content-removal]
> Expected result:
> The response should be 404 not found if the not does not exist.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (SLING-8988) Remove NoSQL features

2020-01-10 Thread Oliver Lietz (Jira)
Oliver Lietz created SLING-8988:
---

 Summary: Remove NoSQL features
 Key: SLING-8988
 URL: https://issues.apache.org/jira/browse/SLING-8988
 Project: Sling
  Issue Type: Task
  Components: Karaf
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: Karaf Features 0.2.0, Karaf Integration Tests 0.2.0, 
Karaf Distribution 0.2.0, Karaf Configs 0.2.0






--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[VOTE] Release Apache Sling Feature Model Converter Plugin 1.0.4

2020-01-10 Thread Andreas Schaefer
Hi

This is the initial release of the Sling Feature Model Converter Plugin that is 
the Maven frontend to the Content Package Converter module allowing a developer 
to convert its CP module into a Feature Model to be used later in a Feature 
Launch.
This release contains a fix for failures in the IT tests on Jenkins in the last 
attempt to release this plugin.

We solve 2 issues in this release:

https://issues.apache.org/jira/projects/SLING/versions/12346749 


Staging Repository:

https://repository.apache.org/content/repositories/orgapachesling-2184 


You can use this UNIX script to download the release and verify the signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
 


Usage:
sh check_staged_release.sh 2184 /tmp/sling-staging

Please vote to approve this release:

 [ ] +1 Approve the release
 [ ]  0 Don't care
 [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards,
Andreas Schaefer

[jira] [Commented] (SLING-7760) Sling Main Servlet - Change header configuration to a service

2020-01-10 Thread Jason Bailey (Jira)


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

Jason Bailey commented on SLING-7760:
-

[~cziegeler] that would be a great step in the right direction. The reason why 
I would eventually like to see it service based is that problem I'm having with 
different headers being required for different domains that are all ran out of 
one instance of AEM. As well as doing cool things with expiration headers and 
security headers.

> Sling Main Servlet - Change header configuration to a service
> -
>
> Key: SLING-7760
> URL: https://issues.apache.org/jira/browse/SLING-7760
> Project: Sling
>  Issue Type: Improvement
>Reporter: Jason E Bailey
>Assignee: Jason E Bailey
>Priority: Major
>
> The ability to set headers must be done prior to any writing that occurs the 
> output stream. This is the reason why the headers are set to be configured in 
> the Sling Main Servlet.
> With Sling being used to maintain multiple sites, having a single set of 
> response headers creates problems where the header provides a non tailored 
> response. One site may have a conflicting set of requirements then another 
> site.
> If the setting of headers was moved from being a configuration to being a 
> service used by the Main Servlet, this would allow the following:
>  * Headers set on a per site basis
>  * Headers based on selected resource
>  * Ability to modify the headers without causing the restart of the Sling 
> Main Servlet
>  ** Which if you're dealing with CSP headers can be a constant pain
>  * Ability to create a CSP configuration Service that eases the use of CSP 
> creation
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: [VOTE] Release Sling Apache Feature Model Converter 1.0.10, Content-Package to Feature Model Converter 1.0.6 and Slingstart Maven Plugin 1.9.6

2020-01-10 Thread Andreas Schaefer
+1 (non-binding)

- Andy

> On Jan 10, 2020, at 3:20 AM, dav...@apache.org wrote:
> 
> Hi all,
> 
> I would like to call the release on the following Sling Apache components:
> Feature Model Converter 1.0.10
> Solved issues:
> https://issues.apache.org/jira/projects/SLING/versions/12346747
> 
> Content-Package to Feature Model Converter 1.0.6
> Solved issues:
> https://issues.apache.org/jira/projects/SLING/versions/12346742
> 
> Slingstart Maven Plugin 1.9.6
> Solved issues:
> https://issues.apache.org/jira/projects/SLING/versions/12346652
> 
> We fixed the following issue:
> https://issues.apache.org/jira/projects/SLING/versions/12346630
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-2183
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
> 
> Usage:
> sh check_staged_release.sh 2183 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>   [ ] +1 Approve the release
>   [ ] -1 Don't release, because ...
> 
> This majority vote is open for at least 72 hours.
> 
> Best regards,
> 
> David



[jira] [Commented] (SLING-7760) Sling Main Servlet - Change header configuration to a service

2020-01-10 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler commented on SLING-7760:
-

Just as a side comment - we can change the implementation to not restart the 
main servlet if the configuration changes

> Sling Main Servlet - Change header configuration to a service
> -
>
> Key: SLING-7760
> URL: https://issues.apache.org/jira/browse/SLING-7760
> Project: Sling
>  Issue Type: Improvement
>Reporter: Jason E Bailey
>Assignee: Jason E Bailey
>Priority: Major
>
> The ability to set headers must be done prior to any writing that occurs the 
> output stream. This is the reason why the headers are set to be configured in 
> the Sling Main Servlet.
> With Sling being used to maintain multiple sites, having a single set of 
> response headers creates problems where the header provides a non tailored 
> response. One site may have a conflicting set of requirements then another 
> site.
> If the setting of headers was moved from being a configuration to being a 
> service used by the Main Servlet, this would allow the following:
>  * Headers set on a per site basis
>  * Headers based on selected resource
>  * Ability to modify the headers without causing the restart of the Sling 
> Main Servlet
>  ** Which if you're dealing with CSP headers can be a constant pain
>  * Ability to create a CSP configuration Service that eases the use of CSP 
> creation
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SLING-7768) Add String Interpolation support to /etc/map

2020-01-10 Thread Carsten Ziegeler (Jira)


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

Carsten Ziegeler commented on SLING-7768:
-

I had a brief look at the PR. I think we don't need an interface, there 
shouldn't be a need to make the interpolation pluggable.
>From a syntax point of view, it would be nice if we could support the same 
>syntax as the configuration admin interpolation plugin which is 
{noformat}
 $[proptype:propname]
 $[proptype:propname;default=foo]
{noformat}
where proptype can be secret, env, or prop - we probably don't need to support 
"secret", env gets a value from the named env variable and prop from the bundle 
context. If no proptype prefix is used it could fallback to the provided 
configuration.

Not sure if we can use square brackets in JCR node names; if we can't we need 
to stick with angle brackets.
But we should support the proptype and default values

> Add String Interpolation support to /etc/map
> 
>
> Key: SLING-7768
> URL: https://issues.apache.org/jira/browse/SLING-7768
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
> Environment: Sling 11-SNAPSHOT, JDK 1.8
>Reporter: Andreas Schaefer
>Priority: Major
> Attachments: Screenshot 2018-07-06 11.41.58.png, Screenshot 
> 2018-07-06 11.42.41.png, Screenshot 2018-07-06 11.43.34.png
>
>
> Having worked on migrations of a Sling derivate Ruben & I ran into issues 
> where the /etc/map would map to production instead of testing environment.
>  Many big customer have extensive /etc/maps and also many different 
> environments like dev, qa, staging, prod etc.
>  It would be great to have a tool where for example items like the host name 
> or external links in /etc/map could be configured outside so that just one 
> entry has to adjusted rather than creating a full copy of the /etc/map tree.
>   
>  Example:
>   
>  /etc/map/http/phv.fq.host.name.8080
>   
>  Placeholder provides:
>  DEV: phv.fq.host.name=localhost
>  QA: phv.fq.host.name=qa.author.acme.com
>  STAGING: 
> phv.fq.host.name=[staging.author.acme.com|http://staging.author.acme.com/]
>  PROD: phv.fq.host.name=[acme.com|http://acme.com/]
>   
>  At runtime these are the resolved values:
>  DEV: http/localhost.8080
>  QA: http/qa.author.acme.com.8080
>  STAGING: http/[staging.author.acme.com|http://staging.author.acme.com/].8080
>  PROD: http/[acme.com|http://acme.com/].8080
>   
>  Not only does that make it easier and faster to create new test environments 
> but it also cuts down on the chance of copy-n-paste errors.
>   
>  I have a working POC with an PlaceholderProvider OSGi service and an 
> enhanced MapEntries that resolved any placeholders if found.
>   
>  Attached are 3 screenshots:
>  1. OSGi Placeholder Provider Configuration
>  2. /etc/map (Composum)
>  3. Result of [http://andreass.local:8080/] call



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (SLING-7760) Sling Main Servlet - Change header configuration to a service

2020-01-10 Thread Jason Bailey (Jira)


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

Jason Bailey updated SLING-7760:

Description: 
The ability to set headers must be done prior to any writing that occurs the 
output stream. This is the reason why the headers are set to be configured in 
the Sling Main Servlet.

With Sling being used to maintain multiple sites, having a single set of 
response headers creates problems where the header provides a non tailored 
response. One site may have a conflicting set of requirements then another site.

If the setting of headers was moved from being a configuration to being a 
service used by the Main Servlet, this would allow the following:
 * Headers set on a per site basis
 * Headers based on selected resource
 * Ability to modify the headers without causing the restart of the Sling Main 
Servlet
 ** Which if you're dealing with CSP headers can be a constant pain
 * Ability to create a CSP configuration Service that eases the use of CSP 
creation

 

 

  was:
Currently, for us to set the global response headers we need to add these to 
the Sling Main Servlet.

The problem with this is
 * Any changes to the Sling Main Servlet ends up with the service restarting. 
This has a negative overall effect to the environment
 * We run multiple domains out of a single instance. For a 
Content-Security-Header we end up putting in exemptions that should apply to 
one site for all sites. This is problematic from a security perspective

Ideally we would be able to configure headers based on the domain that's being 
requested


> Sling Main Servlet - Change header configuration to a service
> -
>
> Key: SLING-7760
> URL: https://issues.apache.org/jira/browse/SLING-7760
> Project: Sling
>  Issue Type: Improvement
>Reporter: Jason E Bailey
>Assignee: Jason E Bailey
>Priority: Major
>
> The ability to set headers must be done prior to any writing that occurs the 
> output stream. This is the reason why the headers are set to be configured in 
> the Sling Main Servlet.
> With Sling being used to maintain multiple sites, having a single set of 
> response headers creates problems where the header provides a non tailored 
> response. One site may have a conflicting set of requirements then another 
> site.
> If the setting of headers was moved from being a configuration to being a 
> service used by the Main Servlet, this would allow the following:
>  * Headers set on a per site basis
>  * Headers based on selected resource
>  * Ability to modify the headers without causing the restart of the Sling 
> Main Servlet
>  ** Which if you're dealing with CSP headers can be a constant pain
>  * Ability to create a CSP configuration Service that eases the use of CSP 
> creation
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (SLING-7760) Sling Main Servlet - Change header configuration to a service

2020-01-10 Thread Jason Bailey (Jira)


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

Jason Bailey updated SLING-7760:

Summary: Sling Main Servlet - Change header configuration to a service  
(was: Contextual Additional Response Headers)

> Sling Main Servlet - Change header configuration to a service
> -
>
> Key: SLING-7760
> URL: https://issues.apache.org/jira/browse/SLING-7760
> Project: Sling
>  Issue Type: Improvement
>Reporter: Jason E Bailey
>Assignee: Jason E Bailey
>Priority: Major
>
> Currently, for us to set the global response headers we need to add these to 
> the Sling Main Servlet.
> The problem with this is
>  * Any changes to the Sling Main Servlet ends up with the service restarting. 
> This has a negative overall effect to the environment
>  * We run multiple domains out of a single instance. For a 
> Content-Security-Header we end up putting in exemptions that should apply to 
> one site for all sites. This is problematic from a security perspective
> Ideally we would be able to configure headers based on the domain that's 
> being requested



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SLING-8987) Review exported packages

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu commented on SLING-8987:


Thanks to both of you for the comments. I'll try and gather some more feedback 
on https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/12 
(and also on the Sling user's list ) before committing and merging the release.

> Review exported packages
> 
>
> Key: SLING-8987
> URL: https://issues.apache.org/jira/browse/SLING-8987
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Robert Munteanu
>Priority: Critical
> Fix For: Dynamic Include 3.1.8
>
>
> With SLING-8982 changes that were supposed to be transparent to the consumers 
> have bled into the API. We should review what really needs to be exported (if 
> anything).  My hunch is that we actually don't need to export anything, but 
> that should be validated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [sling-org-apache-sling-dynamic-include] sonarcloud[bot] commented on issue #12: SLING-8982 - dynamic-include: upgrade to parent pom 35

2020-01-10 Thread GitBox
sonarcloud[bot] commented on issue #12: SLING-8982 - dynamic-include: upgrade 
to parent pom 35
URL: 
https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/12#issuecomment-573054456
 
 
   SonarCloud Quality Gate failed.
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-dynamic-include=12=false=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-dynamic-include=12=false=BUG)
 [1 
Bug](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-dynamic-include=12=false=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-dynamic-include=12=false=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-dynamic-include=12=false=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-dynamic-include=12=false=VULNERABILITY)
 (and [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-dynamic-include=12=false=SECURITY_HOTSPOT)
 [0 Security 
Hotspots](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-dynamic-include=12=false=SECURITY_HOTSPOT)
 to review)  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-dynamic-include=12=false=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-dynamic-include=12=false=CODE_SMELL)
 [17 Code 
Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-dynamic-include=12=false=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-dynamic-include=12=new_coverage=list)
 [0.0% 
Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-dynamic-include=12=new_coverage=list)
  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-dynamic-include=12=new_duplicated_lines_density=list)
 [0.0% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-dynamic-include=12=new_duplicated_lines_density=list)
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [sling-org-apache-sling-dynamic-include] rombert commented on issue #12: SLING-8982 - dynamic-include: upgrade to parent pom 35

2020-01-10 Thread GitBox
rombert commented on issue #12: SLING-8982 - dynamic-include: upgrade to parent 
pom 35
URL: 
https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/12#issuecomment-573054240
 
 
   Based on the discussion from 
[SLING-8987](https://issues.apache.org/jira/browse/SLING-8987) I've removed 
**all** package exports. My assumption is that none are actually used, but I'll 
wait for more feedback before proceeding.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Commented] (SLING-8987) Review exported packages

2020-01-10 Thread Jira


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

Tomasz Niedźwiedź commented on SLING-8987:
--

Hi [~rombert], I've never felt the need to import a package from SDI. As you 
say, we install it and configure it accordingly.

> Review exported packages
> 
>
> Key: SLING-8987
> URL: https://issues.apache.org/jira/browse/SLING-8987
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Robert Munteanu
>Priority: Critical
> Fix For: Dynamic Include 3.1.8
>
>
> With SLING-8982 changes that were supposed to be transparent to the consumers 
> have bled into the API. We should review what really needs to be exported (if 
> anything).  My hunch is that we actually don't need to export anything, but 
> that should be validated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SLING-8987) Review exported packages

2020-01-10 Thread Jira


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

Tomek Rękawek commented on SLING-8987:
--

[~rombert] - I think the SDI is a standalone bundle (not meant to be exported), 
but maybe [~tomasz.k.niedzwi...@gmail.com] can share some recent usage patterns 
from the production.

> Review exported packages
> 
>
> Key: SLING-8987
> URL: https://issues.apache.org/jira/browse/SLING-8987
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Robert Munteanu
>Priority: Critical
> Fix For: Dynamic Include 3.1.8
>
>
> With SLING-8982 changes that were supposed to be transparent to the consumers 
> have bled into the API. We should review what really needs to be exported (if 
> anything).  My hunch is that we actually don't need to export anything, but 
> that should be validated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[Jenkins] Sling » sling-org-apache-sling-launchpad-testing » master #512 is BROKEN

2020-01-10 Thread Apache Jenkins Server
jar"
 
-Dorg.jenkinsci.plugins.pipeline.maven.reportsFolder="/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master@tmp/withMaven3abe8cc9"
 
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 
2019-08-27T15:06:16Z)
Maven home: /home/jenkins/tools/maven/latest
Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: 
/usr/local/asfpackages/java/jdk1.8.0_191/jre
Default locale: en_US, platform encoding: ISO-8859-1
OS name: "linux", version: "4.4.0-164-generic", arch: "amd64", family: "unix"
[INFO] [jenkins-event-spy] Generate 
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master@tmp/withMaven3abe8cc9/maven-spy-20200110-132326-6572712300660467901362.log.tmp
 ...
[INFO] Scanning for projects...
[INFO] [jenkins-event-spy] Generated 
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master@tmp/withMaven3abe8cc9/maven-spy-20200110-132326-6572712300660467901362.log
[ERROR] Unable to get artifact for Dependency {groupId=org.apache.sling, 
artifactId=org.apache.sling.launchpad.test-bundles, version=12-SNAPSHOT, 
type=slingfeature}: Could not find artifact 
org.apache.sling:org.apache.sling.launchpad.test-bundles:txt:12-SNAPSHOT
[ERROR] 
[ERROR] Try downloading the file manually from the project website.
[ERROR] 
[ERROR] Then, install it using the command: 
[ERROR] mvn install:install-file -DgroupId=org.apache.sling 
-DartifactId=org.apache.sling.launchpad.test-bundles -Dversion=12-SNAPSHOT 
-Dpackaging=slingfeature -Dfile=/path/to/file
[ERROR] 
[ERROR] Alternatively, if you host your own repository you can deploy the file 
there: 
[ERROR] mvn deploy:deploy-file -DgroupId=org.apache.sling 
-DartifactId=org.apache.sling.launchpad.test-bundles -Dversion=12-SNAPSHOT 
-Dpackaging=slingfeature -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
[ERROR] 
[ERROR] 
[ERROR]   
org.apache.sling:org.apache.sling.launchpad.test-bundles:slingfeature:12-SNAPSHOT
[ERROR] 
[ERROR] from the specified remote repositories:
[ERROR]   central (https://repo.maven.apache.org/maven2, releases=true, 
snapshots=false)
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
[Pipeline] }
[withMaven] Publishers: Generated Artifacts Publisher: 1018 ms
[Pipeline] // withMaven
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // timeout
[Pipeline] stage
[Pipeline] { (Notifications)
[Pipeline] echo
Status change is BROKEN, notifications will be sent.
[Pipeline] emailext

Re: Retire feature application builder

2020-01-10 Thread Carsten Ziegeler

Thanks Bertrand

I plan to get it removed, unless someone objects. This reduces the 
number of our repositories :)


Carsten

On 10.01.2020 12:15, Bertrand Delacretaz wrote:

Hi,

On Thu, Jan 9, 2020 at 9:27 AM Carsten Ziegeler  wrote:

...I think we should retire it. What is the process for that ?
As we never released it, we can probably just delete it?...


In case you decide to keep it but mark it deprecated (I have no
opinion on that myself) I have moved the documentation of the
deprecating procedure discussed at few months ago at
https://sling.apache.org/documentation/development/deprecating-sling-modules.html

-Bertrand



--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


Re: [VOTE] Release Sling Apache Feature Model Converter 1.0.10, Content-Package to Feature Model Converter 1.0.6 and Slingstart Maven Plugin 1.9.6

2020-01-10 Thread Carsten Ziegeler

+1

Carsten

On 10.01.2020 12:20, dav...@apache.org wrote:

Hi all,

I would like to call the release on the following Sling Apache components:
Feature Model Converter 1.0.10
Solved issues:
https://issues.apache.org/jira/projects/SLING/versions/12346747

Content-Package to Feature Model Converter 1.0.6
Solved issues:
https://issues.apache.org/jira/projects/SLING/versions/12346742

Slingstart Maven Plugin 1.9.6
Solved issues:
https://issues.apache.org/jira/projects/SLING/versions/12346652

We fixed the following issue:
https://issues.apache.org/jira/projects/SLING/versions/12346630

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

You can use this UNIX script to download the release and verify the
signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

Usage:
sh check_staged_release.sh 2183 /tmp/sling-staging

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Best regards,

David



--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


Re: [VOTE] Release Sling Apache Feature Model Converter 1.0.10, Content-Package to Feature Model Converter 1.0.6 and Slingstart Maven Plugin 1.9.6

2020-01-10 Thread Robert Munteanu
On Fri, 2020-01-10 at 11:20 +, dav...@apache.org wrote:
> Please vote to approve this release:

+1
Robert


signature.asc
Description: This is a digitally signed message part


[jira] [Commented] (SLING-8987) Review exported packages

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu commented on SLING-8987:


[~tomekr], [~tomasz.k.niedzwi...@gmail.com] - what are your thoughts on this? 
Do you expect anyone to actually use to the code from SDI, as opposed to just 
configuring it?

> Review exported packages
> 
>
> Key: SLING-8987
> URL: https://issues.apache.org/jira/browse/SLING-8987
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Robert Munteanu
>Priority: Critical
> Fix For: Dynamic Include 3.1.8
>
>
> With SLING-8982 changes that were supposed to be transparent to the consumers 
> have bled into the API. We should review what really needs to be exported (if 
> anything).  My hunch is that we actually don't need to export anything, but 
> that should be validated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (SLING-8987) Review exported packages

2020-01-10 Thread Robert Munteanu (Jira)
Robert Munteanu created SLING-8987:
--

 Summary: Review exported packages
 Key: SLING-8987
 URL: https://issues.apache.org/jira/browse/SLING-8987
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Robert Munteanu
 Fix For: Dynamic Include 3.1.8


With SLING-8982 changes that were supposed to be transparent to the consumers 
have bled into the API. We should review what really needs to be exported (if 
anything).  My hunch is that we actually don't need to export anything, but 
that should be validated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [sling-org-apache-sling-dynamic-include] rombert commented on issue #12: SLING-8982 - dynamic-include: upgrade to parent pom 35

2020-01-10 Thread GitBox
rombert commented on issue #12: SLING-8982 - dynamic-include: upgrade to parent 
pom 35
URL: 
https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/12#issuecomment-573017316
 
 
   @ericvangeem, @scotty6435 , @briankasingli , @toniedzwiedz  - from recent 
activity you are using SDI in your projects. I have migrated the SDI project to 
the bnd annotations, it would be great if you could test if things still work 
with the changes from this PR.
   
   Thanks!


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Commented] (SLING-8986) Incorrect selection of fields with assignable types for collection references

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu commented on SLING-8986:


To reproduce the failure, build 
https://github.com/apache/sling-org-apache-sling-dynamic-include/tree/feature/SLING-8982
 , with the {{configs}} field type changed to {{Set}}.

[~sseifert] - WDYT?

> Incorrect selection of fields with assignable types for collection references
> -
>
> Key: SLING-8986
> URL: https://issues.apache.org/jira/browse/SLING-8986
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing OSGi Mock 2.4.10
>Reporter: Robert Munteanu
>Priority: Major
>
> When trying to inject references to fields that are of type collection, the 
> injection fails, due to the following {{isAssignableFrom}} check in the code 
> below:
> {noformat}
>  private static Field getFieldWithAssignableType(Class clazz, String 
> fieldName, Class type) {
>  Field[] fields = clazz.getDeclaredFields();
>  for (Field field : fields) {
> if (StringUtils.equals(field.getName(), fieldName) && 
> field.getType().isAssignableFrom(type)) {
>  return field;
>  }
>  }
> }
> {noformat}
> The {{type}} parameter is always Collection.class, and the 
> {{field.getType()}} is a subclass of Collection, such as Set or List. The 
> problem is that the check is inverted, e.g. 
> {{Set.class.isAssignableFrom(Collection.class)}} is false, whereas 
> {{Collection.class.isAssignableFrom(Set.class)}} is true. The least specific 
> class type should be first, opposite of the {{instanceof}} check ( I always 
> find this confusing ).
> I have prepared a simple patch, but unfortunately the build fails with 
> {{MockBundleContextDynamicReferencesOsgiR6Test.testReferenceWithDynamicTargetFilter:172->assertDependencies3DynamicFiltered:209
>  expected: but was:}}.
> I am not familiar enough with the codebase to understand whether I should 
> update the test or try and find out what breaks.
> The patch I tried is:
> {noformat}diff --git 
> a/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiServiceUtil.java 
> b/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiServiceUtil.java
> index 8726f9d..71b7e9a 100644
> --- 
> a/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiServiceUtil.java
> +++ 
> b/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiServiceUtil.java
> @@ -340,7 +340,7 @@ final class OsgiServiceUtil {
>  private static Field getFieldWithAssignableType(Class clazz, String 
> fieldName, Class type) {
>  Field[] fields = clazz.getDeclaredFields();
>  for (Field field : fields) {
> -if (StringUtils.equals(field.getName(), fieldName) && 
> field.getType().isAssignableFrom(type)) {
> +if (StringUtils.equals(field.getName(), fieldName) && 
> type.isAssignableFrom(field.getType())) {
>  return field;
>  }
>  }
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [sling-org-apache-sling-dynamic-include] rombert opened a new pull request #12: SLING-8982 - dynamic-include: upgrade to parent pom 35

2020-01-10 Thread GitBox
rombert opened a new pull request #12: SLING-8982 - dynamic-include: upgrade to 
parent pom 35
URL: https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/12
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Created] (SLING-8986) Incorrect selection of fields with assignable types for collection references

2020-01-10 Thread Robert Munteanu (Jira)
Robert Munteanu created SLING-8986:
--

 Summary: Incorrect selection of fields with assignable types for 
collection references
 Key: SLING-8986
 URL: https://issues.apache.org/jira/browse/SLING-8986
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: Testing OSGi Mock 2.4.10
Reporter: Robert Munteanu


When trying to inject references to fields that are of type collection, the 
injection fails, due to the following {{isAssignableFrom}} check in the code 
below:

{noformat}
 private static Field getFieldWithAssignableType(Class clazz, String 
fieldName, Class type) {
 Field[] fields = clazz.getDeclaredFields();
 for (Field field : fields) {
if (StringUtils.equals(field.getName(), fieldName) && 
field.getType().isAssignableFrom(type)) {
 return field;
 }
 }
}
{noformat}

The {{type}} parameter is always Collection.class, and the {{field.getType()}} 
is a subclass of Collection, such as Set or List. The problem is that the check 
is inverted, e.g. {{Set.class.isAssignableFrom(Collection.class)}} is false, 
whereas {{Collection.class.isAssignableFrom(Set.class)}} is true. The least 
specific class type should be first, opposite of the {{instanceof}} check ( I 
always find this confusing ).

I have prepared a simple patch, but unfortunately the build fails with 
{{MockBundleContextDynamicReferencesOsgiR6Test.testReferenceWithDynamicTargetFilter:172->assertDependencies3DynamicFiltered:209
 expected: but was:}}.

I am not familiar enough with the codebase to understand whether I should 
update the test or try and find out what breaks.

The patch I tried is:

{noformat}diff --git 
a/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiServiceUtil.java 
b/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiServiceUtil.java
index 8726f9d..71b7e9a 100644
--- a/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiServiceUtil.java
+++ b/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiServiceUtil.java
@@ -340,7 +340,7 @@ final class OsgiServiceUtil {
 private static Field getFieldWithAssignableType(Class clazz, String 
fieldName, Class type) {
 Field[] fields = clazz.getDeclaredFields();
 for (Field field : fields) {
-if (StringUtils.equals(field.getName(), fieldName) && 
field.getType().isAssignableFrom(type)) {
+if (StringUtils.equals(field.getName(), fieldName) && 
type.isAssignableFrom(field.getType())) {
 return field;
 }
 }
{noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (SLING-8985) sling-mock/resourceresolver-mock: Ensure Resource.getResourceType never returns null

2020-01-10 Thread Stefan Seifert (Jira)


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

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

https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/commit/1fec07ed591984ebe0cddf9944f309eb3d8d94ab
https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/1359a0a5c0c52026034eb14e8774dee516e4e271

> sling-mock/resourceresolver-mock: Ensure Resource.getResourceType never 
> returns null
> 
>
> Key: SLING-8985
> URL: https://issues.apache.org/jira/browse/SLING-8985
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing ResourceResolver Mock 1.1.24, Testing Sling Mock 
> 2.3.18
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Testing ResourceResolver Mock 1.1.26, Testing Sling Mock 
> 2.4.0
>
>
> as discussed in 
> https://lists.apache.org/thread.html/rce8e3d424bd539e18bd5f747eafb0236200c37e6b095ebd860854eb5%40%3Cdev.sling.apache.org%3E
>  Resource.getResourceType should never return null.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (SLING-8985) sling-mock/resourceresolver-mock: Ensure Resource.getResourceType never returns null

2020-01-10 Thread Stefan Seifert (Jira)
Stefan Seifert created SLING-8985:
-

 Summary: sling-mock/resourceresolver-mock: Ensure 
Resource.getResourceType never returns null
 Key: SLING-8985
 URL: https://issues.apache.org/jira/browse/SLING-8985
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: Testing Sling Mock 2.3.18, Testing ResourceResolver Mock 
1.1.24
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: Testing ResourceResolver Mock 1.1.26, Testing Sling Mock 
2.4.0


as discussed in 
https://lists.apache.org/thread.html/rce8e3d424bd539e18bd5f747eafb0236200c37e6b095ebd860854eb5%40%3Cdev.sling.apache.org%3E
 Resource.getResourceType should never return null.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SLING-8962) Use Sling API 2.22.0

2020-01-10 Thread Bertrand Delacretaz (Jira)


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

Bertrand Delacretaz commented on SLING-8962:


Thank you [~olli] for the clarification, and indeed the 
{{o.a.s.scripting.core.it.HtmlScriptingIT}} test fails if I build 
{{o.a.s.servlets.resolver}} with {{o.a.sling.api}} 2..0.0 instead of 
2.22.0-SNAPSHOT.

As we'll need to update the API version at some point anyway I suppose the best 
is for me to work on the version numbers in the {{o.a.s.testing.paxexam}} 
module's {{SlingVersionResolver}}, or in my own version of that.

That class' comments say _this file is generated from Sling's Karaf Features_, 
do we have a documentation on how that works, i.e. how to recreate it with a 
set of compatible version numbers?

> Use Sling API 2.22.0
> 
>
> Key: SLING-8962
> URL: https://issues.apache.org/jira/browse/SLING-8962
> Project: Sling
>  Issue Type: Task
>  Components: Servlets
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
> Fix For: Servlets Resolver 2.5.10
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


RE: [VOTE] Release Apache Sling Parent and Apache Sling Bundle Parent 36

2020-01-10 Thread Stefan Seifert
+1



Re: [VOTE] Release Sling Apache Feature Model Converter 1.0.10, Content-Package to Feature Model Converter 1.0.6 and Slingstart Maven Plugin 1.9.6

2020-01-10 Thread davidb
Here's my +1

David

On Fri, 10 Jan 2020 at 11:20,  wrote:

> Hi all,
>
> I would like to call the release on the following Sling Apache components:
> Feature Model Converter 1.0.10
> Solved issues:
> https://issues.apache.org/jira/projects/SLING/versions/12346747
>
> Content-Package to Feature Model Converter 1.0.6
> Solved issues:
> https://issues.apache.org/jira/projects/SLING/versions/12346742
>
> Slingstart Maven Plugin 1.9.6
> Solved issues:
> https://issues.apache.org/jira/projects/SLING/versions/12346652
>
> We fixed the following issue:
> https://issues.apache.org/jira/projects/SLING/versions/12346630
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-2183
>
> You can use this UNIX script to download the release and verify the
> signatures:
>
> https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
>
> Usage:
> sh check_staged_release.sh 2183 /tmp/sling-staging
>
> Please vote to approve this release:
>
>[ ] +1 Approve the release
>[ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Best regards,
>
> David
>


Re: [VOTE] Release Sling Apache Feature Model Converter 1.0.10, Content-Package to Feature Model Converter 1.0.6 and Slingstart Maven Plugin 1.9.6

2020-01-10 Thread davidb
Please ignore the line in the mail:
We fixed the following issue:
https://issues.apache.org/jira/projects/SLING/versions/12346630

That's a copy-and-paste glitch.

Cheers,

David

On Fri, 10 Jan 2020 at 11:20,  wrote:

> Hi all,
>
> I would like to call the release on the following Sling Apache components:
> Feature Model Converter 1.0.10
> Solved issues:
> https://issues.apache.org/jira/projects/SLING/versions/12346747
>
> Content-Package to Feature Model Converter 1.0.6
> Solved issues:
> https://issues.apache.org/jira/projects/SLING/versions/12346742
>
> Slingstart Maven Plugin 1.9.6
> Solved issues:
> https://issues.apache.org/jira/projects/SLING/versions/12346652
>
> We fixed the following issue:
> https://issues.apache.org/jira/projects/SLING/versions/12346630
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-2183
>
> You can use this UNIX script to download the release and verify the
> signatures:
>
> https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
>
> Usage:
> sh check_staged_release.sh 2183 /tmp/sling-staging
>
> Please vote to approve this release:
>
>[ ] +1 Approve the release
>[ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Best regards,
>
> David
>


[VOTE] Release Sling Apache Feature Model Converter 1.0.10, Content-Package to Feature Model Converter 1.0.6 and Slingstart Maven Plugin 1.9.6

2020-01-10 Thread davidb
Hi all,

I would like to call the release on the following Sling Apache components:
Feature Model Converter 1.0.10
Solved issues:
https://issues.apache.org/jira/projects/SLING/versions/12346747

Content-Package to Feature Model Converter 1.0.6
Solved issues:
https://issues.apache.org/jira/projects/SLING/versions/12346742

Slingstart Maven Plugin 1.9.6
Solved issues:
https://issues.apache.org/jira/projects/SLING/versions/12346652

We fixed the following issue:
https://issues.apache.org/jira/projects/SLING/versions/12346630

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

You can use this UNIX script to download the release and verify the
signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

Usage:
sh check_staged_release.sh 2183 /tmp/sling-staging

Please vote to approve this release:

   [ ] +1 Approve the release
   [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Best regards,

David


[jira] [Resolved] (SLING-8975) Sling API: Resource.getResourceType should be @Nullable

2020-01-10 Thread Stefan Seifert (Jira)


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

Stefan Seifert resolved SLING-8975.
---
  Assignee: (was: Stefan Seifert)
Resolution: Won't Fix

set this ticket to won't fix - see 
https://lists.apache.org/thread.html/rce8e3d424bd539e18bd5f747eafb0236200c37e6b095ebd860854eb5%40%3Cdev.sling.apache.org%3E

> Sling API: Resource.getResourceType should be @Nullable
> ---
>
> Key: SLING-8975
> URL: https://issues.apache.org/jira/browse/SLING-8975
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.21.0
>Reporter: Stefan Seifert
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> currently, the {{getResourceType()}} method of the {{Resource}} interface is 
> marked as {{@NotNull}} in the API.
> imho this is wrong:
> * it is not mandatory that every resource has a resource type
> * the JCR resource provider uses the JCR primary type as "fallback" value 
> when no resource type is defined as property, but this is not necessary the 
> case for other resource providers or synthetic resources



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (SLING-8975) Sling API: Resource.getResourceType should be @Nullable

2020-01-10 Thread Stefan Seifert (Jira)


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

Stefan Seifert closed SLING-8975.
-

> Sling API: Resource.getResourceType should be @Nullable
> ---
>
> Key: SLING-8975
> URL: https://issues.apache.org/jira/browse/SLING-8975
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.21.0
>Reporter: Stefan Seifert
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> currently, the {{getResourceType()}} method of the {{Resource}} interface is 
> marked as {{@NotNull}} in the API.
> imho this is wrong:
> * it is not mandatory that every resource has a resource type
> * the JCR resource provider uses the JCR primary type as "fallback" value 
> when no resource type is defined as property, but this is not necessary the 
> case for other resource providers or synthetic resources



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (SLING-8984) SyntheticResource and ResourceWrapper: Add missing @NotNull annotations

2020-01-10 Thread Stefan Seifert (Jira)


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

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

https://github.com/apache/sling-org-apache-sling-api/commit/52873bc46fa2ff8e81d506535e0294ae2773c22f

> SyntheticResource and ResourceWrapper: Add missing @NotNull annotations
> ---
>
> Key: SLING-8984
> URL: https://issues.apache.org/jira/browse/SLING-8984
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: API 2.22.2
>
>
> alle methods of SyntheticResource and ResourceWrapper should have the 
> approritate @NotNull anotations for mandatory parameters.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (SLING-8984) SyntheticResource and ResourceWrapper: Add missing @NotNull annotations

2020-01-10 Thread Stefan Seifert (Jira)
Stefan Seifert created SLING-8984:
-

 Summary: SyntheticResource and ResourceWrapper: Add missing 
@NotNull annotations
 Key: SLING-8984
 URL: https://issues.apache.org/jira/browse/SLING-8984
 Project: Sling
  Issue Type: Improvement
  Components: API
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: API 2.22.2


alle methods of SyntheticResource and ResourceWrapper should have the 
approritate @NotNull anotations for mandatory parameters.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


RE: Resource Type mandatory or optional?

2020-01-10 Thread Stefan Seifert
all right, than we're fine from that side.

i will cross-check the nullability annotations for synthetic resource and the 
sling mock/resource resolver mocks to make sure they do not return null for 
resource type in unit tests.

stefan

>-Original Message-
>From: Carsten Ziegeler [mailto:cziege...@apache.org]
>Sent: Thursday, January 9, 2020 10:45 PM
>To: dev@sling.apache.org
>Subject: Re: Resource Type mandatory or optional?
>
>I looked at some of our provider implementations and all of them make
>sure to return a default resource type; so I think we're safe here.
>
>The only place where we potentially could handle this is inside the
>resource resolver implementation after a resource is returned from a
>provider. If the resource type is null, log a big error message and wrap
>the resource. But on the other hand, a provider is then clearly breaking
>the contract and there are other places where this could happen and we
>don't check for that either, like if the resource returns the correct
>path, the correct resource resolver etc.
>
>So as we don't have a problem here as of today, I think its not worth
>doing any extra effort.
>
>Regards
>Carsten
>
>
>On 09.01.2020 22:08, Stefan Seifert wrote:
>> to sum up the opinions:
>>
>> 1. Sling API should always return a resource type, even if it's a
>fallback one
>>
>> 2. setting a sling:resourceType property is optional, if it's not set a
>fallback resource type is returned
>>
>> 3. the JCR resource provider always uses the JCR primrary type as
>fallback
>>
>>
>> -> open question from my side: should we change the Sling API
>implementation to always return a fixed fallback resource type, if the
>resource provider does not provide any value for the resource type? konrad
>recommended to use 'sling/servlet/default' to use for this purpose.
>>
>>
>> stefan
>>
>>
>>> -Original Message-
>>> From: Stefan Seifert [mailto:sseif...@pro-vision.de]
>>> Sent: Thursday, January 9, 2020 2:00 PM
>>> To: Sling Developers
>>> Subject: Resource Type mandatory or optional?
>>>
>>> i've created a ticket concerning the Sling API that the method
>>> Resource.getResourceType should be marke das @Nullable, i always thought
>it
>>> was a bug and that the resource type is optional [1].
>>>
>>> carsten pointed out that the resource type is mandatory. the javadocs
>are
>>> not precise on this, i've also found no clear statement in the sling
>docs
>>> (I might not have found it).
>>>
>>> technically there is always a resource type when the JCR resource
>provider
>>> is used (fallback to JCR primary type if sling:resourceType is not set),
>>> but that's not implicitly the case for other resource providers or
>>> synthetic resources.
>>>
>>> if we think a resource type should be never null, we should return a
>>> default value for resources that do not have one, and update the
>>> documentation.
>>>
>>> WDYT?
>>>
>>> stefan
>>>
>>> [1] https://issues.apache.org/jira/browse/SLING-8975
>>>
>>
>>
>
>--
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>cziege...@apache.org



Re: Retire feature application builder

2020-01-10 Thread Bertrand Delacretaz
Hi,

On Thu, Jan 9, 2020 at 9:27 AM Carsten Ziegeler  wrote:
> ...I think we should retire it. What is the process for that ?
> As we never released it, we can probably just delete it?...

In case you decide to keep it but mark it deprecated (I have no
opinion on that myself) I have moved the documentation of the
deprecating procedure discussed at few months ago at
https://sling.apache.org/documentation/development/deprecating-sling-modules.html

-Bertrand


Re: Retiring Sling modules (was: Retire feature application builder)

2020-01-10 Thread Bertrand Delacretaz
On Thu, Jan 9, 2020 at 10:33 AM Bertrand Delacretaz
 wrote:
> ... 
> https://cwiki.apache.org/confluence/display/SLING/Deprecating+Sling+Modules
> was discussed a few months ago...

I have now moved that information to
https://sling.apache.org/documentation/development/deprecating-sling-modules.html
, it seems like we have consensus to use that procedure.

-Bertrand


[jira] [Commented] (SLING-8980) Set bundle-version suffix of SNAPSHOT versions to the static String "-SNAPSHOT" instead of a timestamp

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu commented on SLING-8980:


Follow-up fix in [sling-parent commit 
216a06d|https://github.com/apache/sling-parent/commit/216a06d]


> Set bundle-version suffix of SNAPSHOT versions to the static String 
> "-SNAPSHOT" instead of a timestamp
> --
>
> Key: SLING-8980
> URL: https://issues.apache.org/jira/browse/SLING-8980
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Konrad Windszus
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Bundle Parent 37
>
>
> Despite the discussion in  
> https://www.mail-archive.com/dev@sling.apache.org/msg76177.html we should 
> nowadays switch back the bundle version to having the suffix SNAPSHOT (for 
> reproducible builds to also work on SNAPSHOTs). Compare with 
> https://github.com/bndtools/bnd/issues/3521#issuecomment-572695574 and 
> https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin#reproducible-builds.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (SLING-8623) Add support to cpConverter to drop content-packages of PackageType.CONTENT from targetmodel

2020-01-10 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert updated SLING-8623:
--
Fix Version/s: (was: Content-Package to Feature Model Converter 1.0.6)
   Content-Package to Feature Model Converter 1.0.8

> Add support to cpConverter to drop content-packages of PackageType.CONTENT 
> from targetmodel
> ---
>
> Key: SLING-8623
> URL: https://issues.apache.org/jira/browse/SLING-8623
> Project: Sling
>  Issue Type: New Feature
>  Components: Content-Package to Feature Model Converter
>Reporter: Dominik Süß
>Assignee: Simone Tripodi
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.8
>
>
> In cases where content packages are converted for scenarios with use of 
> CompositeNodeStore to handle the immutable content the featureModels are 
> supposed to only install the immutable part of the repository - therefore the 
> content-packages of PackageType.Content should be droppable. They anyhow 
> can't be omitted from scanning & parsing as the conversion of service users, 
> CNDs etc. into repoinit is still supposed to happen.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (SLING-8924) Some tests fail on Java 11

2020-01-10 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert updated SLING-8924:
--
Fix Version/s: (was: Content-Package to Feature Model Converter 1.0.6)
   Content-Package to Feature Model Converter 1.0.8

> Some tests fail on Java 11
> --
>
> Key: SLING-8924
> URL: https://issues.apache.org/jira/browse/SLING-8924
> Project: Sling
>  Issue Type: Bug
>  Components: Content-Package to Feature Model Converter
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.8
>
>
> Running {{mvn clean install}} with
> {noformat}Apache Maven 3.6.2 (SUSE 3.6.2-1.1)
> Maven home: /usr/share/maven
> Java version: 11.0.5, vendor: Oracle Corporation, runtime: 
> /usr/lib64/jvm/java-11-openjdk-11
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.3.12-1-default", arch: "amd64", family: 
> "unix"{noformat}
> results in the following failures/errors:
> {noformat}[ERROR] Failures: 
> [ERROR]   
> RepPolicyEntryHandlerTest.notDeclaredSystemUsersWillNotHaveAclSettings:179 
> expected:<...maryType="rep:ACL">
> [ rep:principalName="acs-commons-ensure-oak-index-service" 
> rep:privileges="{Name}[jcr:read,rep:write,rep:indexDefinitionManagement]">
>  rep:glob="{Name}[*/oak:index/*]"/>
> 
> ] but was:<...maryType="rep:ACL">
> [ rep:principalName="acs-commons-ensure-oak-index-service" 
> rep:privileges="{Name}[jcr:read,rep:write,rep:indexDefinitionManagement]">
>  rep:glob="{Name}[*/oak:index/*]"/>
> 
> ]
> [ERROR]   RepPolicyEntryHandlerTest.systemUserAclSetNotForUserPath:214 
> expected:<...maryType="rep:ACL">
> [ rep:principalName="acs-commons-ensure-oak-index-service" 
> rep:privileges="{Name}[jcr:read,rep:write,rep:indexDefinitionManagement]">
>  rep:glob="{Name}[*/oak:index/*]"/>
> 
>  rep:principalName="acs-commons-dispatcher-flush-service" 
> rep:privileges="{Name}[jcr:read,crx:replicate,jcr:removeNode]"/>
>  rep:principalName="acs-commons-ensure-service-user-service" 
> rep:privileges="{Name}[jcr:read,rep:write,jcr:readAccessControl,jcr:modifyAccessControl]"/>
>  rep:principalName="acs-commons-automatic-package-replicator-service" 
> rep:privileges="{Name}[jcr:read]"/>
> ] but was:<...maryType="rep:ACL">
> [ rep:principalName="acs-commons-ensure-oak-index-service" 
> rep:privileges="{Name}[jcr:read,rep:write,rep:indexDefinitionManagement]">
>  rep:glob="{Name}[*/oak:index/*]"/>
> 
>  rep:principalName="acs-commons-dispatcher-flush-service" 
> rep:privileges="{Name}[jcr:read,crx:replicate,jcr:removeNode]"/>
>  rep:principalName="acs-commons-ensure-service-user-service" 
> rep:privileges="{Name}[jcr:read,rep:write,jcr:readAccessControl,jcr:modifyAccessControl]"/>
>  rep:principalName="acs-commons-automatic-package-replicator-service" 
> rep:privileges="{Name}[jcr:read]"/>
> ]
> [ERROR] Errors: 
> [ERROR]   
> RepPolicyEntryHandlerTest.parseAcl:88->parseAndSetRepoinit:231->parseAndSetRepoinit:258
>  » IndexOutOfBounds
> [INFO] 
> [ERROR] Tests run: 131, Failures: 2, Errors: 1, Skipped: 0
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (SLING-8973) Repoinit convertion is not respecting runmodes

2020-01-10 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert updated SLING-8973:
--
Fix Version/s: Content-Package to Feature Model Converter 1.0.6

> Repoinit convertion is not respecting runmodes
> --
>
> Key: SLING-8973
> URL: https://issues.apache.org/jira/browse/SLING-8973
> Project: Sling
>  Issue Type: Bug
>  Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.0.2
>Reporter: Dominik Süß
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.4, 
> Content-Package to Feature Model Converter 1.0.6
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When repoinit configurations get converted into repoinit extensions the 
> runmode selection is not being respected and repoinit statements always being 
> added to the non runmode specific feature.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (SLING-8973) Repoinit convertion is not respecting runmodes

2020-01-10 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert updated SLING-8973:
--
Fix Version/s: (was: Content-Package to Feature Model Converter 1.0.6)

> Repoinit convertion is not respecting runmodes
> --
>
> Key: SLING-8973
> URL: https://issues.apache.org/jira/browse/SLING-8973
> Project: Sling
>  Issue Type: Bug
>  Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.0.2
>Reporter: Dominik Süß
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.4
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When repoinit configurations get converted into repoinit extensions the 
> runmode selection is not being respected and repoinit statements always being 
> added to the non runmode specific feature.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (SLING-8973) Repoinit convertion is not respecting runmodes

2020-01-10 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert updated SLING-8973:
--
Fix Version/s: (was: Content-Package to Feature Model Converter 1.0.4)
   Content-Package to Feature Model Converter 1.0.6

> Repoinit convertion is not respecting runmodes
> --
>
> Key: SLING-8973
> URL: https://issues.apache.org/jira/browse/SLING-8973
> Project: Sling
>  Issue Type: Bug
>  Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.0.2
>Reporter: Dominik Süß
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.6
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When repoinit configurations get converted into repoinit extensions the 
> runmode selection is not being respected and repoinit statements always being 
> added to the non runmode specific feature.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (SLING-8979) Include the -source-release.zip file in releases

2020-01-10 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert resolved SLING-8979.
---
Resolution: Fixed

> Include the -source-release.zip file in releases
> 
>
> Key: SLING-8979
> URL: https://issues.apache.org/jira/browse/SLING-8979
> Project: Sling
>  Issue Type: Bug
>  Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.0.4
>Reporter: David Bosschaert
>Assignee: A. J. David Bosschaert
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> As described on the 1.0.4 release thread ( 
> [https://lists.apache.org/thread.html/r9bef8ccde5ff94e5f841eaabaf66284faed6dfe89f82c4315f62daba%40%3Cdev.sling.apache.org%3E]
>  ), the release is missing the \{{-source-release.zip}} file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (SLING-8983) Include the -source-release.zip file in releases

2020-01-10 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert resolved SLING-8983.
---
Resolution: Fixed

> Include the -source-release.zip file in releases
> 
>
> Key: SLING-8983
> URL: https://issues.apache.org/jira/browse/SLING-8983
> Project: Sling
>  Issue Type: Bug
>  Components: Feature Model
>Affects Versions: Feature Model Converter 1.0.8
>Reporter: David Bosschaert
>Assignee: A. J. David Bosschaert
>Priority: Major
> Fix For: Feature Model Converter 1.0.10
>
>
> As described on the 1.0.4 release thread of the content package to feature 
> model converter, ( 
> [https://lists.apache.org/thread.html/r9bef8ccde5ff94e5f841eaabaf66284faed6dfe89f82c4315f62daba%40%3Cdev.sling.apache.org%3E]
>  ), the release is missing the {{-source-release.zip}} file. This problem is 
> also present in the feature model converter component.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [sling-org-apache-sling-feature-cpconverter] bosschaert merged pull request #24: SLING-8979 Include the -source-release.zip file in releases

2020-01-10 Thread GitBox
bosschaert merged pull request #24: SLING-8979 Include the -source-release.zip 
file in releases
URL: 
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/24
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Updated] (SLING-8983) Include the -source-release.zip file in releases

2020-01-10 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert updated SLING-8983:
--
Description: As described on the 1.0.4 release thread of the content 
package to feature model converter, ( 
[https://lists.apache.org/thread.html/r9bef8ccde5ff94e5f841eaabaf66284faed6dfe89f82c4315f62daba%40%3Cdev.sling.apache.org%3E]
 ), the release is missing the {{-source-release.zip}} file. This problem is 
also present in the feature model converter component.  (was: As described on 
the 1.0.4 release thread ( 
[https://lists.apache.org/thread.html/r9bef8ccde5ff94e5f841eaabaf66284faed6dfe89f82c4315f62daba%40%3Cdev.sling.apache.org%3E]
 ), the release is missing the \{{-source-release.zip}} file.)

> Include the -source-release.zip file in releases
> 
>
> Key: SLING-8983
> URL: https://issues.apache.org/jira/browse/SLING-8983
> Project: Sling
>  Issue Type: Bug
>  Components: Feature Model
>Affects Versions: Feature Model Converter 1.0.8
>Reporter: David Bosschaert
>Assignee: A. J. David Bosschaert
>Priority: Major
> Fix For: Feature Model Converter 1.0.10
>
>
> As described on the 1.0.4 release thread of the content package to feature 
> model converter, ( 
> [https://lists.apache.org/thread.html/r9bef8ccde5ff94e5f841eaabaf66284faed6dfe89f82c4315f62daba%40%3Cdev.sling.apache.org%3E]
>  ), the release is missing the {{-source-release.zip}} file. This problem is 
> also present in the feature model converter component.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (SLING-8983) Include the -source-release.zip file in releases

2020-01-10 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert updated SLING-8983:
--
Component/s: (was: Content-Package to Feature Model Converter)
 Feature Model

> Include the -source-release.zip file in releases
> 
>
> Key: SLING-8983
> URL: https://issues.apache.org/jira/browse/SLING-8983
> Project: Sling
>  Issue Type: Bug
>  Components: Feature Model
>Affects Versions: Feature Model Converter 1.0.8
>Reporter: David Bosschaert
>Assignee: A. J. David Bosschaert
>Priority: Major
> Fix For: Feature Model Converter 1.0.10
>
>
> As described on the 1.0.4 release thread ( 
> [https://lists.apache.org/thread.html/r9bef8ccde5ff94e5f841eaabaf66284faed6dfe89f82c4315f62daba%40%3Cdev.sling.apache.org%3E]
>  ), the release is missing the \{{-source-release.zip}} file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (SLING-8983) Include the -source-release.zip file in releases

2020-01-10 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert updated SLING-8983:
--
Fix Version/s: (was: Content-Package to Feature Model Converter 1.0.6)
   Feature Model Converter 1.0.10

> Include the -source-release.zip file in releases
> 
>
> Key: SLING-8983
> URL: https://issues.apache.org/jira/browse/SLING-8983
> Project: Sling
>  Issue Type: Bug
>  Components: Content-Package to Feature Model Converter
>Affects Versions: Feature Model Converter 1.0.8
>Reporter: David Bosschaert
>Assignee: A. J. David Bosschaert
>Priority: Major
> Fix For: Feature Model Converter 1.0.10
>
>
> As described on the 1.0.4 release thread ( 
> [https://lists.apache.org/thread.html/r9bef8ccde5ff94e5f841eaabaf66284faed6dfe89f82c4315f62daba%40%3Cdev.sling.apache.org%3E]
>  ), the release is missing the \{{-source-release.zip}} file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [sling-org-apache-sling-feature-cpconverter] sonarcloud[bot] commented on issue #24: SLING-8979 Include the -source-release.zip file in releases

2020-01-10 Thread GitBox
sonarcloud[bot] commented on issue #24: SLING-8979 Include the 
-source-release.zip file in releases
URL: 
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/24#issuecomment-572957826
 
 
   Kudos, SonarCloud Quality Gate passed!
   
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=24=false=BUG)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=24=false=BUG)
 [0 
Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=24=false=BUG)
  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=24=false=VULNERABILITY)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=24=false=VULNERABILITY)
 [0 
Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=24=false=VULNERABILITY)
 (and [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=24=false=SECURITY_HOTSPOT)
 [0 Security 
Hotspots](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=24=false=SECURITY_HOTSPOT)
 to review)  
   [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=24=false=CODE_SMELL)
 [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=24=false=CODE_SMELL)
 [0 Code 
Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-cpconverter=24=false=CODE_SMELL)
   
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-cpconverter=24=coverage=list)
 No Coverage information  
   [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-cpconverter=24=new_duplicated_lines_density=list)
 [0.0% 
Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-cpconverter=24=new_duplicated_lines_density=list)
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Updated] (SLING-8983) Include the -source-release.zip file in releases

2020-01-10 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert updated SLING-8983:
--
Affects Version/s: (was: Content-Package to Feature Model Converter 
1.0.4)
   Feature Model Converter 1.0.8

> Include the -source-release.zip file in releases
> 
>
> Key: SLING-8983
> URL: https://issues.apache.org/jira/browse/SLING-8983
> Project: Sling
>  Issue Type: Bug
>  Components: Content-Package to Feature Model Converter
>Affects Versions: Feature Model Converter 1.0.8
>Reporter: David Bosschaert
>Assignee: A. J. David Bosschaert
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.6
>
>
> As described on the 1.0.4 release thread ( 
> [https://lists.apache.org/thread.html/r9bef8ccde5ff94e5f841eaabaf66284faed6dfe89f82c4315f62daba%40%3Cdev.sling.apache.org%3E]
>  ), the release is missing the \{{-source-release.zip}} file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (SLING-8983) Include the -source-release.zip file in releases

2020-01-10 Thread A. J. David Bosschaert (Jira)
A. J. David Bosschaert created SLING-8983:
-

 Summary: Include the -source-release.zip file in releases
 Key: SLING-8983
 URL: https://issues.apache.org/jira/browse/SLING-8983
 Project: Sling
  Issue Type: Bug
  Components: Content-Package to Feature Model Converter
Affects Versions: Content-Package to Feature Model Converter 1.0.4
Reporter: David Bosschaert
Assignee: A. J. David Bosschaert
 Fix For: Content-Package to Feature Model Converter 1.0.6


As described on the 1.0.4 release thread ( 
[https://lists.apache.org/thread.html/r9bef8ccde5ff94e5f841eaabaf66284faed6dfe89f82c4315f62daba%40%3Cdev.sling.apache.org%3E]
 ), the release is missing the \{{-source-release.zip}} file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [sling-org-apache-sling-feature-cpconverter] bosschaert opened a new pull request #24: SLING-8979 Include the -source-release.zip file in releases

2020-01-10 Thread GitBox
bosschaert opened a new pull request #24: SLING-8979 Include the 
-source-release.zip file in releases
URL: 
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/24
 
 
   The maven-assembly-plugin configuration was overridden globally rather
   than added for an extra goal


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Assigned] (SLING-8979) Include the -source-release.zip file in releases

2020-01-10 Thread A. J. David Bosschaert (Jira)


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

A. J. David Bosschaert reassigned SLING-8979:
-

Assignee: A. J. David Bosschaert

> Include the -source-release.zip file in releases
> 
>
> Key: SLING-8979
> URL: https://issues.apache.org/jira/browse/SLING-8979
> Project: Sling
>  Issue Type: Bug
>  Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.0.4
>Reporter: David Bosschaert
>Assignee: A. J. David Bosschaert
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.0.6
>
>
> As described on the 1.0.4 release thread ( 
> [https://lists.apache.org/thread.html/r9bef8ccde5ff94e5f841eaabaf66284faed6dfe89f82c4315f62daba%40%3Cdev.sling.apache.org%3E]
>  ), the release is missing the \{{-source-release.zip}} file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (SLING-8982) dynamic-include: upgrade to parent pom 35

2020-01-10 Thread Robert Munteanu (Jira)
Robert Munteanu created SLING-8982:
--

 Summary: dynamic-include: upgrade to parent pom 35
 Key: SLING-8982
 URL: https://issues.apache.org/jira/browse/SLING-8982
 Project: Sling
  Issue Type: Task
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: Dynamic Include 3.1.8






--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (SLING-8982) dynamic-include: upgrade to parent pom 35

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu updated SLING-8982:
---
Parent: SLING-8734
Issue Type: Sub-task  (was: Task)

> dynamic-include: upgrade to parent pom 35
> -
>
> Key: SLING-8982
> URL: https://issues.apache.org/jira/browse/SLING-8982
> Project: Sling
>  Issue Type: Sub-task
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Dynamic Include 3.1.8
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SLING-8427) Sling Dynamic Include - TTL not being set on synthetic resources

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu commented on SLING-8427:


Follow-up fix in [sling-org-apache-sling-dynamic-include commit 
1c02ed5|https://github.com/apache/sling-org-apache-sling-dynamic-include/commit/1c02ed5]


> Sling Dynamic Include - TTL not being set on synthetic resources
> 
>
> Key: SLING-8427
> URL: https://issues.apache.org/jira/browse/SLING-8427
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Dynamic Include 3.1.2
> Environment: AEM 6.3 - AEM 6.5
>Reporter: Eric Van Geem
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Dynamic Include 3.1.8
>
>
> When a TTL value is configured, the Cache-Control header does not get set in 
> the response headers of the resource when the resource is synthetic. 
> *Expected behavior:*
> The existing SyntheticResourceFilter is responsible for identifying if the 
> requested resource is synthetic, and if so, force the resourceType into the 
> request by taking the resourceType from the request URL suffix. Then, the 
> CacheControlFilter is to be invoked after this which reads the resource from 
> the request (now the forced resourceType from the prior step) and sets the 
> appropriate Cache-Control header if this resourceType is configured for SDI.
> *Actual behavior:*
> The CacheControlFilter is never executed after the SyntheticResourceFilter 
> sets the forced resourceType in the request for the synthetic resource, thus 
> the Cache-Control response header never gets set. 
>  
> More details:
> I believe the cause of this issue is due to the way the CacheControlFilter's 
> filter scope is defined; it is missing the *forward* filter scope. The 
> SyntheticResourceFilter forces the resourceType by passing a new object of 
> options to the request dispatcher 
> {code:java}
> dispatcher = slingRequest.getRequestDispatcher(resource, options);{code}
> This is then followed by a call to 
> {code:java}
> dispatcher.forward(request, response);{code}
> to forward the request in the filter chain.
> This is where the CacheControlFilter should receive the request, but does not 
> happen because the CacheControlFilter's filter scope has not been declared to 
> receive forwarded requests. Simply adding the *forward* scope to the 
> CacheControlFilter's list of scopes seems to resolve the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (SLING-8838) Add HEAD support to ContentDispositionFilter

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu updated SLING-8838:
---
Fix Version/s: (was: Security 1.1.16)
   Security 1.1.18

> Add HEAD support to ContentDispositionFilter
> 
>
> Key: SLING-8838
> URL: https://issues.apache.org/jira/browse/SLING-8838
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Security 1.1.10
>Reporter: Ilyas Türkben
>Priority: Major
> Fix For: Security 1.1.18
>
>
> As per \(*) {{ContentDispositionFilter}} doesn't seem to support HEAD 
> requests.
> It is handy to use curl with {{curl -I http://localhost/path}} in order to 
> retrieve only the response headers rather than the whole content, especially 
> with blobs.
> * 
> https://github.com/apache/sling-org-apache-sling-security/blob/master/src/main/java/org/apache/sling/security/impl/ContentDispositionFilter.java#L205



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SLING-8838) Add HEAD support to ContentDispositionFilter

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu commented on SLING-8838:


Thanks! [~tuerkben] - would you have the time to send a PR? This will probably 
get the work done faster.

> Add HEAD support to ContentDispositionFilter
> 
>
> Key: SLING-8838
> URL: https://issues.apache.org/jira/browse/SLING-8838
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Security 1.1.10
>Reporter: Ilyas Türkben
>Priority: Major
>
> As per \(*) {{ContentDispositionFilter}} doesn't seem to support HEAD 
> requests.
> It is handy to use curl with {{curl -I http://localhost/path}} in order to 
> retrieve only the response headers rather than the whole content, especially 
> with blobs.
> * 
> https://github.com/apache/sling-org-apache-sling-security/blob/master/src/main/java/org/apache/sling/security/impl/ContentDispositionFilter.java#L205



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SLING-8838) Add HEAD support to ContentDispositionFilter

2020-01-10 Thread Antonio Sanso (Jira)


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

Antonio Sanso commented on SLING-8838:
--

[~rombert] I do not see why not...

> Add HEAD support to ContentDispositionFilter
> 
>
> Key: SLING-8838
> URL: https://issues.apache.org/jira/browse/SLING-8838
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Security 1.1.10
>Reporter: Ilyas Türkben
>Priority: Major
>
> As per \(*) {{ContentDispositionFilter}} doesn't seem to support HEAD 
> requests.
> It is handy to use curl with {{curl -I http://localhost/path}} in order to 
> retrieve only the response headers rather than the whole content, especially 
> with blobs.
> * 
> https://github.com/apache/sling-org-apache-sling-security/blob/master/src/main/java/org/apache/sling/security/impl/ContentDispositionFilter.java#L205



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (SLING-8838) Add HEAD support to ContentDispositionFilter

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu updated SLING-8838:
---
Fix Version/s: Security 1.1.16

> Add HEAD support to ContentDispositionFilter
> 
>
> Key: SLING-8838
> URL: https://issues.apache.org/jira/browse/SLING-8838
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Security 1.1.10
>Reporter: Ilyas Türkben
>Priority: Major
> Fix For: Security 1.1.16
>
>
> As per \(*) {{ContentDispositionFilter}} doesn't seem to support HEAD 
> requests.
> It is handy to use curl with {{curl -I http://localhost/path}} in order to 
> retrieve only the response headers rather than the whole content, especially 
> with blobs.
> * 
> https://github.com/apache/sling-org-apache-sling-security/blob/master/src/main/java/org/apache/sling/security/impl/ContentDispositionFilter.java#L205



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (SLING-8427) Sling Dynamic Include - TTL not being set on synthetic resources

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu resolved SLING-8427.

Resolution: Fixed

> Sling Dynamic Include - TTL not being set on synthetic resources
> 
>
> Key: SLING-8427
> URL: https://issues.apache.org/jira/browse/SLING-8427
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Dynamic Include 3.1.2
> Environment: AEM 6.3 - AEM 6.5
>Reporter: Eric Van Geem
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Dynamic Include 3.1.8
>
>
> When a TTL value is configured, the Cache-Control header does not get set in 
> the response headers of the resource when the resource is synthetic. 
> *Expected behavior:*
> The existing SyntheticResourceFilter is responsible for identifying if the 
> requested resource is synthetic, and if so, force the resourceType into the 
> request by taking the resourceType from the request URL suffix. Then, the 
> CacheControlFilter is to be invoked after this which reads the resource from 
> the request (now the forced resourceType from the prior step) and sets the 
> appropriate Cache-Control header if this resourceType is configured for SDI.
> *Actual behavior:*
> The CacheControlFilter is never executed after the SyntheticResourceFilter 
> sets the forced resourceType in the request for the synthetic resource, thus 
> the Cache-Control response header never gets set. 
>  
> More details:
> I believe the cause of this issue is due to the way the CacheControlFilter's 
> filter scope is defined; it is missing the *forward* filter scope. The 
> SyntheticResourceFilter forces the resourceType by passing a new object of 
> options to the request dispatcher 
> {code:java}
> dispatcher = slingRequest.getRequestDispatcher(resource, options);{code}
> This is then followed by a call to 
> {code:java}
> dispatcher.forward(request, response);{code}
> to forward the request in the filter chain.
> This is where the CacheControlFilter should receive the request, but does not 
> happen because the CacheControlFilter's filter scope has not been declared to 
> receive forwarded requests. Simply adding the *forward* scope to the 
> CacheControlFilter's list of scopes seems to resolve the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [sling-org-apache-sling-dynamic-include] rombert commented on issue #11: add Forward filter scope to CacheControlFilter

2020-01-10 Thread GitBox
rombert commented on issue #11: add Forward filter scope to CacheControlFilter
URL: 
https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/11#issuecomment-572948787
 
 
   Sorry for taking so long to merge, and thanks for the contribution 
@ericvangeem 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [sling-org-apache-sling-dynamic-include] rombert merged pull request #11: add Forward filter scope to CacheControlFilter

2020-01-10 Thread GitBox
rombert merged pull request #11: add Forward filter scope to CacheControlFilter
URL: https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/11
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Assigned] (SLING-8427) Sling Dynamic Include - TTL not being set on synthetic resources

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu reassigned SLING-8427:
--

Assignee: Robert Munteanu

> Sling Dynamic Include - TTL not being set on synthetic resources
> 
>
> Key: SLING-8427
> URL: https://issues.apache.org/jira/browse/SLING-8427
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Dynamic Include 3.1.2
> Environment: AEM 6.3 - AEM 6.5
>Reporter: Eric Van Geem
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Dynamic Include 3.1.8
>
>
> When a TTL value is configured, the Cache-Control header does not get set in 
> the response headers of the resource when the resource is synthetic. 
> *Expected behavior:*
> The existing SyntheticResourceFilter is responsible for identifying if the 
> requested resource is synthetic, and if so, force the resourceType into the 
> request by taking the resourceType from the request URL suffix. Then, the 
> CacheControlFilter is to be invoked after this which reads the resource from 
> the request (now the forced resourceType from the prior step) and sets the 
> appropriate Cache-Control header if this resourceType is configured for SDI.
> *Actual behavior:*
> The CacheControlFilter is never executed after the SyntheticResourceFilter 
> sets the forced resourceType in the request for the synthetic resource, thus 
> the Cache-Control response header never gets set. 
>  
> More details:
> I believe the cause of this issue is due to the way the CacheControlFilter's 
> filter scope is defined; it is missing the *forward* filter scope. The 
> SyntheticResourceFilter forces the resourceType by passing a new object of 
> options to the request dispatcher 
> {code:java}
> dispatcher = slingRequest.getRequestDispatcher(resource, options);{code}
> This is then followed by a call to 
> {code:java}
> dispatcher.forward(request, response);{code}
> to forward the request in the filter chain.
> This is where the CacheControlFilter should receive the request, but does not 
> happen because the CacheControlFilter's filter scope has not been declared to 
> receive forwarded requests. Simply adding the *forward* scope to the 
> CacheControlFilter's list of scopes seems to resolve the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SLING-8838) Add HEAD support to ContentDispositionFilter

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu commented on SLING-8838:


[~asanso] - WDYT, should we do this?

> Add HEAD support to ContentDispositionFilter
> 
>
> Key: SLING-8838
> URL: https://issues.apache.org/jira/browse/SLING-8838
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: Security 1.1.10
>Reporter: Ilyas Türkben
>Priority: Major
>
> As per \(*) {{ContentDispositionFilter}} doesn't seem to support HEAD 
> requests.
> It is handy to use curl with {{curl -I http://localhost/path}} in order to 
> retrieve only the response headers rather than the whole content, especially 
> with blobs.
> * 
> https://github.com/apache/sling-org-apache-sling-security/blob/master/src/main/java/org/apache/sling/security/impl/ContentDispositionFilter.java#L205



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (SLING-8980) Set bundle-version suffix of SNAPSHOT versions to the static String "-SNAPSHOT" instead of a timestamp

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu resolved SLING-8980.

Resolution: Fixed

> Set bundle-version suffix of SNAPSHOT versions to the static String 
> "-SNAPSHOT" instead of a timestamp
> --
>
> Key: SLING-8980
> URL: https://issues.apache.org/jira/browse/SLING-8980
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Konrad Windszus
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Bundle Parent 37
>
>
> Despite the discussion in  
> https://www.mail-archive.com/dev@sling.apache.org/msg76177.html we should 
> nowadays switch back the bundle version to having the suffix SNAPSHOT (for 
> reproducible builds to also work on SNAPSHOTs). Compare with 
> https://github.com/bndtools/bnd/issues/3521#issuecomment-572695574 and 
> https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin#reproducible-builds.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SLING-8980) Set bundle-version suffix of SNAPSHOT versions to the static String "-SNAPSHOT" instead of a timestamp

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu commented on SLING-8980:


Thanks for confirming. Fixed with [sling-parent commit 
d9bc35a|https://github.com/apache/sling-parent/commit/d9bc35a].

> Set bundle-version suffix of SNAPSHOT versions to the static String 
> "-SNAPSHOT" instead of a timestamp
> --
>
> Key: SLING-8980
> URL: https://issues.apache.org/jira/browse/SLING-8980
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Konrad Windszus
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Bundle Parent 37
>
>
> Despite the discussion in  
> https://www.mail-archive.com/dev@sling.apache.org/msg76177.html we should 
> nowadays switch back the bundle version to having the suffix SNAPSHOT (for 
> reproducible builds to also work on SNAPSHOTs). Compare with 
> https://github.com/bndtools/bnd/issues/3521#issuecomment-572695574 and 
> https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin#reproducible-builds.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SLING-8951) Enable reproducible builds by default

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu commented on SLING-8951:


Thanks [~kwin]

> Enable reproducible builds by default
> -
>
> Key: SLING-8951
> URL: https://issues.apache.org/jira/browse/SLING-8951
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Parent 35
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Parent 36, Bundle Parent 36
>
>
> Recently all relevant Maven plugins have been updated to support reproducible 
> builds (https://maven.apache.org/guides/mini/guide-reproducible-builds.html). 
> The new ASF parent 22 will manage those versions 
> (https://github.com/apache/maven-apache-parent/blob/master/pom.xml).
> Also there is a flag for bnd for this 
> (https://github.com/bndtools/bnd/issues/3521).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (SLING-8980) Set bundle-version suffix of SNAPSHOT versions to the static String "-SNAPSHOT" instead of a timestamp

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu reassigned SLING-8980:
--

Assignee: Robert Munteanu

> Set bundle-version suffix of SNAPSHOT versions to the static String 
> "-SNAPSHOT" instead of a timestamp
> --
>
> Key: SLING-8980
> URL: https://issues.apache.org/jira/browse/SLING-8980
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Konrad Windszus
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Bundle Parent 37
>
>
> Despite the discussion in  
> https://www.mail-archive.com/dev@sling.apache.org/msg76177.html we should 
> nowadays switch back the bundle version to having the suffix SNAPSHOT (for 
> reproducible builds to also work on SNAPSHOTs). Compare with 
> https://github.com/bndtools/bnd/issues/3521#issuecomment-572695574 and 
> https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin#reproducible-builds.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SLING-8980) Set bundle-version suffix of SNAPSHOT versions to the static String "-SNAPSHOT" instead of a timestamp

2020-01-10 Thread Konrad Windszus (Jira)


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

Konrad Windszus commented on SLING-8980:


Yes, maven-bundle-plugin always used SNAPSHOT suffixed bundle versions and 
there is special handling for SNAPSHOT versions 
(https://github.com/apache/sling-org-apache-sling-installer-core/blob/0a34e33dd26092437be5180e34979abbf9a88300/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleTaskCreator.java#L260).

> Set bundle-version suffix of SNAPSHOT versions to the static String 
> "-SNAPSHOT" instead of a timestamp
> --
>
> Key: SLING-8980
> URL: https://issues.apache.org/jira/browse/SLING-8980
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: Bundle Parent 37
>
>
> Despite the discussion in  
> https://www.mail-archive.com/dev@sling.apache.org/msg76177.html we should 
> nowadays switch back the bundle version to having the suffix SNAPSHOT (for 
> reproducible builds to also work on SNAPSHOTs). Compare with 
> https://github.com/bndtools/bnd/issues/3521#issuecomment-572695574 and 
> https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin#reproducible-builds.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SLING-8980) Set bundle-version suffix of SNAPSHOT versions to the static String "-SNAPSHOT" instead of a timestamp

2020-01-10 Thread Robert Munteanu (Jira)


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

Robert Munteanu commented on SLING-8980:


Will this work properly with the OSGi installer?

> Set bundle-version suffix of SNAPSHOT versions to the static String 
> "-SNAPSHOT" instead of a timestamp
> --
>
> Key: SLING-8980
> URL: https://issues.apache.org/jira/browse/SLING-8980
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: Bundle Parent 37
>
>
> Despite the discussion in  
> https://www.mail-archive.com/dev@sling.apache.org/msg76177.html we should 
> nowadays switch back the bundle version to having the suffix SNAPSHOT (for 
> reproducible builds to also work on SNAPSHOTs). Compare with 
> https://github.com/bndtools/bnd/issues/3521#issuecomment-572695574 and 
> https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin#reproducible-builds.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[VOTE][CANCELLED] Release Apache Sling Feature Model Converter Plugin 1.0.2

2020-01-10 Thread Robert Munteanu
Hi Andy,

As you reported on another email thread, the tests are now fixed, which
is great news :-)

I have updated the email subject to make sure that the cancellation is
visible, please check the steps from [1] to make sure you followed all
of them.

Thanks!

Robert

[1]: 
https://sling.apache.org/documentation/development/release-management.html#canceling-the-release

On Thu, 2020-01-09 at 08:29 -0800, Andreas Schaefer wrote:
> Hi Robert
> 
> I will check out the build with Java 11 and then try to run it under
> Ubuntu in a VM.
> 
> I will pull the plug on the release as I agree that a build must work
> but I was not aware that the build failed until you pointed it out.
> 
> Keep you posted - Andy
> 
> > On Jan 9, 2020, at 2:04 AM, Robert Munteanu 
> > wrote:
> > 
> > On Wed, 2020-01-08 at 07:55 -0800, Andreas Schaefer wrote:
> > > If a subsequent build works it would mean that in the 2nd build
> > > it
> > > would find the dependency on *.core but not in the first.
> > > 
> > > This is my env:
> > > 
> > > mvn --version
> > > Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> > > 2019-
> > > 04-04T12:00:29-07:00)
> > > Maven home: /Java/maven3
> > > Java version: 1.8.0_201, vendor: Oracle Corporation, runtime:
> > > /Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home/
> > > jre
> > > Default locale: en_US, platform encoding: UTF-8
> > > OS name: "mac os x", version: "10.14.6", arch: "x86_64", family:
> > > “mac"
> > 
> > I have
> > 
> > $ mvn -v
> > Apache Maven 3.6.2 (SUSE 3.6.2-1.1)
> > Maven home: /usr/share/maven
> > Java version: 11.0.5, vendor: Oracle Corporation, runtime:
> > /usr/lib64/jvm/java-11-openjdk-11
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux", version: "5.3.12-2-default", arch: "amd64",
> > family: "unix"
> > 
> > I would say it's a JVM issue, but Jenkins runs on Java 8. Maybe
> > Linux
> > vs Mac? At any rate, I would be hesistant of releasing a module
> > with a
> > broken build on Jenkins.
> > 
> > Thank,
> > Robert
> > > Execution Order of the IT tests:
> > > 
> > > [INFO] --- maven-invoker-plugin:3.1.0:integration-test
> > > (integration-
> > > test) @ sling-feature-converter-maven-plugin ---
> > > [INFO] Running 1 setup job:
> > > [INFO] Building: setup-tests/pom.xml
> > > [INFO]   setup-tests/pom.xml
> > > ..
> > > SUCCESS (2.2 s)
> > > [INFO] Setup done.
> > > [INFO] Building: package-with-single-bundle-no-
> > > parameters/core/pom.xml
> > > [INFO]   package-with-single-bundle-no-
> > > parameters/core/pom.xml SUCCESS (8.8 s)
> > > [INFO] Building: package-with-single-bundle-no-parameters/pom.xml
> > > [INFO] run post-build script verify.bsh
> > > [INFO]   package-with-single-bundle-no-parameters/pom.xml 
> > > .
> > > SUCCESS (10.3 s)
> > > [INFO] Building: package-with-single-bundle-no-
> > > parameters/ui.apps/pom.xml
> > > [INFO]   package-with-single-bundle-no-
> > > parameters/ui.apps/pom.xml SUCCESS (2.8 s)
> > > [INFO] Building: package-with-single-bundle-target-
> > > mode/core/pom.xml
> > > [INFO]   package-with-single-bundle-target-
> > > mode/core/pom.xml
> > > SUCCESS (3.9 s)
> > > [INFO] Building: package-with-single-bundle-target-mode/pom.xml
> > > [INFO] run post-build script verify.bsh
> > > [INFO]   package-with-single-bundle-target-mode/pom.xml
> > > ...
> > > SUCCESS (6.6 s)
> > > [INFO] Building: package-with-single-bundle-target-
> > > mode/fm.launcher/pom.xml
> > > [INFO]   package-with-single-bundle-target-
> > > mode/fm.launcher/pom.xml SUCCESS (2.2 s)
> > > [INFO] Building: package-with-single-bundle-target-
> > > mode/ui.apps/pom.xml
> > > [INFO]   package-with-single-bundle-target-
> > > mode/ui.apps/pom.xml SUCCESS (2.8 s)
> > > [INFO] Building: package-with-single-bundle-with-
> > > parameters/core/pom.xml
> > > [INFO]   package-with-single-bundle-with-
> > > parameters/core/pom.xml SUCCESS (3.8 s)
> > > [INFO] Building: package-with-single-bundle-with-
> > > parameters/pom.xml
> > > [INFO] run post-build script verify.bsh
> > > [INFO]   package-with-single-bundle-with-
> > > parameters/pom.xml
> > > SUCCESS (5.4 s)
> > > [INFO] Building: package-with-single-bundle-with-
> > > parameters/ui.apps/pom.xml
> > > [INFO]   package-with-single-bundle-with-
> > > parameters/ui.apps/pom.xml SUCCESS (3.0 s)
> > > 
> > > I also ran the build with my settings.xml file moved away and it
> > > did
> > > still work.
> > > 
> > > Then I upgraded to Maven 3.6.3 and it still does work. What is
> > > your
> > > Maven / Java version?
> > > 
> > > The only thing that always made me wonder is the fact that the
> > > ui.apps are built in the integration-test after the root pom.xml
> > > if
> > > built but that worked for me with all the plugins that have IT
> > > tests
> > > and did not give me grief.
> > > 
> > > - Andy
> > > 
> > > > On Jan 8, 2020, at 6:49 AM, Robert Munteanu  > > > >
> > > > 

[VOTE] [CANCELLED] Release Apache Sling Content-Package to Feature Model Converter 1.0.4

2020-01-10 Thread Robert Munteanu
Hi David,

Thanks a lot for looking into this. I've also updated the subject line
to make it clear the release was cancelled, following [2].

Robert

[2]: 
https://sling.apache.org/documentation/development/release-management.html#canceling-the-release

On Thu, 2020-01-09 at 16:25 +, David Bosschaert wrote:
> Hi Robert,
> 
> I have created https://issues.apache.org/jira/browse/SLING-8979
> 
> and am cancelling this release.
> 
> Best regards,
> 
> David
> 
> On Thu, 9 Jan 2020 at 15:17, Robert Munteanu 
> wrote:
> 
> > 
> > On Thu, 2020-01-09 at 15:13 +, David Bosschaert wrote:
> > > Hi Robert,
> > > 
> > > AFAIK the 1.0.2 version of this component didn't have that
> > > -source-release.zip file either. Can we maybe file a JIRA to add
> > > this
> > > to
> > > the cpconverter build and address it for 1.0.6?
> > 
> > That is an unfortunate oversight.
> > 
> > At this moment I don't think this release satisfies [1] as IMO the
> > sources.jar is not 'sufficient for a user to build and test the
> > release
> > provided they have access to the appropriate platform and tools.'
> > 
> > Thanks,
> > Robert
> > 
> > 
> > [1]: 
> > https://www.apache.org/legal/release-policy.html#source-packages
> > 
> > 



Re: Sling Feature Maven Converter Plugin: Fix for failing IT tests

2020-01-10 Thread Robert Munteanu
Hi Andy,

On Thu, 2020-01-09 at 14:59 -0800, Andreas Schaefer wrote:
> Hi
> 
> I got the issue with the failing IT test fixed and now the Jenkins
> build 
> https://builds.apache.org/job/Sling/job/sling-feature-converter-maven-plugin/
> <
> https://builds.apache.org/job/Sling/job/sling-feature-converter-maven-plugin/
> > did pass.
> 
> If anyone could run a local tests to verify that would be great.
> 

Works perfectly for me, thanks a lot for getting to the bottom of this!

Robert

> I will create a release 1.0.4 soon and then restart the vote.
> 
> - Andy