date:20160610


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

Oliver Lietz commented on SLING-5777:
-

Bootstrap ITs are successful on Jenkins also.

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



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

[jira] [Commented] (SLING-5520) Update Oak to 1.4


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

Oliver Lietz commented on SLING-5520:
-

That doesn't look nice, but as long the repository shuts down clean not a bug.

Found the issue: OAK-2910, [Repository 
Initializer|https://issues.apache.org/jira/browse/OAK-2910?focusedCommentId=14560717&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14560717]s
 need to be active before {{OakSlingRepositoryManager}} is activated.

> Update Oak to 1.4
> -
>
> Key: SLING-5520
> URL: https://issues.apache.org/jira/browse/SLING-5520
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Launchpad, Oak
>Reporter: Oliver Lietz
> Fix For: Launchpad Karaf Features 0.2.0, JCR Oak Server 1.0.2, 
> Launchpad Builder 9
>
>
> Doing update in several more steps until Oak {{1.4}} is released due to major 
> changes, one of them being OAK-3842 (removed package exports, tracked in 
> SLING-5511).
> First updating to Oak {{1.3.14}} (latest pre OAK-3842 release) and then to 
> Oak {{1.3.15}}.
> Features deprecated for Oak {{1.4}} should be removed from 
> {{org.apache.sling.jcr.oak.server}}.



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

[jira] [Comment Edited] (SLING-5511) Adjust Oak package imports


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

Oliver Lietz edited comment on SLING-5511 at 6/10/16 8:30 PM:
--

[~rombert], I didn't encounter any issues related to package imports so far, 
will resolve.


was (Author: olli):
[~rombert], I didn't encounter any issues related to package imports so far, 
will close.

> Adjust Oak package imports
> --
>
> Key: SLING-5511
> URL: https://issues.apache.org/jira/browse/SLING-5511
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Oak
>Affects Versions: JCR Oak Server 1.0.0
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR Oak Server 1.0.2
>
>
> With OAK-3842 lots of package exports were removed. We have to adjust in 
> Sling accordingly when using Oak >= {{1.3.15}}.



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

[jira] [Resolved] (SLING-5511) Adjust Oak package imports


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

Oliver Lietz resolved SLING-5511.
-
Resolution: Done

> Adjust Oak package imports
> --
>
> Key: SLING-5511
> URL: https://issues.apache.org/jira/browse/SLING-5511
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Oak
>Affects Versions: JCR Oak Server 1.0.0
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR Oak Server 1.0.2
>
>
> With OAK-3842 lots of package exports were removed. We have to adjust in 
> Sling accordingly when using Oak >= {{1.3.15}}.



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

[jira] [Commented] (SLING-5511) Adjust Oak package imports


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

Oliver Lietz commented on SLING-5511:
-

[~rombert], I didn't encounter any issues related to package imports so far, 
will close.

> Adjust Oak package imports
> --
>
> Key: SLING-5511
> URL: https://issues.apache.org/jira/browse/SLING-5511
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Oak
>Affects Versions: JCR Oak Server 1.0.0
>Reporter: Oliver Lietz
> Fix For: JCR Oak Server 1.0.2
>
>
> With OAK-3842 lots of package exports were removed. We have to adjust in 
> Sling accordingly when using Oak >= {{1.3.15}}.



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

[jira] [Assigned] (SLING-5511) Adjust Oak package imports


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

Oliver Lietz reassigned SLING-5511:
---

Assignee: Oliver Lietz

> Adjust Oak package imports
> --
>
> Key: SLING-5511
> URL: https://issues.apache.org/jira/browse/SLING-5511
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Oak
>Affects Versions: JCR Oak Server 1.0.0
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: JCR Oak Server 1.0.2
>
>
> With OAK-3842 lots of package exports were removed. We have to adjust in 
> Sling accordingly when using Oak >= {{1.3.15}}.



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

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


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

Oliver Lietz commented on SLING-5777:
-

[~rombert], Bootstrap ITs are successful here: 

{noformat}
[INFO] Apache Sling Launchpad Karaf - Integration Tests ... SUCCESS [11:05 min]
[INFO] Apache Sling Launchpad Karaf - Launchpad Oak Tar Integration Tests 
FAILURE [02:20 min]
{noformat}

Let's see if build 
[947|https://builds.apache.org/view/S-Z/view/Sling/job/sling-contrib-1.7/947/] 
will succeed (SLING-5780).

Will investigate what's going wrong with Launchpad ITs (again) in SLING-3821:

{noformat}
Tests run: 511, Failures: 490, Errors: 18, Skipped: 2
{noformat}

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



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

[jira] [Closed] (SLING-5780) Remove org.apache.sling.auth.openid from build


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

Oliver Lietz closed SLING-5780.
---

> Remove org.apache.sling.auth.openid from build
> --
>
> Key: SLING-5780
> URL: https://issues.apache.org/jira/browse/SLING-5780
> Project: Sling
>  Issue Type: Task
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>
> The Maven repo for dyuproject 
> (http://dyuproject.googlecode.com/svn/repos/maven2) is gone:
> {noformat}
> [ERROR] Failed to execute goal on project org.apache.sling.auth.openid: Could 
> not resolve dependencies for project 
> org.apache.sling:org.apache.sling.auth.openid:bundle:1.0.5-SNAPSHOT: The 
> following artifacts could not be resolved: 
> com.dyuproject:dyuproject-openid:jar:1.1.7, 
> com.dyuproject:dyuproject-util:jar:1.1.7, 
> com.dyuproject:dyuproject-json:jar:1.1.7: Could not find artifact 
> com.dyuproject:dyuproject-openid:jar:1.1.7 in dyuproject-repo 
> (http://dyuproject.googlecode.com/svn/repos/maven2) -> [Help 1]
> {noformat}



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

[jira] [Resolved] (SLING-5780) Remove org.apache.sling.auth.openid from build


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

Oliver Lietz resolved SLING-5780.
-
Resolution: Done

[r1747788|https://svn.apache.org/r1747788]

> Remove org.apache.sling.auth.openid from build
> --
>
> Key: SLING-5780
> URL: https://issues.apache.org/jira/browse/SLING-5780
> Project: Sling
>  Issue Type: Task
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>
> The Maven repo for dyuproject 
> (http://dyuproject.googlecode.com/svn/repos/maven2) is gone:
> {noformat}
> [ERROR] Failed to execute goal on project org.apache.sling.auth.openid: Could 
> not resolve dependencies for project 
> org.apache.sling:org.apache.sling.auth.openid:bundle:1.0.5-SNAPSHOT: The 
> following artifacts could not be resolved: 
> com.dyuproject:dyuproject-openid:jar:1.1.7, 
> com.dyuproject:dyuproject-util:jar:1.1.7, 
> com.dyuproject:dyuproject-json:jar:1.1.7: Could not find artifact 
> com.dyuproject:dyuproject-openid:jar:1.1.7 in dyuproject-repo 
> (http://dyuproject.googlecode.com/svn/repos/maven2) -> [Help 1]
> {noformat}



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

[jira] [Created] (SLING-5780) Remove org.apache.sling.auth.openid from build

Oliver Lietz created SLING-5780:
---

 Summary: Remove org.apache.sling.auth.openid from build
 Key: SLING-5780
 URL: https://issues.apache.org/jira/browse/SLING-5780
 Project: Sling
  Issue Type: Task
Reporter: Oliver Lietz
Assignee: Oliver Lietz


The Maven repo for dyuproject 
(http://dyuproject.googlecode.com/svn/repos/maven2) is gone:

{noformat}
[ERROR] Failed to execute goal on project org.apache.sling.auth.openid: Could 
not resolve dependencies for project 
org.apache.sling:org.apache.sling.auth.openid:bundle:1.0.5-SNAPSHOT: The 
following artifacts could not be resolved: 
com.dyuproject:dyuproject-openid:jar:1.1.7, 
com.dyuproject:dyuproject-util:jar:1.1.7, 
com.dyuproject:dyuproject-json:jar:1.1.7: Could not find artifact 
com.dyuproject:dyuproject-openid:jar:1.1.7 in dyuproject-repo 
(http://dyuproject.googlecode.com/svn/repos/maven2) -> [Help 1]
{noformat}



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

[jira] [Updated] (SLING-5776) Update to Oak 1.5.3


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

Oliver Lietz updated SLING-5776:

Issue Type: Improvement  (was: Bug)

> Update to Oak 1.5.3
> ---
>
> Key: SLING-5776
> URL: https://issues.apache.org/jira/browse/SLING-5776
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR, Launchpad, Oak
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Launchpad Karaf Features 0.2.0, Launchpad Karaf 
> Integration Tests 0.2.0, JCR Oak Server 1.0.2, Launchpad Builder 9
>
>




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

[jira] [Commented] (SLING-5776) Update to Oak 1.5.3


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

Oliver Lietz commented on SLING-5776:
-

Looks good, [~rombert]. Thanks. Test added for bundle 
{{org.apache.jackrabbit.oak-jcr}} in [r1747780|https://svn.apache.org/r1747780].

> Update to Oak 1.5.3
> ---
>
> Key: SLING-5776
> URL: https://issues.apache.org/jira/browse/SLING-5776
> Project: Sling
>  Issue Type: Bug
>  Components: JCR, Launchpad, Oak
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Launchpad Karaf Features 0.2.0, Launchpad Karaf 
> Integration Tests 0.2.0, JCR Oak Server 1.0.2, Launchpad Builder 9
>
>




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

[jira] [Updated] (SLING-5776) Update to Oak 1.5.3


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

Oliver Lietz updated SLING-5776:

Fix Version/s: Launchpad Builder 9
   Launchpad Karaf Integration Tests 0.2.0
   Launchpad Karaf Features 0.2.0

> Update to Oak 1.5.3
> ---
>
> Key: SLING-5776
> URL: https://issues.apache.org/jira/browse/SLING-5776
> Project: Sling
>  Issue Type: Bug
>  Components: JCR, Launchpad, Oak
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Launchpad Karaf Features 0.2.0, Launchpad Karaf 
> Integration Tests 0.2.0, JCR Oak Server 1.0.2, Launchpad Builder 9
>
>




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

Re: Scripts, docs and locations

2016-06-10 Thread Oliver Lietz

On Friday 10 June 2016 14:51:43 Robert Munteanu wrote:
> Hi,

Hi Robert,

> We have a couple of scripts in the root folder:
> 
> - modules.py
> - update_dependencies.sh

- check_release_matches_tag.sh
- check_staged_release.sh

> 
> As they are not frequently used, I suggest we move them to
> 'tooling/release' or maybe 'tooling/scm' if appropriate.
> 
> Also, I'm not sure how to use update_dependencies.sh, there are no docs
> for it and invoking it directly ( Linux, bash 4.3, sed 4.2.2 ) errors
> out with 
> 
> sed: can't read
> s/1.3.16<\/oak.version>/1.4.0<\/oak.version>/
> 1: No such file or directory
> sed: can't read
> s/1.3.16<\/oak.version>/1.4.0<\/oak.version>/
> 1: No such file or directory
> 
> (and many similar lines).
> 
> Opinions?

modules.py:

8<-
# simple script to find projects (modules) and print their artifact ids
# could help when moving from Subversion to Git 
(https://issues.apache.org/jira/browse/SLING-3987)

[...]

def usage():
print 'usage:', sys.argv[0], 'projects root, e.g. trunk or whiteboard'
8<-

update_dependencies.sh:

8<-
# sed (BSD only) commands to change versions
# TODO make GNU compatible

[...]

# Oak
OAK_VERSION_CURRENT=1.3.16
OAK_VERSION_NEW=1.4.0
8<-

*_VERSION_CURRENT: the current version of dependencies
*_VERSION_NEW: the new version of dependencies

Not sure what is not obvious here. As I'm the only one using this scripts I 
will remove them from Subversion.

Regards,
O.

> 
> Robert

[jira] [Updated] (SLING-5779) LuceneIndexProviderService is sometimes not configured


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

Robert Munteanu updated SLING-5779:
---
Summary: LuceneIndexProviderService is sometimes not configured  (was: 
LuceneIndexProviderService sometimes is not configured)

> LuceneIndexProviderService is sometimes not configured
> --
>
> Key: SLING-5779
> URL: https://issues.apache.org/jira/browse/SLING-5779
> Project: Sling
>  Issue Type: Bug
>  Components: Launchpad
>Reporter: Robert Munteanu
> Fix For: Launchpad Builder 9
>
> Attachments: error.log.gz, stdout.log.gz
>
>
> (Setting version to Launchpad for now until we find out the root cause).
> From time to time I see the launchpad failing to start properly. The first 
> error that is visible is {noformat}10.06.2016 18:18:48.826 *ERROR* 
> [OsgiInstallerImpl] org.apache.jackrabbit.oak-lucene 
> [org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService(31)]
>  The activate method has thrown an exception (java.lang.NullPointerException: 
> Index directory cannot be determined as neither index directory path 
> [localIndexDir] nor repository home [repository.home] defined)
> java.lang.NullPointerException: Index directory cannot be determined as 
> neither index directory path [localIndexDir] nor repository home 
> [repository.home] defined
> at 
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:236){noformat}
> That's weird since the provisioning model holds all the configurations and 
> the relevant bundles are present in the {{:boot}} feature → Start Level 1.
> My launchpad jar was built from r1747733 ( but of course SNAPSHOT 
> dependencies mean that someone else building the launchpad will not get the 
> same exact output ).



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

[jira] [Created] (SLING-5779) LuceneIndexProviderService sometimes is not configured

Robert Munteanu created SLING-5779:
--

 Summary: LuceneIndexProviderService sometimes is not configured
 Key: SLING-5779
 URL: https://issues.apache.org/jira/browse/SLING-5779
 Project: Sling
  Issue Type: Bug
  Components: Launchpad
Reporter: Robert Munteanu
 Fix For: Launchpad Builder 9
 Attachments: error.log.gz, stdout.log.gz

(Setting version to Launchpad for now until we find out the root cause).

>From time to time I see the launchpad failing to start properly. The first 
>error that is visible is {noformat}10.06.2016 18:18:48.826 *ERROR* 
>[OsgiInstallerImpl] org.apache.jackrabbit.oak-lucene 
>[org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService(31)]
> The activate method has thrown an exception (java.lang.NullPointerException: 
>Index directory cannot be determined as neither index directory path 
>[localIndexDir] nor repository home [repository.home] defined)
java.lang.NullPointerException: Index directory cannot be determined as neither 
index directory path [localIndexDir] nor repository home [repository.home] 
defined
at 
com.google.common.base.Preconditions.checkNotNull(Preconditions.java:236){noformat}

That's weird since the provisioning model holds all the configurations and the 
relevant bundles are present in the {{:boot}} feature → Start Level 1.

My launchpad jar was built from r1747733 ( but of course SNAPSHOT dependencies 
mean that someone else building the launchpad will not get the same exact 
output ).



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

[jira] [Updated] (SLING-5779) LuceneIndexProviderService is sometimes not configured


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

Robert Munteanu updated SLING-5779:
---
Attachment: stdout.log.gz
error.log.gz

> LuceneIndexProviderService is sometimes not configured
> --
>
> Key: SLING-5779
> URL: https://issues.apache.org/jira/browse/SLING-5779
> Project: Sling
>  Issue Type: Bug
>  Components: Launchpad
>Reporter: Robert Munteanu
> Fix For: Launchpad Builder 9
>
> Attachments: error.log.gz, stdout.log.gz
>
>
> (Setting version to Launchpad for now until we find out the root cause).
> From time to time I see the launchpad failing to start properly. The first 
> error that is visible is {noformat}10.06.2016 18:18:48.826 *ERROR* 
> [OsgiInstallerImpl] org.apache.jackrabbit.oak-lucene 
> [org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService(31)]
>  The activate method has thrown an exception (java.lang.NullPointerException: 
> Index directory cannot be determined as neither index directory path 
> [localIndexDir] nor repository home [repository.home] defined)
> java.lang.NullPointerException: Index directory cannot be determined as 
> neither index directory path [localIndexDir] nor repository home 
> [repository.home] defined
> at 
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:236){noformat}
> That's weird since the provisioning model holds all the configurations and 
> the relevant bundles are present in the {{:boot}} feature → Start Level 1.
> My launchpad jar was built from r1747733 ( but of course SNAPSHOT 
> dependencies mean that someone else building the launchpad will not get the 
> same exact output ).



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

[jira] [Resolved] (SLING-5778) o.a.s.repoinit.oak-jcr does not start due to missing org.apache.sling.provisioning.model package


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

Robert Munteanu resolved SLING-5778.

Resolution: Fixed

Fixed in [r1747733|https://svn.apache.org/r1747733]

> o.a.s.repoinit.oak-jcr does not start due to missing 
> org.apache.sling.provisioning.model package
> 
>
> Key: SLING-5778
> URL: https://issues.apache.org/jira/browse/SLING-5778
> Project: Sling
>  Issue Type: Bug
>  Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Launchpad Builder 9
>
>
> {noformat}10.06.2016 17:59:25.220 *INFO* [OsgiInstallerImpl] 
> org.apache.sling.installer.core.impl.tasks.BundleStartTask Could not start 
> bundle org.apache.sling.repoinit.oak-jcr [129]. Reason: {}. Will retry.
> org.osgi.framework.BundleException: Unable to resolve 
> org.apache.sling.repoinit.oak-jcr [129](R 129.0): missing requirement 
> [org.apache.sling.repoinit.oak-jcr [129](R 129.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.apache.sling.provisioning.model)(version>=1.5.0)(!(version>=2.0.0)))
>  Unresolved requirements: [[org.apache.sling.repoinit.oak-jcr [129](R 129.0)] 
> osgi.wiring.package; 
> (&(osgi.wiring.package=org.apache.sling.provisioning.model)(version>=1.5.0)(!(version>=2.0.0)))]
> at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4111)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2117)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
> at 
> org.apache.sling.installer.core.impl.tasks.BundleStartTask.execute(BundleStartTask.java:93)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:847)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:689)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:265)
> at java.lang.Thread.run(Thread.java:745){noformat}



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

Re: Resource.getParent() on NonExistingResource

I am talking about 
https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L254
 

 here.
The best would be if the SyntheticResource would optionally get a list of 
possible resolved resource locations. If we add another constructor taking an 
additional List with possible resolved repository paths we would be 
able to consider that list in the getParent().
That way we would not directly rely on ResourceResolver.resolve() within 
getParent() but just try getParent() for the different possible repository 
paths until we find a matching one, or if we don't find a matching one return a 
NonExistingResource(), again being feeded with the same list of possible 
resolved repository paths.
WDYT?
Konrad


> On 10 Jun 2016, at 10:13, Carsten Ziegeler  wrote:
> 
> Konrad Windszus wrote
>> My use case is AEM:
>> I have an existing page containing some components (each one encapsulated in 
>> dedicated child resources).
>> Now the underlying template in AEM is extended (i.e. new fixed components 
>> have been added). For each of those a child resource is necessary, which 
>> does not exist yet on older pages (being created at a point in time, where 
>> the template did not have that component yet).
>> 
>> In Sightly we include those new components via data-sly-use with an explicit 
>> resourceType. Sightly will first try to get the child resource with that 
>> path. If it does not exist yet it will create a SyntheticResource with the 
>> given resource type.
>> For example to get the cloud service configuration we would need to get the 
>> (existing) container AEM page for the SyntheticResource. This currently 
>> fails, because of the issues mentioned.
>> 
>> If this would work, the component would be rendered fine (even acting on a 
>> SyntheticResource).
> 
> Ok, so I guess this can be easily solved in Sightly as this sounds to me
> like a Sightly use case.
> 
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[jira] [Created] (SLING-5778) o.a.s.repoinit.oak-jcr does not start due to missing org.apache.sling.provisioning.model package

Robert Munteanu created SLING-5778:
--

 Summary: o.a.s.repoinit.oak-jcr does not start due to missing 
org.apache.sling.provisioning.model package
 Key: SLING-5778
 URL: https://issues.apache.org/jira/browse/SLING-5778
 Project: Sling
  Issue Type: Bug
  Components: Launchpad
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: Launchpad Builder 9


{noformat}10.06.2016 17:59:25.220 *INFO* [OsgiInstallerImpl] 
org.apache.sling.installer.core.impl.tasks.BundleStartTask Could not start 
bundle org.apache.sling.repoinit.oak-jcr [129]. Reason: {}. Will retry.
org.osgi.framework.BundleException: Unable to resolve 
org.apache.sling.repoinit.oak-jcr [129](R 129.0): missing requirement 
[org.apache.sling.repoinit.oak-jcr [129](R 129.0)] osgi.wiring.package; 
(&(osgi.wiring.package=org.apache.sling.provisioning.model)(version>=1.5.0)(!(version>=2.0.0)))
 Unresolved requirements: [[org.apache.sling.repoinit.oak-jcr [129](R 129.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.apache.sling.provisioning.model)(version>=1.5.0)(!(version>=2.0.0)))]
at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4111)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2117)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
at 
org.apache.sling.installer.core.impl.tasks.BundleStartTask.execute(BundleStartTask.java:93)
at 
org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:847)
at 
org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:689)
at 
org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:265)
at java.lang.Thread.run(Thread.java:745){noformat}



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

Re: Resource.getParent() on NonExistingResource

I only propose to change getParent() on NonExistingResource. Right now we have 
the situation that getParent() would just return the wrong NonExistingResource! 
So what we could do is to rely on resolve() as a fallback in case the regular 
way does not succeed. That would not make things any worse than they currently 
are. For real resources the getParent() handling would not be touched at all.

But I know that even the solution of relying on RR.resolve(String) is not 
optimal, as the resource resolver mapping is only 100% functional in case you 
also consider the request (which you don't have at hand at that point in time).
Maybe someone else has another good idea on how to solve this...
Thanks,
Konrad


> On 10 Jun 2016, at 16:24, Rob Ryan  wrote:
> 
> Regardless of what other problem may exist; involving resolve() in
> getParent() isn't a solution.
> 
> Resolve() operates on _URI_ paths. Not on resource paths. So proposing to
> involve resolve() in an implementation of getParent() doesn't make sense.
> 
> Resolve() makes special considerations of some constructs:
> _foo_bar to mean foo:bar. But a resource path could legitimately have
> _foo_bar as a component.
> 
> /* : star resource handling
> 
> 
> getParent() would likely be broken if it involved resolve() in such cases.
> 
> 
> -Rob
> 
> On 6/10/16, 12:12 AM, "Konrad Windszus"  wrote:
> 
>> There is one related problem with mapping:
>> 
>> Consider the case you have a resource resolver mapping from "/content/"
>> to "/". In the underlying repository you have a resource in
>> "/content/existingParent".
>> 
>> Now it might happen that a NonExistingResource is resolved for path
>> "/existingParent/nonExistingResource". Since this is pointing towards a
>> non-existing resource the mapping is not active (i.e. the path will not
>> contain "/content"). So you end up with a NonExistingResource with path
>> "/existingParent/nonExistingResource".
>> Now you call getParent() on this resource.
>> 
>> You would expect to end up with an existing resource in
>> "/content/existingParent" (because that path does exist in the
>> repository). Unfortunately due to the logic in
>> AbstractResource.getParent() this just calls ResourceResolver.getParent()
>> which will not use ResourceResolver.resolve(...) but rather
>> ResourceResolver.getResource(...) internally. So the mapping is not
>> considered here. Therefore no resource is found at "/existingParent",
>> although it does exist at "/content/existingParent".
>> 
>> This is unexpected and wrong in my opinion. So the NonExistingResource
>> should not rely on AbstractResource.getParent() at all, but rather use
>> its own implementation relying on ResourceResolver.resolve(...). WDYT?
>> 
>> Thanks,
>> Konrad
>> 
>> 
>>> On 02 Jun 2016, at 14:48, Konrad Windszus  wrote:
>>> 
>>> Thanks for the input.
>>> I created https://issues.apache.org/jira/browse/SLING-5757 for tracking
>>> that and I am going to propose a patch in there.
>>> 
>>> What about SyntheticResources which are not NonExistingResources? If we
>>> would follow the same approach as for NonExistingResources the question
>>> is, with which resource type the non-existing parent resource should be
>>> created? Or should a SyntheticResource (which is not a
>>> NonExistingResource) return a NonExistingResource for getParent()
>>> instead in that case?
>>> 
>>> Konrad
>>> 
>>> 
 On 02 Jun 2016, at 13:47, Daniel Klco  wrote:
 
 I would imagine that the only thing this would change is to make a
 small
 number of null checks irrelevant.
 
 +1 for making the behavior more consistent, however, the JavaDocs and
 release notes should be explicit about this change.
 
 On Thu, Jun 2, 2016 at 4:45 AM, Georg Henzler 
 wrote:
 
> Hi Konrad,
> 
> +1 for making the behaviour of NonExistingResource more consistent - I
> personally can't think of any places this would break existing code.
> 
> Regards
> Georg
> 
> 
> 
> On 2016-06-01 15:09, Konrad Windszus wrote:
> 
>> Hi Robert,
>> thanks for your input.
>> 
>> 
>>> I am not sure whether this would confuse existing clients though...
>>> 
>> 
>> I am also a bit worried about that but the only example I could think
>> of is a code trying to create the parent nodes or collecting the
>> non-existing ones by checking getParent() for null.
>> 
>> This would be pretty bad style IMHO therefore I would deliberately be
>> willing to break that code. I wonder what do others think about
>> changing the semantics of getParent() for NonExistingResource and
>> probably also SyntheticResource.
>> Konrad
>> 
> 
> 
>>> 
>> 
>

Re: Resource.getParent() on NonExistingResource

2016-06-10 Thread Rob Ryan

Regardless of what other problem may exist; involving resolve() in
getParent() isn't a solution.

Resolve() operates on _URI_ paths. Not on resource paths. So proposing to
involve resolve() in an implementation of getParent() doesn't make sense.

Resolve() makes special considerations of some constructs:
_foo_bar to mean foo:bar. But a resource path could legitimately have
_foo_bar as a component.

/* : star resource handling


getParent() would likely be broken if it involved resolve() in such cases.


-Rob

On 6/10/16, 12:12 AM, "Konrad Windszus"  wrote:

>There is one related problem with mapping:
>
>Consider the case you have a resource resolver mapping from "/content/"
>to "/". In the underlying repository you have a resource in
>"/content/existingParent".
>
>Now it might happen that a NonExistingResource is resolved for path
>"/existingParent/nonExistingResource". Since this is pointing towards a
>non-existing resource the mapping is not active (i.e. the path will not
>contain "/content"). So you end up with a NonExistingResource with path
>"/existingParent/nonExistingResource".
>Now you call getParent() on this resource.
>
>You would expect to end up with an existing resource in
>"/content/existingParent" (because that path does exist in the
>repository). Unfortunately due to the logic in
>AbstractResource.getParent() this just calls ResourceResolver.getParent()
>which will not use ResourceResolver.resolve(...) but rather
>ResourceResolver.getResource(...) internally. So the mapping is not
>considered here. Therefore no resource is found at "/existingParent",
>although it does exist at "/content/existingParent".
>
>This is unexpected and wrong in my opinion. So the NonExistingResource
>should not rely on AbstractResource.getParent() at all, but rather use
>its own implementation relying on ResourceResolver.resolve(...). WDYT?
>
>Thanks,
>Konrad
>
>
>> On 02 Jun 2016, at 14:48, Konrad Windszus  wrote:
>> 
>> Thanks for the input.
>> I created https://issues.apache.org/jira/browse/SLING-5757 for tracking
>>that and I am going to propose a patch in there.
>> 
>> What about SyntheticResources which are not NonExistingResources? If we
>>would follow the same approach as for NonExistingResources the question
>>is, with which resource type the non-existing parent resource should be
>>created? Or should a SyntheticResource (which is not a
>>NonExistingResource) return a NonExistingResource for getParent()
>>instead in that case?
>> 
>> Konrad
>> 
>> 
>>> On 02 Jun 2016, at 13:47, Daniel Klco  wrote:
>>> 
>>> I would imagine that the only thing this would change is to make a
>>>small
>>> number of null checks irrelevant.
>>> 
>>> +1 for making the behavior more consistent, however, the JavaDocs and
>>> release notes should be explicit about this change.
>>> 
>>> On Thu, Jun 2, 2016 at 4:45 AM, Georg Henzler 
>>>wrote:
>>> 
 Hi Konrad,
 
 +1 for making the behaviour of NonExistingResource more consistent - I
 personally can't think of any places this would break existing code.
 
 Regards
 Georg
 
 
 
 On 2016-06-01 15:09, Konrad Windszus wrote:
 
> Hi Robert,
> thanks for your input.
> 
> 
>> I am not sure whether this would confuse existing clients though...
>> 
> 
> I am also a bit worried about that but the only example I could think
> of is a code trying to create the parent nodes or collecting the
> non-existing ones by checking getParent() for null.
> 
> This would be pretty bad style IMHO therefore I would deliberately be
> willing to break that code. I wonder what do others think about
> changing the semantics of getParent() for NonExistingResource and
> probably also SyntheticResource.
> Konrad
> 
 
 
>> 
>

[jira] [Commented] (SLING-5520) Update Oak to 1.4


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

Robert Munteanu commented on SLING-5520:


[~olli] - the Repository is still reconfigured/restarted when I move the 
oak-server bundle to startLevel 15:

{noformat}
$ grep -e 'OakSlingRepositoryManager stop' sling/logs/error.log 
10.06.2016 17:00:28.745 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent: 
pid=org.apache.jackrabbit.oak.security.authentication.AuthenticationConfigurationImpl)]
 org.apache.sling.oak.server.OakSlingRepositoryManager stop: Repository still 
running, forcing shutdown
10.06.2016 17:00:29.693 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent: 
pid=org.apache.jackrabbit.oak.security.user.UserConfigurationImpl)] 
org.apache.sling.oak.server.OakSlingRepositoryManager stop: Repository still 
running, forcing shutdown
10.06.2016 17:00:30.467 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent: 
pid=org.apache.jackrabbit.oak.spi.security.user.action.DefaultAuthorizableActionProvider)]
 org.apache.sling.oak.server.OakSlingRepositoryManager stop: Repository still 
running, forcing shutdown
{noformat}

Do you consider this a bug in Sling? Just trying to make sure I capture the 
right information in the bug report.

> Update Oak to 1.4
> -
>
> Key: SLING-5520
> URL: https://issues.apache.org/jira/browse/SLING-5520
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Launchpad, Oak
>Reporter: Oliver Lietz
> Fix For: Launchpad Karaf Features 0.2.0, JCR Oak Server 1.0.2, 
> Launchpad Builder 9
>
>
> Doing update in several more steps until Oak {{1.4}} is released due to major 
> changes, one of them being OAK-3842 (removed package exports, tracked in 
> SLING-5511).
> First updating to Oak {{1.3.14}} (latest pre OAK-3842 release) and then to 
> Oak {{1.3.15}}.
> Features deprecated for Oak {{1.4}} should be removed from 
> {{org.apache.sling.jcr.oak.server}}.



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

RE: [VOTE] Release Apache Sling Testing JCR Mock 1.1.14, OSGi Mock 2.0.4, ResourceResolver Mock 1.1.14

2016-06-10 Thread Stefan Seifert

+1

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


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

Robert Munteanu resolved SLING-5777.

Resolution: Fixed

Fixed in [r1747710|https://svn.apache.org/r1747710]

[~olli] - I updated the Karaf feature as well, but some tests failed for me ( 
not sure when they started failing )

{noformat}  SlingLaunchpadOakTarIT.testAnonymousHasReadAccess » ClassNotFound 
de.flapdoodl...
  SlingLaunchpadOakTarIT.testAnonymousLoginA » ClassNotFound 
de.flapdoodle.embed...
  SlingLaunchpadOakTarIT.testAnonymousLoginB » ClassNotFound 
de.flapdoodle.embed...
  SlingLaunchpadOakTarIT.testCreateRetrieveNode » ClassNotFound 
de.flapdoodle.em...
  SlingLaunchpadOakTarIT.testCreateRetrieveSlingFolder » ClassNotFound 
de.flapdo...
  SlingLaunchpadOakTarIT.testExplicitAdminLogin » ClassNotFound 
de.flapdoodle.em...
  SlingLaunchpadOakTarIT.testLoginAdministrative » ClassNotFound 
de.flapdoodle.e...
  SlingLaunchpadOakTarIT.testMultiValueInputStream » ClassNotFound 
de.flapdoodle...
  SlingLaunchpadOakTarIT.testNodetypeObservation » ClassNotFound 
de.flapdoodle.e...
  SlingLaunchpadOakTarIT.testRepositoryPresent » ClassNotFound 
de.flapdoodle.emb...
  SlingLaunchpadOakTarIT.testSingleValueInputStream » ClassNotFound 
de.flapdoodl...
  SlingLaunchpadOakTarIT.testSlingRepository » ClassNotFound 
de.flapdoodle.embed...
  SlingLaunchpadOakTarIT.testSqlQuery » ClassNotFound 
de.flapdoodle.embed.mongo
  SlingLaunchpadOakTarIT.testVarSlingExists » ClassNotFound 
de.flapdoodle.embed
  SlingLaunchpadOakTarIT.testWrongLogin » ClassNotFound 
de.flapdoodle.embed.mong...
  SlingLaunchpadOakTarIT.testXpathQueryWithMixin » ClassNotFound 
de.flapdoodle.e...
{noformat}

They don't seem related to my changes though but feel free to reopen and point 
out what I missed.

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



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

[jira] [Comment Edited] (SLING-5770) Allow to configure resource resolver mapping

2016-06-10 Thread Konrad Windszus (JIRA)


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

Konrad Windszus edited comment on SLING-5770 at 6/10/16 1:46 PM:
-

For that I need to implement my own custom context, I would rather prefer to do 
that in the setup of the test class itself. Have a look also at the related 
ticket https://wcm-io.atlassian.net/browse/WTES-18

Also I am still not sure this can work, because the 
{{ResourceResolverFactoryActivator}} is always registered as a service in 
https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/testing/mocks/sling-mock/src/main/java/org/apache/sling/testing/mock/sling/ResourceResolverFactoryInitializer.java#L128
 with a different configuration (no matter which configuration is otherwise 
already present in the system).


was (Author: kwin):
For that I need to implement my own custom context, I would rather prefer to do 
that in the setup of the test class itself.

Regarding properties to merge: Indeed I only want to merge with the default 
properties, so just setting the properties I want to change for the 
ConfigurationAdmin should be fine then (in my case only 
"resource.resolver.mapping").

> Allow to configure resource resolver mapping
> 
>
> Key: SLING-5770
> URL: https://issues.apache.org/jira/browse/SLING-5770
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing Sling Mock 1.6.2
>Reporter: Konrad Windszus
>
> Currently the {{ResourceResolverFactoryActivator}} being registered in 
> https://github.com/apache/sling/blob/trunk/testing/mocks/sling-mock/src/main/java/org/apache/sling/testing/mock/sling/ResourceResolverFactoryInitializer.java#L123
>  is not configured at all.
> Since resource resolver mapping is a topic which is often implemented in the 
> wrong way, it should be possible to setup some mapping for SlingContext to 
> allow to test in a more realistic way.



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

[jira] [Comment Edited] (SLING-5520) Update Oak to 1.4


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

Robert Munteanu edited comment on SLING-5520 at 6/10/16 1:44 PM:
-

{quote}There is still use of deprecated Oak API in OakSlingRepositoryManager 
but it can be postponed.{quote}

Is that the {{withAsync()}} call? I replaced it for SLING-5776.

{quote}AFAIK next stable Oak (1.6) will be released in 2017. I prefer upgrading 
to Oak 1.4.3 and releasing org.apache.sling.jcr.oak.server 1.0.2 first (and 
branch), so we can release launchpads without having to use unstable Oak 
1.5.{quote}

Well, we already went with unstable Oak releases so far and no one complained 
:-) The reason for updating to an unstable version is SLING-5777, which makes 
it really simple for users of the launchpad to upgrade Oak without having to 
rebuild .


was (Author: rombert):
{quote}There is still use of deprecated Oak API in OakSlingRepositoryManager 
but it can be postponed.{/quote}

Is that the {{withAsync()}} call? I replaced it for SLING-5776.

{quote}AFAIK next stable Oak (1.6) will be released in 2017. I prefer upgrading 
to Oak 1.4.3 and releasing org.apache.sling.jcr.oak.server 1.0.2 first (and 
branch), so we can release launchpads without having to use unstable Oak 
1.5.{/quote}

Well, we already went with unstable Oak releases so far and no one complained 
:-) The reason for updating to an unstable version is SLING-5777, which makes 
it really simple for users of the launchpad to upgrade Oak without having to 
rebuild .

> Update Oak to 1.4
> -
>
> Key: SLING-5520
> URL: https://issues.apache.org/jira/browse/SLING-5520
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Launchpad, Oak
>Reporter: Oliver Lietz
> Fix For: Launchpad Karaf Features 0.2.0, JCR Oak Server 1.0.2, 
> Launchpad Builder 9
>
>
> Doing update in several more steps until Oak {{1.4}} is released due to major 
> changes, one of them being OAK-3842 (removed package exports, tracked in 
> SLING-5511).
> First updating to Oak {{1.3.14}} (latest pre OAK-3842 release) and then to 
> Oak {{1.3.15}}.
> Features deprecated for Oak {{1.4}} should be removed from 
> {{org.apache.sling.jcr.oak.server}}.



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

[jira] [Commented] (SLING-5520) Update Oak to 1.4


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

Robert Munteanu commented on SLING-5520:


I am not sure about that, but I can try later :-) and file a bug if it still 
does not work.

> Update Oak to 1.4
> -
>
> Key: SLING-5520
> URL: https://issues.apache.org/jira/browse/SLING-5520
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Launchpad, Oak
>Reporter: Oliver Lietz
> Fix For: Launchpad Karaf Features 0.2.0, JCR Oak Server 1.0.2, 
> Launchpad Builder 9
>
>
> Doing update in several more steps until Oak {{1.4}} is released due to major 
> changes, one of them being OAK-3842 (removed package exports, tracked in 
> SLING-5511).
> First updating to Oak {{1.3.14}} (latest pre OAK-3842 release) and then to 
> Oak {{1.3.15}}.
> Features deprecated for Oak {{1.4}} should be removed from 
> {{org.apache.sling.jcr.oak.server}}.



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

Re: [VOTE] Release Apache Sling Testing JCR Mock 1.1.14, OSGi Mock 2.0.4, ResourceResolver Mock 1.1.14

+1

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

Re: [VOTE] Release Apache Sling Testing JCR Mock 1.1.14, OSGi Mock 2.0.4, ResourceResolver Mock 1.1.14

2016-06-10 Thread Robert Munteanu

On Fri, 2016-06-10 at 12:24 +, Stefan Seifert wrote:
> Please vote to approve this release:


+1

Robert

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

[jira] [Commented] (SLING-5520) Update Oak to 1.4


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

Robert Munteanu commented on SLING-5520:


{quote}There is still use of deprecated Oak API in OakSlingRepositoryManager 
but it can be postponed.{/quote}

Is that the {{withAsync()}} call? I replaced it for SLING-5776.

{quote}AFAIK next stable Oak (1.6) will be released in 2017. I prefer upgrading 
to Oak 1.4.3 and releasing org.apache.sling.jcr.oak.server 1.0.2 first (and 
branch), so we can release launchpads without having to use unstable Oak 
1.5.{/quote}

Well, we already went with unstable Oak releases so far and no one complained 
:-) The reason for updating to an unstable version is SLING-5777, which makes 
it really simple for users of the launchpad to upgrade Oak without having to 
rebuild .

> Update Oak to 1.4
> -
>
> Key: SLING-5520
> URL: https://issues.apache.org/jira/browse/SLING-5520
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Launchpad, Oak
>Reporter: Oliver Lietz
> Fix For: Launchpad Karaf Features 0.2.0, JCR Oak Server 1.0.2, 
> Launchpad Builder 9
>
>
> Doing update in several more steps until Oak {{1.4}} is released due to major 
> changes, one of them being OAK-3842 (removed package exports, tracked in 
> SLING-5511).
> First updating to Oak {{1.3.14}} (latest pre OAK-3842 release) and then to 
> Oak {{1.3.15}}.
> Features deprecated for Oak {{1.4}} should be removed from 
> {{org.apache.sling.jcr.oak.server}}.



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

[jira] [Commented] (SLING-5520) Update Oak to 1.4


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

Oliver Lietz commented on SLING-5520:
-

Do we still need start levels for setting up Oak properly (which is a bug in – 
not only – [~cziegeler]s opinion)?

> Update Oak to 1.4
> -
>
> Key: SLING-5520
> URL: https://issues.apache.org/jira/browse/SLING-5520
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Launchpad, Oak
>Reporter: Oliver Lietz
> Fix For: Launchpad Karaf Features 0.2.0, JCR Oak Server 1.0.2, 
> Launchpad Builder 9
>
>
> Doing update in several more steps until Oak {{1.4}} is released due to major 
> changes, one of them being OAK-3842 (removed package exports, tracked in 
> SLING-5511).
> First updating to Oak {{1.3.14}} (latest pre OAK-3842 release) and then to 
> Oak {{1.3.15}}.
> Features deprecated for Oak {{1.4}} should be removed from 
> {{org.apache.sling.jcr.oak.server}}.



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

[jira] [Commented] (SLING-5520) Update Oak to 1.4


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

Oliver Lietz commented on SLING-5520:
-

There is still use of deprecated Oak API in {{OakSlingRepositoryManager}} but 
it can be postponed.

AFAIK next stable Oak (1.6) will be released in 2017. I prefer upgrading to Oak 
1.4.3 and releasing {{org.apache.sling.jcr.oak.server}} 1.0.2 first (and 
branch), so we can release launchpads without having to use _unstable_ Oak 1.5.

I've added a script for updating some dependencies: 
https://github.com/apache/sling/blob/trunk/update_dependencies.sh

> Update Oak to 1.4
> -
>
> Key: SLING-5520
> URL: https://issues.apache.org/jira/browse/SLING-5520
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Launchpad, Oak
>Reporter: Oliver Lietz
> Fix For: Launchpad Karaf Features 0.2.0, JCR Oak Server 1.0.2, 
> Launchpad Builder 9
>
>
> Doing update in several more steps until Oak {{1.4}} is released due to major 
> changes, one of them being OAK-3842 (removed package exports, tracked in 
> SLING-5511).
> First updating to Oak {{1.3.14}} (latest pre OAK-3842 release) and then to 
> Oak {{1.3.15}}.
> Features deprecated for Oak {{1.4}} should be removed from 
> {{org.apache.sling.jcr.oak.server}}.



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

[VOTE] Release Apache Sling Testing JCR Mock 1.1.14, OSGi Mock 2.0.4, ResourceResolver Mock 1.1.14

2016-06-10 Thread Stefan Seifert

Hi,

We solved issues in this releases:

Apache Sling Testing JCR Mock 1.1.14 (2 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12334801

Apache Sling Testing OSGi Mock 2.0.4 (2 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12334799

Apache Sling Testing ResourceResolver Mock 1.1.14 (1 issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/12334803


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

You can use this UNIX script to download the release and verify the signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1462 /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.


stefan

Merging oak-server and it-jackrabbit-oak

2016-06-10 Thread Robert Munteanu

Hi,

Right now we have the oak glue code located in bundles/jcr/jackrabbit-
oak and the ITs for the oak integration located in bundles/jcr/it-
jackrabbit-oak.

This makes updating Oak a bit harder since:

- you have to update the oak version in both the bundles and the ITs
- you have to build and install the bundle and then run the ITs ( bonus
points if you need to update the bundle version in the IT project )

I intend to merge the two projects next week so that the ITs are
located in the oak-server project.

If anyone sees a reason not to, please let me know.

Thanks,

Robert

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

Robert Munteanu created SLING-5777:
--

 Summary: Stop embedding oak-jcr in the o.a.s.jcr.oak.server bundle
 Key: SLING-5777
 URL: https://issues.apache.org/jira/browse/SLING-5777
 Project: Sling
  Issue Type: Bug
  Components: Oak
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: JCR Oak Server 1.0.2


We should no longer embed the oak-jcr bundle, as it makes upgrading new Oak 
version harder, since we need to update both the oak-server bundle and the 
launchpad.



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

[jira] [Commented] (SLING-5511) Adjust Oak package imports


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

Robert Munteanu commented on SLING-5511:


[~olli] - is there anything left to be done here?

> Adjust Oak package imports
> --
>
> Key: SLING-5511
> URL: https://issues.apache.org/jira/browse/SLING-5511
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Oak
>Affects Versions: JCR Oak Server 1.0.0
>Reporter: Oliver Lietz
> Fix For: JCR Oak Server 1.0.2
>
>
> With OAK-3842 lots of package exports were removed. We have to adjust in 
> Sling accordingly when using Oak >= {{1.3.15}}.



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

[jira] [Resolved] (SLING-5776) Update to Oak 1.5.3


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

Robert Munteanu resolved SLING-5776.

Resolution: Fixed

Fixed in [r1747690|https://svn.apache.org/r1747690]:

- bundles/jcr/oak-server
- bundles/jcr/it-jackrabbit-oak
- launchpad/builder
- contrib/launchpad/karaf/org.apache.sling.launchpad.karaf-features

[~olli] - if I missed something related to the Karaf features, please let me 
know. I followed your previous commits

> Update to Oak 1.5.3
> ---
>
> Key: SLING-5776
> URL: https://issues.apache.org/jira/browse/SLING-5776
> Project: Sling
>  Issue Type: Bug
>  Components: JCR, Launchpad, Oak
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: JCR Oak Server 1.0.2
>
>




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

[jira] [Created] (SLING-5776) Update to Oak 1.5.3

Robert Munteanu created SLING-5776:
--

 Summary: Update to Oak 1.5.3
 Key: SLING-5776
 URL: https://issues.apache.org/jira/browse/SLING-5776
 Project: Sling
  Issue Type: Bug
  Components: JCR, Launchpad, Oak
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: JCR Oak Server 1.0.2






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

Re: Release of Testing ResourceResolverMock

Perfect, thanks.
Konrad

> On 10 Jun 2016, at 13:48, Stefan Seifert  wrote:
> 
> i will do the release as i want to release some of the other mock libs as 
> well today.
> 
> stefan
> 
> 
>> -Original Message-
>> From: Konrad Windszus [mailto:konra...@gmx.de]
>> Sent: Thursday, June 09, 2016 10:18 AM
>> To: dev@sling.apache.org
>> Subject: Release of Testing ResourceResolverMock
>> 
>> I would like to have a release of Testing ResourceResolver Mock 1.1.14 for
>> fix https://issues.apache.org/jira/browse/SLING-5673.
>> I am working on some issue related to NonExistingResource's and for that it
>> would be very handy to have proper testing support.
>> 
>> Should we wait for any more fixes? Otherwise I will start the release
>> process soon
>> Thanks,
>> Konrad
>> 
>> 
> 
>

[jira] [Updated] (SLING-5478) Implement MockNode methods regarding mixin, reordering and move


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

Stefan Seifert updated SLING-5478:
--
 Assignee: (was: Stefan Seifert)
Fix Version/s: (was: Testing JCR Mock 1.1.14)

> Implement MockNode methods regarding mixin, reordering and move
> ---
>
> Key: SLING-5478
> URL: https://issues.apache.org/jira/browse/SLING-5478
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR, Testing
>Affects Versions: Testing JCR Mock 1.1.10
>Reporter: Danilo Cugia
>Priority: Minor
>  Labels: test
>
> Implement the following operations on a MockNode object:
> - Add mixin
> - Get index
> - Get mixin types
> - Node repositioning (node.orderBefore)
> - Remove mixin
> - Move
> PR: https://github.com/apache/sling/pull/121



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

Scripts, docs and locations

2016-06-10 Thread Robert Munteanu

Hi,

We have a couple of scripts in the root folder:

- modules.py
- update_dependencies.sh

As they are not frequently used, I suggest we move them to
'tooling/release' or maybe 'tooling/scm' if appropriate.

Also, I'm not sure how to use update_dependencies.sh, there are no docs
for it and invoking it directly ( Linux, bash 4.3, sed 4.2.2 ) errors
out with 

sed: can't read
s/1.3.16<\/oak.version>/1.4.0<\/oak.version>/
1: No such file or directory
sed: can't read
s/1.3.16<\/oak.version>/1.4.0<\/oak.version>/
1: No such file or directory

(and many similar lines).

Opinions?

Robert

[jira] [Commented] (SLING-5770) Allow to configure resource resolver mapping

2016-06-10 Thread Konrad Windszus (JIRA)


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

Konrad Windszus commented on SLING-5770:


For that I need to implement my own custom context, I would rather prefer to do 
that in the setup of the test class itself.

Regarding properties to merge: Indeed I only want to merge with the default 
properties, so just setting the properties I want to change for the 
ConfigurationAdmin should be fine then (in my case only 
"resource.resolver.mapping").

> Allow to configure resource resolver mapping
> 
>
> Key: SLING-5770
> URL: https://issues.apache.org/jira/browse/SLING-5770
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing Sling Mock 1.6.2
>Reporter: Konrad Windszus
>
> Currently the {{ResourceResolverFactoryActivator}} being registered in 
> https://github.com/apache/sling/blob/trunk/testing/mocks/sling-mock/src/main/java/org/apache/sling/testing/mock/sling/ResourceResolverFactoryInitializer.java#L123
>  is not configured at all.
> Since resource resolver mapping is a topic which is often implemented in the 
> wrong way, it should be possible to setup some mapping for SlingContext to 
> allow to test in a more realistic way.



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

[jira] [Commented] (SLING-5520) Update Oak to 1.4


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

Robert Munteanu commented on SLING-5520:


[~olli] - any more changes to be done here? I'd like to update to 1.5.3 ( 
separate task ) to see if we can stop embedding {{oak-jcr}}

> Update Oak to 1.4
> -
>
> Key: SLING-5520
> URL: https://issues.apache.org/jira/browse/SLING-5520
> Project: Sling
>  Issue Type: Task
>  Components: JCR, Launchpad, Oak
>Reporter: Oliver Lietz
> Fix For: Launchpad Karaf Features 0.2.0, JCR Oak Server 1.0.2, 
> Launchpad Builder 9
>
>
> Doing update in several more steps until Oak {{1.4}} is released due to major 
> changes, one of them being OAK-3842 (removed package exports, tracked in 
> SLING-5511).
> First updating to Oak {{1.3.14}} (latest pre OAK-3842 release) and then to 
> Oak {{1.3.15}}.
> Features deprecated for Oak {{1.4}} should be removed from 
> {{org.apache.sling.jcr.oak.server}}.



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

RE: Release of Testing ResourceResolverMock

2016-06-10 Thread Stefan Seifert

i will do the release as i want to release some of the other mock libs as well 
today.

stefan


>-Original Message-
>From: Konrad Windszus [mailto:konra...@gmx.de]
>Sent: Thursday, June 09, 2016 10:18 AM
>To: dev@sling.apache.org
>Subject: Release of Testing ResourceResolverMock
>
>I would like to have a release of Testing ResourceResolver Mock 1.1.14 for
>fix https://issues.apache.org/jira/browse/SLING-5673.
>I am working on some issue related to NonExistingResource's and for that it
>would be very handy to have proper testing support.
>
>Should we wait for any more fixes? Otherwise I will start the release
>process soon
>Thanks,
>Konrad
>
>

[jira] [Commented] (SLING-5770) Allow to configure resource resolver mapping


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

Stefan Seifert commented on SLING-5770:
---

if you do the same as in AemContextImpl and overwrite the setUp() method of 
SingContextImpl it should work early enough before the resource resolver 
factory is initialized.
what properties do you want to merge? by default only the default property 
defined in the SCR metadata are applied. 
MapUtil.propertiesMergeWithOsgiMetadata is really an implementation detail.

> Allow to configure resource resolver mapping
> 
>
> Key: SLING-5770
> URL: https://issues.apache.org/jira/browse/SLING-5770
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing Sling Mock 1.6.2
>Reporter: Konrad Windszus
>
> Currently the {{ResourceResolverFactoryActivator}} being registered in 
> https://github.com/apache/sling/blob/trunk/testing/mocks/sling-mock/src/main/java/org/apache/sling/testing/mock/sling/ResourceResolverFactoryInitializer.java#L123
>  is not configured at all.
> Since resource resolver mapping is a topic which is often implemented in the 
> wrong way, it should be possible to setup some mapping for SlingContext to 
> allow to test in a more realistic way.



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

[jira] [Resolved] (SLING-5775) jcr-mock: Support PropertyDefinition flags


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

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

Completed: At revision: 1747678  


> jcr-mock: Support PropertyDefinition flags
> --
>
> Key: SLING-5775
> URL: https://issues.apache.org/jira/browse/SLING-5775
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing JCR Mock 1.1.12
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: mock
> Fix For: Testing JCR Mock 1.1.14
>
>
> add support for this flag-methods of JCR PropertyDefinition:
> * isAutoCreated
> * isMandatory
> * isProtected
> * isFullTextSearchable
> * isQueryOrderable
> for sake of simplicity we just return false for all of them.



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

[jira] [Created] (SLING-5775) jcr-mock: Support PropertyDefinition flags

Stefan Seifert created SLING-5775:
-

 Summary: jcr-mock: Support PropertyDefinition flags
 Key: SLING-5775
 URL: https://issues.apache.org/jira/browse/SLING-5775
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Affects Versions: Testing JCR Mock 1.1.12
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Testing JCR Mock 1.1.14


add support for this flag-methods of JCR PropertyDefinition:
* isAutoCreated
* isMandatory
* isProtected
* isFullTextSearchable
* isQueryOrderable

for sake of simplicity we just return false for all of them.



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

[jira] [Resolved] (SLING-5774) jcr-mock: Support Node.getMixinNodeTypes


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

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

Completed: At revision: 1747677  


> jcr-mock: Support Node.getMixinNodeTypes
> 
>
> Key: SLING-5774
> URL: https://issues.apache.org/jira/browse/SLING-5774
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing JCR Mock 1.1.12
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
>  Labels: mock
> Fix For: Testing JCR Mock 1.1.14
>
>
> we should add a minimal support for Node.getMixinNodeTypes.
> we have no real mixin support in JCR mock, but can return an empty array to 
> signal that no mixing nodetypes are assigned.



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

[jira] [Created] (SLING-5774) jcr-mock: Support Node.getMixinNodeTypes

Stefan Seifert created SLING-5774:
-

 Summary: jcr-mock: Support Node.getMixinNodeTypes
 Key: SLING-5774
 URL: https://issues.apache.org/jira/browse/SLING-5774
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Affects Versions: Testing JCR Mock 1.1.12
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Testing JCR Mock 1.1.14


we should add a minimal support for Node.getMixinNodeTypes.
we have no real mixin support in JCR mock, but can return an empty array to 
signal that no mixing nodetypes are assigned.



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

[jira] [Commented] (SLING-5629) redirectAfterLogout prepends servlet context to the target, when it's already there

2016-06-10 Thread ASF GitHub Bot (JIRA)


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

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

Github user glucazeau closed the pull request at:

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


> redirectAfterLogout prepends servlet context to the target, when it's already 
> there
> ---
>
> Key: SLING-5629
> URL: https://issues.apache.org/jira/browse/SLING-5629
> Project: Sling
>  Issue Type: Bug
>  Components: Authentication
>Affects Versions: Auth Core 1.3.12
>Reporter: Guillaume Lucazeau
>Assignee: Carsten Ziegeler
> Fix For: Auth Core 1.3.14
>
>
> In SlingAuthenticator.redirectAfterLogout, a call is made to 
> AuthUtil.isRedirectValid(request, target) which expects the target to contain 
> the servlet context path.
> When the validation is made, the call for redirection appends the servlet 
> context to the same target, leading to a duplicated context:
> Line 1417: response.sendRedirect(request.getContextPath() + target);
> Calling 
> http://localhost:8080/dev/system/sling/logout?resource=/dev/content/node1.html
>  redirects to http://localhost:8080/dev/dev/content/node1.html



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

[GitHub] sling pull request #132: SLING-5629: do not prepend servlet context path on ...

2016-06-10 Thread glucazeau

Github user glucazeau closed the pull request at:

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


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

[jira] [Commented] (SLING-5461) Sightly quotes all markup attributes' values with double quotes

2016-06-10 Thread Radu Cotescu (JIRA)


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

Radu Cotescu commented on SLING-5461:
-

Please open a separate issue (as this one is closed) and try to reproduce it 
with Sightly >= 1.0.12.

> Sightly quotes all markup attributes' values with double quotes
> ---
>
> Key: SLING-5461
> URL: https://issues.apache.org/jira/browse/SLING-5461
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Sightly Engine 1.0.12
>
>
> Irrespective of how HTML attributes are quoted in a Sightly script, the 
> resulting output will always use double quotes ({{"}}), which will break 
> attributes that have been defined in the script to use single quotes ({{'}}).
> This issue affects developers who would like to define JSON structures in 
> {{data-}} attributes.



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

[jira] [Closed] (SLING-5738) Add support for configuring a pattern for the model files to be read

2016-06-10 Thread Carsten Ziegeler (JIRA)


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

Carsten Ziegeler closed SLING-5738.
---

> Add support for configuring a pattern for the model files to be read
> 
>
> Key: SLING-5738
> URL: https://issues.apache.org/jira/browse/SLING-5738
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Slingstart Maven Plugin 1.4.4
>
>
> Right now, the plugin reads all files ending with .txt or .model from the 
> configured directory. We should make the regexp for this configurable



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

[jira] [Closed] (SLING-5765) No way to remove an artifact from a special runmode

2016-06-10 Thread Carsten Ziegeler (JIRA)


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

Carsten Ziegeler closed SLING-5765.
---

> No way to remove an artifact from a special runmode
> ---
>
> Key: SLING-5765
> URL: https://issues.apache.org/jira/browse/SLING-5765
> Project: Sling
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: Sling Provisioning Model 1.4.2
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Sling Provisioning Model 1.4.4
>
>
> For example if a bundle is defined in the :standalone runmode, it's not 
> possible to remove it
> [artifacts runModes=:remove,:standalone] results in an error as only one 
> special run mode is allowed



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

[VOTE RESULT] Release Apache Sling Provisioning Model 1.4.4 and Apache Sling Slingstart Maven Plugin 1.4.4

The vote passes with three binding +1 votes


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

Re: Resource.getParent() on NonExistingResource

Konrad Windszus wrote
> My use case is AEM:
> I have an existing page containing some components (each one encapsulated in 
> dedicated child resources).
> Now the underlying template in AEM is extended (i.e. new fixed components 
> have been added). For each of those a child resource is necessary, which does 
> not exist yet on older pages (being created at a point in time, where the 
> template did not have that component yet).
> 
> In Sightly we include those new components via data-sly-use with an explicit 
> resourceType. Sightly will first try to get the child resource with that 
> path. If it does not exist yet it will create a SyntheticResource with the 
> given resource type.
> For example to get the cloud service configuration we would need to get the 
> (existing) container AEM page for the SyntheticResource. This currently 
> fails, because of the issues mentioned.
> 
> If this would work, the component would be rendered fine (even acting on a 
> SyntheticResource).

Ok, so I guess this can be easily solved in Sightly as this sounds to me
like a Sightly use case.

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

Re: svn commit: r1747400 - /sling/trunk/testing/http/clients/src/test/java/org/apache/sling/testing/DelayRequestInterceptorTest.java

2016-06-10 Thread Andrei Dulvac

Hi Robert,

That's a unit test for the sling http testing clients themselves and I only
made that change to test my svn rights :)
But thanks for pointing that out, I'll make sure to use the
timeoutsprovider wherever there's a sleep in the tooling.
Thanks.

On Thu, Jun 9, 2016 at 2:53 PM Robert Munteanu  wrote:

> Hi Andrei,
>
> On Wed, 2016-06-08 at 14:30 +, dul...@apache.org wrote:
> > -DelayRequestInterceptor interceptor = new
> > DelayRequestInterceptor(1000);
> > +DelayRequestInterceptor interceptor = new
> > DelayRequestInterceptor(700);
>
> This type of timeout tweaking might be better served by using a
> TimeoutsProvider [1] , which has a configurable multiplier.
>
> Thanks,
>
> Robert
>
>
> [1]: https://github.com/apache/sling/blob/bbe394c21d8fe449dfd01b0f1c3e4
> f102dbbfda7/testing/tools/src/main/java/org/apache/sling/testing/tools/
> sling/TimeoutsProvider.java
> 
>

Re: Resource.getParent() on NonExistingResource

My use case is AEM:
I have an existing page containing some components (each one encapsulated in 
dedicated child resources).
Now the underlying template in AEM is extended (i.e. new fixed components have 
been added). For each of those a child resource is necessary, which does not 
exist yet on older pages (being created at a point in time, where the template 
did not have that component yet).

In Sightly we include those new components via data-sly-use with an explicit 
resourceType. Sightly will first try to get the child resource with that path. 
If it does not exist yet it will create a SyntheticResource with the given 
resource type.
For example to get the cloud service configuration we would need to get the 
(existing) container AEM page for the SyntheticResource. This currently fails, 
because of the issues mentioned.

If this would work, the component would be rendered fine (even acting on a 
SyntheticResource).
Konrad

> On 10 Jun 2016, at 09:48, Carsten Ziegeler  wrote:
> 
> Konrad Windszus wrote
>> This is complex to solve for the client (and kind of unexpected that this is 
>> not working).
>> So what speaks against supporting this use case properly in Sling.
>> Maybe you can elaborate a bit on 
>>> I think calling resolve() for traversal is totally unexpected.
>> 
>> IMHO the complex cases should be nicely covered by Sling (instead of adding 
>> that burden to each client).
>> Of course calling resolve() would only be done for the NonExistingResource 
>> (and maybe the SyntheticResource). The handling for regular existing 
>> resources should stay exactly as is (i.e. not relying on resolve() at all).
>> 
>> I meanwhile opened https://issues.apache.org/jira/browse/SLING-5773 
>>  about this problem.
>> 
> 
> The only place where you get a NonExistingResource is the resolve
> method, getResource returns null. As this is known, whoever is calling
> resolve() can check whether the returned resource is a
> NonExistingResource, then call resolve with the parent path or whatever.
> 
> What is your use case?
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Resource.getParent() on NonExistingResource

2016-06-10 Thread Michael Dürig

On 10.6.16 9:26 , Carsten Ziegeler wrote:

I think calling resolve() for traversal is totally unexpected. Now
looking at this, I'm really wondering if it was a good idea to implement
getParent on NonExistingResource. Let the client deal with it instead of
adding complex special cases.

FWIW: in Oak we have a similar situation with Tree instances. Retrieving
a non existing child from a Tree instance returns a Tree instance whose
.exists() method returns false. Calling .getParent() on that non
existing Tree instance returns the original parent Tree instance from
which it was acquired.

Michael

Carsten

Konrad Windszus wrote

There is one related problem with mapping:

Consider the case you have a resource resolver mapping from "/content/" to "/". In the
underlying repository you have a resource in "/content/existingParent".

Now it might happen that a NonExistingResource is resolved for path
"/existingParent/nonExistingResource". Since this is pointing towards a non-existing resource the
mapping is not active (i.e. the path will not contain "/content"). So you end up with a
NonExistingResource with path "/existingParent/nonExistingResource".
Now you call getParent() on this resource.

You would expect to end up with an existing resource in "/content/existingParent" (because that
path does exist in the repository). Unfortunately due to the logic in AbstractResource.getParent() this just
calls ResourceResolver.getParent() which will not use ResourceResolver.resolve(...) but rather
ResourceResolver.getResource(...) internally. So the mapping is not considered here. Therefore no resource is
found at "/existingParent", although it does exist at "/content/existingParent".

This is unexpected and wrong in my opinion. So the NonExistingResource should
not rely on AbstractResource.getParent() at all, but rather use its own
implementation relying on ResourceResolver.resolve(...). WDYT?

Thanks,
Konrad

On 02 Jun 2016, at 14:48, Konrad Windszus wrote:

Thanks for the input.
I created https://issues.apache.org/jira/browse/SLING-5757 for tracking that
and I am going to propose a patch in there.

What about SyntheticResources which are not NonExistingResources? If we would
follow the same approach as for NonExistingResources the question is, with
which resource type the non-existing parent resource should be created? Or
should a SyntheticResource (which is not a NonExistingResource) return a
NonExistingResource for getParent() instead in that case?

Konrad

On 02 Jun 2016, at 13:47, Daniel Klco wrote:

I would imagine that the only thing this would change is to make a small
number of null checks irrelevant.

+1 for making the behavior more consistent, however, the JavaDocs and
release notes should be explicit about this change.

On Thu, Jun 2, 2016 at 4:45 AM, Georg Henzler wrote:

Hi Konrad,

+1 for making the behaviour of NonExistingResource more consistent - I
personally can't think of any places this would break existing code.

Regards
Georg

On 2016-06-01 15:09, Konrad Windszus wrote:

Hi Robert,
thanks for your input.

I am not sure whether this would confuse existing clients though...

I am also a bit worried about that but the only example I could think
of is a code trying to create the parent nodes or collecting the
non-existing ones by checking getParent() for null.

This would be pretty bad style IMHO therefore I would deliberately be
willing to break that code. I wonder what do others think about
changing the semantics of getParent() for NonExistingResource and
probably also SyntheticResource.
Konrad

Re: Resource.getParent() on NonExistingResource

Konrad Windszus wrote
> This is complex to solve for the client (and kind of unexpected that this is 
> not working).
> So what speaks against supporting this use case properly in Sling.
> Maybe you can elaborate a bit on 
>> I think calling resolve() for traversal is totally unexpected.
> 
> IMHO the complex cases should be nicely covered by Sling (instead of adding 
> that burden to each client).
> Of course calling resolve() would only be done for the NonExistingResource 
> (and maybe the SyntheticResource). The handling for regular existing 
> resources should stay exactly as is (i.e. not relying on resolve() at all).
> 
> I meanwhile opened https://issues.apache.org/jira/browse/SLING-5773 
>  about this problem.
> 

The only place where you get a NonExistingResource is the resolve
method, getResource returns null. As this is known, whoever is calling
resolve() can check whether the returned resource is a
NonExistingResource, then call resolve with the parent path or whatever.

What is your use case?

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

Re: Resource.getParent() on NonExistingResource

This is complex to solve for the client (and kind of unexpected that this is 
not working).
So what speaks against supporting this use case properly in Sling.
Maybe you can elaborate a bit on 
> I think calling resolve() for traversal is totally unexpected.

IMHO the complex cases should be nicely covered by Sling (instead of adding 
that burden to each client).
Of course calling resolve() would only be done for the NonExistingResource (and 
maybe the SyntheticResource). The handling for regular existing resources 
should stay exactly as is (i.e. not relying on resolve() at all).

I meanwhile opened https://issues.apache.org/jira/browse/SLING-5773 
 about this problem.

Konrad


> On 10 Jun 2016, at 09:26, Carsten Ziegeler  wrote:
> 
> I think calling resolve() for traversal is totally unexpected. Now
> looking at this, I'm really wondering if it was a good idea to implement
> getParent on NonExistingResource. Let the client deal with it instead of
> adding complex special cases.
> 
> Carsten
> 
> Konrad Windszus wrote
>> There is one related problem with mapping:
>> 
>> Consider the case you have a resource resolver mapping from "/content/" to 
>> "/". In the underlying repository you have a resource in 
>> "/content/existingParent".
>> 
>> Now it might happen that a NonExistingResource is resolved for path 
>> "/existingParent/nonExistingResource". Since this is pointing towards a 
>> non-existing resource the mapping is not active (i.e. the path will not 
>> contain "/content"). So you end up with a NonExistingResource with path  
>> "/existingParent/nonExistingResource".
>> Now you call getParent() on this resource.
>> 
>> You would expect to end up with an existing resource in 
>> "/content/existingParent" (because that path does exist in the repository). 
>> Unfortunately due to the logic in AbstractResource.getParent() this just 
>> calls ResourceResolver.getParent() which will not use 
>> ResourceResolver.resolve(...) but rather ResourceResolver.getResource(...) 
>> internally. So the mapping is not considered here. Therefore no resource is 
>> found at "/existingParent", although it does exist at 
>> "/content/existingParent".
>> 
>> This is unexpected and wrong in my opinion. So the NonExistingResource 
>> should not rely on AbstractResource.getParent() at all, but rather use its 
>> own implementation relying on ResourceResolver.resolve(...). WDYT?
>> 
>> Thanks,
>> Konrad
>> 
>> 
>>> On 02 Jun 2016, at 14:48, Konrad Windszus  wrote:
>>> 
>>> Thanks for the input.
>>> I created https://issues.apache.org/jira/browse/SLING-5757 for tracking 
>>> that and I am going to propose a patch in there.
>>> 
>>> What about SyntheticResources which are not NonExistingResources? If we 
>>> would follow the same approach as for NonExistingResources the question is, 
>>> with which resource type the non-existing parent resource should be 
>>> created? Or should a SyntheticResource (which is not a NonExistingResource) 
>>> return a NonExistingResource for getParent() instead in that case?
>>> 
>>> Konrad
>>> 
>>> 
 On 02 Jun 2016, at 13:47, Daniel Klco  wrote:
 
 I would imagine that the only thing this would change is to make a small
 number of null checks irrelevant.
 
 +1 for making the behavior more consistent, however, the JavaDocs and
 release notes should be explicit about this change.
 
 On Thu, Jun 2, 2016 at 4:45 AM, Georg Henzler  wrote:
 
> Hi Konrad,
> 
> +1 for making the behaviour of NonExistingResource more consistent - I
> personally can't think of any places this would break existing code.
> 
> Regards
> Georg
> 
> 
> 
> On 2016-06-01 15:09, Konrad Windszus wrote:
> 
>> Hi Robert,
>> thanks for your input.
>> 
>> 
>>> I am not sure whether this would confuse existing clients though...
>>> 
>> 
>> I am also a bit worried about that but the only example I could think
>> of is a code trying to create the parent nodes or collecting the
>> non-existing ones by checking getParent() for null.
>> 
>> This would be pretty bad style IMHO therefore I would deliberately be
>> willing to break that code. I wonder what do others think about
>> changing the semantics of getParent() for NonExistingResource and
>> probably also SyntheticResource.
>> Konrad
>> 
> 
> 
>>> 
>> 
>> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Resource.getParent() on NonExistingResource

I think calling resolve() for traversal is totally unexpected. Now
looking at this, I'm really wondering if it was a good idea to implement
getParent on NonExistingResource. Let the client deal with it instead of
adding complex special cases.

Carsten

Konrad Windszus wrote
> There is one related problem with mapping:
> 
> Consider the case you have a resource resolver mapping from "/content/" to 
> "/". In the underlying repository you have a resource in 
> "/content/existingParent".
> 
> Now it might happen that a NonExistingResource is resolved for path 
> "/existingParent/nonExistingResource". Since this is pointing towards a 
> non-existing resource the mapping is not active (i.e. the path will not 
> contain "/content"). So you end up with a NonExistingResource with path  
> "/existingParent/nonExistingResource".
> Now you call getParent() on this resource.
> 
> You would expect to end up with an existing resource in 
> "/content/existingParent" (because that path does exist in the repository). 
> Unfortunately due to the logic in AbstractResource.getParent() this just 
> calls ResourceResolver.getParent() which will not use 
> ResourceResolver.resolve(...) but rather ResourceResolver.getResource(...) 
> internally. So the mapping is not considered here. Therefore no resource is 
> found at "/existingParent", although it does exist at 
> "/content/existingParent".
> 
> This is unexpected and wrong in my opinion. So the NonExistingResource should 
> not rely on AbstractResource.getParent() at all, but rather use its own 
> implementation relying on ResourceResolver.resolve(...). WDYT?
> 
> Thanks,
> Konrad
> 
> 
>> On 02 Jun 2016, at 14:48, Konrad Windszus  wrote:
>>
>> Thanks for the input.
>> I created https://issues.apache.org/jira/browse/SLING-5757 for tracking that 
>> and I am going to propose a patch in there.
>>
>> What about SyntheticResources which are not NonExistingResources? If we 
>> would follow the same approach as for NonExistingResources the question is, 
>> with which resource type the non-existing parent resource should be created? 
>> Or should a SyntheticResource (which is not a NonExistingResource) return a 
>> NonExistingResource for getParent() instead in that case?
>>
>> Konrad
>>
>>
>>> On 02 Jun 2016, at 13:47, Daniel Klco  wrote:
>>>
>>> I would imagine that the only thing this would change is to make a small
>>> number of null checks irrelevant.
>>>
>>> +1 for making the behavior more consistent, however, the JavaDocs and
>>> release notes should be explicit about this change.
>>>
>>> On Thu, Jun 2, 2016 at 4:45 AM, Georg Henzler  wrote:
>>>
 Hi Konrad,

 +1 for making the behaviour of NonExistingResource more consistent - I
 personally can't think of any places this would break existing code.

 Regards
 Georg



 On 2016-06-01 15:09, Konrad Windszus wrote:

> Hi Robert,
> thanks for your input.
>
>
>> I am not sure whether this would confuse existing clients though...
>>
>
> I am also a bit worried about that but the only example I could think
> of is a code trying to create the parent nodes or collecting the
> non-existing ones by checking getParent() for null.
>
> This would be pretty bad style IMHO therefore I would deliberately be
> willing to break that code. I wonder what do others think about
> changing the semantics of getParent() for NonExistingResource and
> probably also SyntheticResource.
> Konrad
>


>>
> 
> 


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

[jira] [Created] (SLING-5773) NonExistingResource.getParent() must consider the resource resolver mapping

2016-06-10 Thread Konrad Windszus (JIRA)

Konrad Windszus created SLING-5773:
--

 Summary: NonExistingResource.getParent() must consider the 
resource resolver mapping
 Key: SLING-5773
 URL: https://issues.apache.org/jira/browse/SLING-5773
 Project: Sling
  Issue Type: Bug
  Components: API
Affects Versions: API 2.11.0
Reporter: Konrad Windszus
Assignee: Konrad Windszus


Consider the case you have a resource resolver mapping from "/content/" to "/". 
In the underlying repository you have a resource in "/content/existingParent".

Now it might happen that a NonExistingResource is resolved for path 
"/existingParent/nonExistingResource". Since this is pointing towards a 
non-existing resource the mapping is not active (i.e. the path will not contain 
"/content"). So you end up with a NonExistingResource with path  
"/existingParent/nonExistingResource".
Now you call getParent() on this resource.

You would expect to end up with an existing resource in 
"/content/existingParent" (because that path does exist in the repository). 
Unfortunately due to the logic in AbstractResource.getParent() this just calls 
ResourceResolver.getParent() which will not use ResourceResolver.resolve(...) 
but rather ResourceResolver.getResource(...) internally. So the mapping is not 
considered here. Therefore no resource is found at "/existingParent", although 
it does exist at "/content/existingParent".

This is unexpected and wrong in my opinion. So the NonExistingResource should 
not rely on AbstractResource.getParent() at all, but rather use its own 
implementation relying on ResourceResolver.resolve(...). 

See also http://www.mail-archive.com/dev@sling.apache.org/msg56405.html.
and the related ticket SLING-5757.



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

Re: Resource.getParent() on NonExistingResource