[jira] [Comment Edited] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver

[Antonio Sanso (JIRA)]

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

Antonio Sanso edited comment on SLING-5135 at 9/6/16 5:53 AM:
--

[~bdelacretaz] LGTM.
One little thing. I suspect that if we enable this as is it might break some 
stuff.
E.g. {{org.apache.sling.resourceresolver}} has {{loginAdministrative}} calls 
but is not on the white list.

Do we want an extra boolean config thats says {{enableWhiteList}}  or is over 
killing ?

On the other point is : do we want to have the same mechanism be applied for 
administrative ResourceResolver?


was (Author: asanso):
[~bdelacretaz] LGTM.
One little thing. I suspect that if we enable this as is it might break some 
stuff.
E.g. {{org.apache.sling.resourceresolver}} has {{loginAdministrative}} calls 
but is not on the white list.

Do we want an extra boolean config thats says {{enableWhiteList}}  or is over 
killing ?

> Whitelist legit usages of loginAdministrative and administrative 
> ResourceResolver
> -
>
> Key: SLING-5135
> URL: https://issues.apache.org/jira/browse/SLING-5135
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Antonio Sanso
>Assignee: Bertrand Delacretaz
> Attachments: SLING-5135.patch, SLING-5135.patch
>
>
> {{AbstractSlingRepositoryManager}} contains a method that disable 
> loginAdministrative support
> {code}
> /**
>  * Returns whether to disable the
>  * {@code SlingRepository.loginAdministrative} method or not.
>  *
>  * @return {@code true} if {@code SlingRepository.loginAdministrative} is
>  * disabled.
>  */
> public final boolean isDisableLoginAdministrative() 
> {code}
> This is a global configuration. It would be nice to have an extension of such 
> mechanism that contains a white list of (few) legit usage of 
> {{loginAdministrative}}



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

[jira] [Commented] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-5135:
--

[~bdelacretaz] LGTM.
One little thing. I suspect that if we enable this as is it might break some 
stuff.
E.g. {{org.apache.sling.resourceresolver}} has {{loginAdministrative}} calls 
but is not on the white list.

Do we want an extra boolean config thats says {{enableWhiteList}}  or is over 
killing ?

> Whitelist legit usages of loginAdministrative and administrative 
> ResourceResolver
> -
>
> Key: SLING-5135
> URL: https://issues.apache.org/jira/browse/SLING-5135
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Antonio Sanso
>Assignee: Bertrand Delacretaz
> Attachments: SLING-5135.patch, SLING-5135.patch
>
>
> {{AbstractSlingRepositoryManager}} contains a method that disable 
> loginAdministrative support
> {code}
> /**
>  * Returns whether to disable the
>  * {@code SlingRepository.loginAdministrative} method or not.
>  *
>  * @return {@code true} if {@code SlingRepository.loginAdministrative} is
>  * disabled.
>  */
> public final boolean isDisableLoginAdministrative() 
> {code}
> This is a global configuration. It would be nice to have an extension of such 
> mechanism that contains a white list of (few) legit usage of 
> {{loginAdministrative}}



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

Re: What's wrong with Sightly?

[Justin Edelson]

Simply put - because Adobe changed the language name. Since Adobe defines
the specification and Sling just contains the implementation, it makes
sense for the implementation to have the same name as the specification.
Otherwise, we are implementing something which no longer exists.

On Mon, Sep 5, 2016 at 2:16 PM Oliver Lietz  wrote:

> hi all,
>
> why do we rename Sightly in Sling back to HTL?
>
> Thanks,
> O.
>
>

[jira] [Commented] (SLING-6025) Context-Aware Config: Provide configuration parameter metadata

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6025:
-

There is something fishy about the current metatype specification, it talks on 
one hand over generic object identifiers but the interface only allows usage of 
PID and factory PID.

> Context-Aware Config: Provide configuration parameter metadata
> --
>
> Key: SLING-6025
> URL: https://issues.apache.org/jira/browse/SLING-6025
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata 
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor 
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter 
> metadata. by default the annotation interface classes are used for this. they 
> have to be detected on the runtime in the classpath when a new bundle is 
> deployed using an osgi extender pattern (quite similar to sling models). to 
> the annotation classes further annotations can be applied an class and 
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for 
> configurations which are defined and accessed with annotation classes, not 
> when the application used direct valuemap access or the low-level 
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can 
> ship the default configuration providing metadata detected from the deployed 
> annotation classes, but leave a door open to add other sources as well.



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

[jira] [Commented] (SLING-6036) ResourceBuilder: Reusing ResourceBuilder instances

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6036:
---

Revision: 1759351

[~bdelacretaz] please have a look at [these 
changes|https://github.com/apache/sling/commit/8d317a0ab6e9a4365cee9ace48585245e55ca609].
 all existing unit tests still pass, i've added a new one.
we can revert if if you think it does not fit into the resourcebuilder concept.

> ResourceBuilder: Reusing ResourceBuilder instances
> --
>
> Key: SLING-6036
> URL: https://issues.apache.org/jira/browse/SLING-6036
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Resource Builder 1.0.0
>
>
> follow-up from discussion in 
> [SLING-5356|https://issues.apache.org/jira/browse/SLING-5356?focusedCommentId=15458657#comment-15458657]
> B) reusing resourcebuilder instances
> example 2:
> {noformat}
> resourceBuilder = 
> getService(ResourceBuilder.class).forResolver(resourceResolver);
> resourceBuilder.resource("content/page1");
> resourceBuilder.resource("content/page2");
> {noformat}
> this produces not the expected result - it produces
> /content/page1
> /content/page1/content/page2
> instead of 
> /content/page1
> /content/page2
> it would be useful if the resourcebuilder returned by a resource method has a 
> new parent set, but not the builder instance initially applyed the resource 
> method on.
> currently the only way to get the expected result is something like:
> example 3:
> {noformat}
> resourceBuilder = 
> getService(ResourceBuilder.class).forResolver(resourceResolver);
> resourceBuilder.resource("content/page1")
> .atParent()
> resource("content/page2");
> {noformat}
> but if creating bigger content structures it makes sense to not use one 
> gigantic fluent line, but split if up in smaller parts.



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

Re: o.a.s.testing.paxeam, how to handle temporary SNAPSHOT requirements?

[Oliver Lietz]

On Monday 05 September 2016 14:43:42 Bertrand Delacretaz wrote:
> Hi,

Hi Bertrand,

> Working on SLING-5135 requires upgrading the jcr.base and
> jcr.oak-server bundles simultaneously.
> 
> For the oak-server integration tests to pass I had to add this to
> OakServerTestSupport in that module:
> 
>   protected Option launchpad() {
> +// TODO can we get this version number from our pom??
> +SlingOptions.versionResolver.setVersion("org.apache.sling",
> "org.apache.sling.jcr.base", "2.4.1-SNAPSHOT");
> 
> Is there a better way?
> 
> Like maybe "for this list of bundles, take the versions from the pom" ?

see SLING-6038 and my latest commit in JCR Oak Server.

Regards,
O.

> (that's not committed yet, I'll attach a patch to that ticket soon)
> 
> -Bertrand

[jira] [Commented] (SLING-6035) ResourceBuilder: Support absolute paths

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> ResourceBuilder: Support absolute paths
> ---
>
> Key: SLING-6035
> URL: https://issues.apache.org/jira/browse/SLING-6035
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Resource Builder 1.0.0
>
>
> follow-up from discussion in 
> [SLING-5356|https://issues.apache.org/jira/browse/SLING-5356?focusedCommentId=15458657#comment-15458657]
> A) why not supporting absolute paths for resource creation?
> example 1:
> {noformat}
> resourceBuilder = 
> getService(ResourceBuilder.class).forResolver(resourceResolver);
> resourceBuilder.resource("content/page1", "sling:config-ref", 
> "/conf/content/page1");
> {noformat}
> it would be clearer/cleaner to just write /content/page1 to make sure this 
> resource starts at the root, and not at an perhaps unknown parent location.
> currently it's completely forbidden to use absoulte paths.



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

[GitHub] sling pull request #165: SLING-6035 ResourceBuilder: Support absolute paths

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Resolved] (SLING-6035) ResourceBuilder: Support absolute paths

[Stefan Seifert (JIRA)]

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

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

Completed: At revision: 1759348  


> ResourceBuilder: Support absolute paths
> ---
>
> Key: SLING-6035
> URL: https://issues.apache.org/jira/browse/SLING-6035
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Resource Builder 1.0.0
>
>
> follow-up from discussion in 
> [SLING-5356|https://issues.apache.org/jira/browse/SLING-5356?focusedCommentId=15458657#comment-15458657]
> A) why not supporting absolute paths for resource creation?
> example 1:
> {noformat}
> resourceBuilder = 
> getService(ResourceBuilder.class).forResolver(resourceResolver);
> resourceBuilder.resource("content/page1", "sling:config-ref", 
> "/conf/content/page1");
> {noformat}
> it would be clearer/cleaner to just write /content/page1 to make sure this 
> resource starts at the root, and not at an perhaps unknown parent location.
> currently it's completely forbidden to use absoulte paths.



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

[jira] [Resolved] (SLING-6038) Provide convenient method to set versions from Maven project

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-6038.
-
Resolution: Done

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

> Provide convenient method to set versions from Maven project
> 
>
> Key: SLING-6038
> URL: https://issues.apache.org/jira/browse/SLING-6038
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.2
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Testing PaxExam 0.0.4
>
>
> issue reported by [~bdelacretaz] on dev@: [o.a.s.testing.paxeam, how to 
> handle temporary SNAPSHOT 
> requirements?|http://mail-archives.apache.org/mod_mbox/sling-dev/201609.mbox/%3cCAEWfVJkZEpz-gXA9S6w_D5pw2LiikH0=rylfnkb39beej2+...@mail.gmail.com%3e]



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

[jira] [Created] (SLING-6038) Provide convenient method to set versions from Maven project

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-6038:
---

 Summary: Provide convenient method to set versions from Maven 
project
 Key: SLING-6038
 URL: https://issues.apache.org/jira/browse/SLING-6038
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Affects Versions: Testing PaxExam 0.0.2
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: Testing PaxExam 0.0.4


issue reported by [~bdelacretaz] on dev@: [o.a.s.testing.paxeam, how to handle 
temporary SNAPSHOT 
requirements?|http://mail-archives.apache.org/mod_mbox/sling-dev/201609.mbox/%3cCAEWfVJkZEpz-gXA9S6w_D5pw2LiikH0=rylfnkb39beej2+...@mail.gmail.com%3e]



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

What's wrong with Sightly?

[Oliver Lietz]

hi all,

why do we rename Sightly in Sling back to HTL?

Thanks,
O.

Re: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.0, Apache Sling Scripting HTL Java Compiler 1.0.0, Apache Sling Scripting HTL Engine 1.0.20, Apache Sling Scripting HTL JS Use Provider 1.0.1

[Radu Cotescu]

+1

On Mon, 5 Sep 2016 at 18:59 Radu Cotescu  wrote:

> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Cheers,
> Radu
>

[VOTE] Release Apache Sling Scripting HTL Compiler 1.0.0, Apache Sling Scripting HTL Java Compiler 1.0.0, Apache Sling Scripting HTL Engine 1.0.20, Apache Sling Scripting HTL JS Use Provider 1.0.12, A

[Radu Cotescu]

Hi,

We solved a total of 19 issues for these releases:

*https://issues.apache.org/jira/browse/SLING/fixforversion/12338132
*

*https://issues.apache.org/jira/browse/SLING/fixforversion/12338213
*

*https://issues.apache.org/jira/browse/SLING/fixforversion/12335356
*

*https://issues.apache.org/jira/browse/SLING/fixforversion/12334026
*

*https://issues.apache.org/jira/browse/SLING/fixforversion/12333860
*

*https://issues.apache.org/jira/browse/SLING/fixforversion/12333861
*

*https://issues.apache.org/jira/browse/SLING/fixforversion/12336741
*

The most important features / improvements of these releases are:
1. the modularisation of the Sightly engine - now renamed to HTL (
https://issues.apache.org/jira/browse/SLING-6028) - into a frontend AST
compiler, a Java compiler and a scripting engine
2. a HTL Maven Plugin (compatible with m2e) that can be used to validate
scripts during build time

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

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 1517 /tmp/sling-staging

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

Cheers,
Radu

[jira] [Updated] (SLING-6032) Not sling pipe

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier updated SLING-6032:
---
Attachment: SLING-6032.patch

please find attached patch treating the issue :
- fix & test ReferencePipe (more precisely in the way its referee behaves with 
upper bindings),
- added setReference to the Pipe API so a pipe is "aware" it's referred by some 
other pipe, i need this e.g. to know wether there is a previous pipe
- extends ReferencePipe with NotPipe

> Not sling pipe
> --
>
> Key: SLING-6032
> URL: https://issues.apache.org/jira/browse/SLING-6032
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Nicolas Peltier
> Attachments: SLING-6032.patch
>
>
> a not sling pipe, working as a reference sling pipe would be useful:
> - output nothing if referred pipe has any output,
> - output input if referred pipe has no output



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

[jira] [Updated] (SLING-6028) Replace Sightly references with HTL in both code and documentation

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-6028:

Fix Version/s: Scripting HTL Models Use Provider 1.0.2
   Scripting HTL REPL 1.0.4
   Scripting HTL Engine 1.0.20
   Scripting HTL JS Use Provider 1.0.12

> Replace Sightly references with HTL in both code and documentation
> --
>
> Key: SLING-6028
> URL: https://issues.apache.org/jira/browse/SLING-6028
> Project: Sling
>  Issue Type: Task
>  Components: Documentation, Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10, Scripting 
> Sightly Engine 1.0.18, Scripting Sightly REPL 1.0.2, Scripting Sightly Models 
> Use Provider 1.0.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.12, Scripting HTL 
> Engine 1.0.20, Scripting HTL REPL 1.0.4, Scripting HTL Models Use Provider 
> 1.0.2
>
>
> Sightly references should be replaced with HTL in both code and documentation 
> in order to follow the renaming of the language. API and bundle names 
> providing it should not be changed.
> 1. https://docs.adobe.com/content/docs/en/htl/update.html
> 2. https://github.com/Adobe-Marketing-Cloud/htl-spec



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

[jira] [Updated] (SLING-6028) Replace Sightly references with HTL in both code and documentation

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-6028:

Affects Version/s: Scripting Sightly JS Use Provider 1.0.10
   Scripting Sightly Engine 1.0.18
   Scripting Sightly REPL 1.0.2
   Scripting Sightly Models Use Provider 1.0.0

> Replace Sightly references with HTL in both code and documentation
> --
>
> Key: SLING-6028
> URL: https://issues.apache.org/jira/browse/SLING-6028
> Project: Sling
>  Issue Type: Task
>  Components: Documentation, Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10, Scripting 
> Sightly Engine 1.0.18, Scripting Sightly REPL 1.0.2, Scripting Sightly Models 
> Use Provider 1.0.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>
> Sightly references should be replaced with HTL in both code and documentation 
> in order to follow the renaming of the language. API and bundle names 
> providing it should not be changed.
> 1. https://docs.adobe.com/content/docs/en/htl/update.html
> 2. https://github.com/Adobe-Marketing-Cloud/htl-spec



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

[jira] [Created] (SLING-6037) sling pipes additionnal bindings should be configurable as resources

[Nicolas Peltier (JIRA)]

Nicolas Peltier created SLING-6037:
--

 Summary: sling pipes additionnal bindings should be configurable 
as resources
 Key: SLING-6037
 URL: https://issues.apache.org/jira/browse/SLING-6037
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Nicolas Peltier


a bit like writers can be configured by adding a writers node, we should be 
able to add a bindings node to a pipe with configured additional bindings



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

[jira] [Commented] (SLING-6035) ResourceBuilder: Support absolute paths

[ASF GitHub Bot (JIRA)]

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

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

GitHub user stefanseifert opened a pull request:

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

SLING-6035 ResourceBuilder: Support absolute paths



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

$ git pull https://github.com/stefanseifert/sling 
feature/SLING-6035-resourcebuilder-abspath

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

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

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

This closes #165


commit e7b434bf30840b4c2236a8cf871aea12f3d8becd
Author: sseifert 
Date:   2016-09-05T16:40:45Z

SLING-6035 ResourceBuilder: Support absolute paths




> ResourceBuilder: Support absolute paths
> ---
>
> Key: SLING-6035
> URL: https://issues.apache.org/jira/browse/SLING-6035
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Resource Builder 1.0.0
>
>
> follow-up from discussion in 
> [SLING-5356|https://issues.apache.org/jira/browse/SLING-5356?focusedCommentId=15458657#comment-15458657]
> A) why not supporting absolute paths for resource creation?
> example 1:
> {noformat}
> resourceBuilder = 
> getService(ResourceBuilder.class).forResolver(resourceResolver);
> resourceBuilder.resource("content/page1", "sling:config-ref", 
> "/conf/content/page1");
> {noformat}
> it would be clearer/cleaner to just write /content/page1 to make sure this 
> resource starts at the root, and not at an perhaps unknown parent location.
> currently it's completely forbidden to use absoulte paths.



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

[GitHub] sling pull request #165: SLING-6035 ResourceBuilder: Support absolute paths

[stefanseifert]

GitHub user stefanseifert opened a pull request:

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

SLING-6035 ResourceBuilder: Support absolute paths



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

$ git pull https://github.com/stefanseifert/sling 
feature/SLING-6035-resourcebuilder-abspath

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

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

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

This closes #165


commit e7b434bf30840b4c2236a8cf871aea12f3d8becd
Author: sseifert 
Date:   2016-09-05T16:40:45Z

SLING-6035 ResourceBuilder: Support absolute paths




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

[jira] [Updated] (SLING-5254) Remove getAdministrativeResourceResolver() from the Sightly JS Provider

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-5254:

Fix Version/s: (was: Scripting Sightly JS Use Provider 1.0.12)

> Remove getAdministrativeResourceResolver() from the Sightly JS Provider
> ---
>
> Key: SLING-5254
> URL: https://issues.apache.org/jira/browse/SLING-5254
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.14
>
>
> 1 occurrence in 
> {{org.apache.sling.scripting.sightly.js.impl.jsapi.SlyBindingsValuesProvider}}.



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

[jira] [Updated] (SLING-5254) Remove getAdministrativeResourceResolver() from the Sightly JS Provider

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-5254:

Fix Version/s: Scripting HTL JS Use Provider 1.0.14

> Remove getAdministrativeResourceResolver() from the Sightly JS Provider
> ---
>
> Key: SLING-5254
> URL: https://issues.apache.org/jira/browse/SLING-5254
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Sightly JS Use Provider 1.0.12, Scripting HTL 
> JS Use Provider 1.0.14
>
>
> 1 occurrence in 
> {{org.apache.sling.scripting.sightly.js.impl.jsapi.SlyBindingsValuesProvider}}.



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

[jira] [Created] (SLING-6036) ResourceBuilder: Reusing ResourceBuilder instances

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6036:
-

 Summary: ResourceBuilder: Reusing ResourceBuilder instances
 Key: SLING-6036
 URL: https://issues.apache.org/jira/browse/SLING-6036
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Resource Builder 1.0.0


follow-up from discussion in 
[SLING-5356|https://issues.apache.org/jira/browse/SLING-5356?focusedCommentId=15458657#comment-15458657]

B) reusing resourcebuilder instances
example 2:
{noformat}
resourceBuilder = 
getService(ResourceBuilder.class).forResolver(resourceResolver);
resourceBuilder.resource("content/page1");
resourceBuilder.resource("content/page2");
{noformat}
this produces not the expected result - it produces
/content/page1
/content/page1/content/page2
instead of 
/content/page1
/content/page2

it would be useful if the resourcebuilder returned by a resource method has a 
new parent set, but not the builder instance initially applyed the resource 
method on.
currently the only way to get the expected result is something like:

example 3:
{noformat}
resourceBuilder = 
getService(ResourceBuilder.class).forResolver(resourceResolver);
resourceBuilder.resource("content/page1")
.atParent()
resource("content/page2");
{noformat}

but if creating bigger content structures it makes sense to not use one 
gigantic fluent line, but split if up in smaller parts.




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

[jira] [Updated] (SLING-5787) Modularise the Sightly script engine

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-5787:

Fix Version/s: Scripting HTL Java Compiler 1.0.0
   Scripting HTL Compiler 1.0.0

> Modularise the Sightly script engine
> 
>
> Key: SLING-5787
> URL: https://issues.apache.org/jira/browse/SLING-5787
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.18
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.20, Scripting HTL Compiler 
> 1.0.0, Scripting HTL Java Compiler 1.0.0
>
>
> The Sightly script engine should be broken into three modules:
> # a Sightly frontend compiler that interprets Sightly scripts and produces an 
> Abstract Syntax Tree (AST)
> # a Sightly Java backend compiler that interprets the AST and produces Java 
> class files
> # a Compilable Script Engine that reuses the previous two modules



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

[jira] [Updated] (SLING-5787) Modularise the Sightly script engine

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-5787:

Affects Version/s: Scripting Sightly Engine 1.0.18

> Modularise the Sightly script engine
> 
>
> Key: SLING-5787
> URL: https://issues.apache.org/jira/browse/SLING-5787
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.18
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.20, Scripting HTL Compiler 
> 1.0.0, Scripting HTL Java Compiler 1.0.0
>
>
> The Sightly script engine should be broken into three modules:
> # a Sightly frontend compiler that interprets Sightly scripts and produces an 
> Abstract Syntax Tree (AST)
> # a Sightly Java backend compiler that interprets the AST and produces Java 
> class files
> # a Compilable Script Engine that reuses the previous two modules



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

[jira] [Created] (SLING-6035) ResourceBuilder: Support absolute paths

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6035:
-

 Summary: ResourceBuilder: Support absolute paths
 Key: SLING-6035
 URL: https://issues.apache.org/jira/browse/SLING-6035
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Priority: Minor
 Fix For: Resource Builder 1.0.0


follow-up from discussion in 
[SLING-5356|https://issues.apache.org/jira/browse/SLING-5356?focusedCommentId=15458657#comment-15458657]

A) why not supporting absolute paths for resource creation?
example 1:
{noformat}
resourceBuilder = 
getService(ResourceBuilder.class).forResolver(resourceResolver);
resourceBuilder.resource("content/page1", "sling:config-ref", 
"/conf/content/page1");
{noformat}
it would be clearer/cleaner to just write /content/page1 to make sure this 
resource starts at the root, and not at an perhaps unknown parent location.
currently it's completely forbidden to use absoulte paths.



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

[jira] [Commented] (SLING-6031) Teleporter.getService() should wait for required services

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6031:
---

i've created a PR for this: https://github.com/apache/sling/pull/164
integration tests are running fine then without the custom WaitFor class.

[~bdelacretaz] can you give it a short review? when ok i can apply it to the 
codebase.

> Teleporter.getService() should wait for required services
> -
>
> Key: SLING-6031
> URL: https://issues.apache.org/jira/browse/SLING-6031
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: JUnit Tests Teleporter 1.0.8, JUnit Core 1.0.18
>
>
> the JUnit TeleporterRule provides a getService method to get OSGi services 
> for the test run. this may return null for services that are not yet started.
> as a workaround some integration tests implement their own "WaitFor" pattern
> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/it/src/test/java/org/apache/sling/repoinit/it/WaitFor.java
> it should be supported by the teleporter rule directly.



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

[jira] [Commented] (SLING-6031) Teleporter.getService() should wait for required services

[ASF GitHub Bot (JIRA)]

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

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

GitHub user stefanseifert opened a pull request:

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

SLING-6031 Teleporter.getService() should wait for required services



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

$ git pull https://github.com/stefanseifert/sling 
feature/SLING-6031-teleporter-waitfor-service

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

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

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

This closes #164


commit 504d4d7684bc1aeb1e6c34b14e1967299d8b8af5
Author: sseifert 
Date:   2016-09-05T15:21:35Z

SLING-6031 Teleporter.getService() should wait for required services

commit 3e386a9ee26f88965514aa65bb98f5b2a1eddf1d
Author: sseifert 
Date:   2016-09-05T15:22:13Z

SLING-6031 switch to latest teleporter version not requiring a WaitFor class

commit 6f8d3451568b8eea8c8bb8f2bc236aa194680c2f
Author: sseifert 
Date:   2016-09-05T15:43:18Z

SLING-6031 switch to latest teleporter version not requiring a WaitFor class

commit a9bf7309da1edd3b63ce0c040fd755c48c2b3e77
Author: sseifert 
Date:   2016-09-05T15:47:11Z

SLING-6031 Teleporter.getService() should wait for required services




> Teleporter.getService() should wait for required services
> -
>
> Key: SLING-6031
> URL: https://issues.apache.org/jira/browse/SLING-6031
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: JUnit Tests Teleporter 1.0.8, JUnit Core 1.0.18
>
>
> the JUnit TeleporterRule provides a getService method to get OSGi services 
> for the test run. this may return null for services that are not yet started.
> as a workaround some integration tests implement their own "WaitFor" pattern
> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/it/src/test/java/org/apache/sling/repoinit/it/WaitFor.java
> it should be supported by the teleporter rule directly.



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

[GitHub] sling pull request #164: SLING-6031 Teleporter.getService() should wait for ...

[stefanseifert]

GitHub user stefanseifert opened a pull request:

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

SLING-6031 Teleporter.getService() should wait for required services



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

$ git pull https://github.com/stefanseifert/sling 
feature/SLING-6031-teleporter-waitfor-service

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

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

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

This closes #164


commit 504d4d7684bc1aeb1e6c34b14e1967299d8b8af5
Author: sseifert 
Date:   2016-09-05T15:21:35Z

SLING-6031 Teleporter.getService() should wait for required services

commit 3e386a9ee26f88965514aa65bb98f5b2a1eddf1d
Author: sseifert 
Date:   2016-09-05T15:22:13Z

SLING-6031 switch to latest teleporter version not requiring a WaitFor class

commit 6f8d3451568b8eea8c8bb8f2bc236aa194680c2f
Author: sseifert 
Date:   2016-09-05T15:43:18Z

SLING-6031 switch to latest teleporter version not requiring a WaitFor class

commit a9bf7309da1edd3b63ce0c040fd755c48c2b3e77
Author: sseifert 
Date:   2016-09-05T15:47:11Z

SLING-6031 Teleporter.getService() should wait for required services




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

[jira] [Updated] (SLING-6031) Teleporter.getService() should wait for required services

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6031:
--
 Assignee: Stefan Seifert  (was: Bertrand Delacretaz)
Fix Version/s: JUnit Core 1.0.18

> Teleporter.getService() should wait for required services
> -
>
> Key: SLING-6031
> URL: https://issues.apache.org/jira/browse/SLING-6031
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: JUnit Tests Teleporter 1.0.8, JUnit Core 1.0.18
>
>
> the JUnit TeleporterRule provides a getService method to get OSGi services 
> for the test run. this may return null for services that are not yet started.
> as a workaround some integration tests implement their own "WaitFor" pattern
> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/repoinit/it/src/test/java/org/apache/sling/repoinit/it/WaitFor.java
> it should be supported by the teleporter rule directly.



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

[jira] [Commented] (SLING-6025) Context-Aware Config: Provide configuration parameter metadata

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6025:
---

i will give it a try and see if we hit some problems on the way.

> Context-Aware Config: Provide configuration parameter metadata
> --
>
> Key: SLING-6025
> URL: https://issues.apache.org/jira/browse/SLING-6025
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata 
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor 
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter 
> metadata. by default the annotation interface classes are used for this. they 
> have to be detected on the runtime in the classpath when a new bundle is 
> deployed using an osgi extender pattern (quite similar to sling models). to 
> the annotation classes further annotations can be applied an class and 
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for 
> configurations which are defined and accessed with annotation classes, not 
> when the application used direct valuemap access or the low-level 
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can 
> ship the default configuration providing metadata detected from the deployed 
> annotation classes, but leave a door open to add other sources as well.



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

[jira] [Commented] (SLING-6025) Context-Aware Config: Provide configuration parameter metadata

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6025:
-

Metatype is a generic approach to manage meta information, it is true that we 
use the same api for different purposes, but that's fine.
I see the issue with the namespace though - I'm not 100% sure but I think the 
configuration admin console of the web console will happily pick up any 
metatype info found, including these. But I think that should be solvable 
somehow.
I don't think the additional properties are a problem.
Custom properties is more a problem, this could be solved with additional 
annotations. Through the metatype we already know the class that is described 
and can then simply scan for these additional annotations on request.
If I look at the benefits and given that metatype is really a general purpose 
api, I think we should try to go this route.

> Context-Aware Config: Provide configuration parameter metadata
> --
>
> Key: SLING-6025
> URL: https://issues.apache.org/jira/browse/SLING-6025
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata 
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor 
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter 
> metadata. by default the annotation interface classes are used for this. they 
> have to be detected on the runtime in the classpath when a new bundle is 
> deployed using an osgi extender pattern (quite similar to sling models). to 
> the annotation classes further annotations can be applied an class and 
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for 
> configurations which are defined and accessed with annotation classes, not 
> when the application used direct valuemap access or the low-level 
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can 
> ship the default configuration providing metadata detected from the deployed 
> annotation classes, but leave a door open to add other sources as well.



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

September Board Report

[Carsten Ziegeler]

Hi,

I've prepared the September board report here:

https://cwiki.apache.org/confluence/display/SLING/Status+Report+September+2016

Please review, adjust, comment

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

[jira] [Commented] (SLING-6025) Context-Aware Config: Provide configuration parameter metadata

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6025:
---

your comment from SLING-6034 was: "I think we must avoid classpath scanning if 
possible. You load up resources into memory at a point when they are definitly 
not needed yet, and maybe they are never used at all."

i would be possible to switch this to a lazy initializing, not scanning the 
classpath and metadata until it is requested by another service (e.g. a 
graphical configuration editor, which will happen only in authoring 
environments and never on publishing environments).

defining each and every configuration class one by one in the bundle header is 
very cumbersome - but let's see what is the result of the metatype service 
discussion, which would be another solution for this problem.

> Context-Aware Config: Provide configuration parameter metadata
> --
>
> Key: SLING-6025
> URL: https://issues.apache.org/jira/browse/SLING-6025
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata 
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor 
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter 
> metadata. by default the annotation interface classes are used for this. they 
> have to be detected on the runtime in the classpath when a new bundle is 
> deployed using an osgi extender pattern (quite similar to sling models). to 
> the annotation classes further annotations can be applied an class and 
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for 
> configurations which are defined and accessed with annotation classes, not 
> when the application used direct valuemap access or the low-level 
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can 
> ship the default configuration providing metadata detected from the deployed 
> annotation classes, but leave a door open to add other sources as well.



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

[jira] [Updated] (SLING-6034) Context-Aware Config: Allow direct adaption of configuration annotation classes

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6034:
--
Assignee: (was: Stefan Seifert)
Priority: Minor  (was: Major)

ok, we keep the classpath scanning discussion in SLING-6025 where it is 
currently already in use in the draft implementation.

i understand your concerns about b).

i leave this ticket open if someone other has a strong opinion on this feature 
to have it. if not we can close it and do not implement it.

> Context-Aware Config: Allow direct adaption of configuration annotation 
> classes
> ---
>
> Key: SLING-6034
> URL: https://issues.apache.org/jira/browse/SLING-6034
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Priority: Minor
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently for getting a configuration mapped to a configuration annotation 
> classes you need this code line:
> {code:java}
> SimpleConfig config = 
> resourcePage1.adaptTo(ConfigurationBuilder.class).as(SimpleConfig.class);
> {code}
> with a dynamic adapter factory it should be also possible to adapt directly 
> to the configuration class:
> {code:java}
> SimpleConfig config = resourcePage1.adaptTo(SimpleConfig.class);
> {code}



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

[jira] [Commented] (SLING-6025) Context-Aware Config: Provide configuration parameter metadata

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6025:
---

i first thought about this as well, but do not wanted to mix up with the OSGi 
metatype to avoid confusion whether it's a context-aware or system-level 
configuration. but it's a good idea to discuss it here if its maybe the better 
chose nevertheless.

benefits using Metatype:
* reusing the existing osgi metatype anotations {{@ObjectClassDefinition}} and 
{{@AttributeDefinition}}
* annotation classes are parsed at compile time, metadata is available at 
runtime by metatype service
* we do not need classpath scanning mechanisms at runtime because the classes 
are detected on compile time and metadata files generated for each
* the same annotation class could be used for both context-aware configuration 
and osgi declarative services

drawbacks using Metatype:
* we mix two different configuration approaches working technically completely 
different - but sharing a common configName/metatype id namespace. this may be 
especially problematic when a custom (short) configName is used instead of the 
full class name.
* both annotations currently provide much more properties that we are currently 
plan to support - e.g. @ObjectClassDefinition, 
AttributeDefinition.type/cardinality/min/max/options etc. - we may just ignore 
them, or add a usefull implementation for them
* we have no possibility to pass in additional custom properties - this is 
needed esp. on attribute level to provide metadata for a graphical GUI editor - 
e.g. to configure a "pathbrowser" widget for a string parameter instead of a 
simple text field. we may create a custom annotation only for this usecase, but 
it will not be parsed and transported by the metatype functionality.
* people may get confused with this different configuration approaches sharing 
some functionality but not all

> Context-Aware Config: Provide configuration parameter metadata
> --
>
> Key: SLING-6025
> URL: https://issues.apache.org/jira/browse/SLING-6025
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata 
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor 
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter 
> metadata. by default the annotation interface classes are used for this. they 
> have to be detected on the runtime in the classpath when a new bundle is 
> deployed using an osgi extender pattern (quite similar to sling models). to 
> the annotation classes further annotations can be applied an class and 
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for 
> configurations which are defined and accessed with annotation classes, not 
> when the application used direct valuemap access or the low-level 
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can 
> ship the default configuration providing metadata detected from the deployed 
> annotation classes, but leave a door open to add other sources as well.



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

[jira] [Commented] (SLING-6025) Context-Aware Config: Provide configuration parameter metadata

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6025:
-

And classpath scanning should be avoid (see note in SLING-6034). If we need 
some header, it can contain the classes (in contrast to packages)

> Context-Aware Config: Provide configuration parameter metadata
> --
>
> Key: SLING-6025
> URL: https://issues.apache.org/jira/browse/SLING-6025
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata 
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor 
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter 
> metadata. by default the annotation interface classes are used for this. they 
> have to be detected on the runtime in the classpath when a new bundle is 
> deployed using an osgi extender pattern (quite similar to sling models). to 
> the annotation classes further annotations can be applied an class and 
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for 
> configurations which are defined and accessed with annotation classes, not 
> when the application used direct valuemap access or the low-level 
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can 
> ship the default configuration providing metadata detected from the deployed 
> annotation classes, but leave a door open to add other sources as well.



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

[jira] [Commented] (SLING-6034) Context-Aware Config: Allow direct adaption of configuration annotation classes

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6034:
-

[~sseif...@pro-vision.de] I think we must avoid classpath scanning if possible. 
You load up resources into memory at a point when they are definitly not needed 
yet, and maybe they are never used at all. 
But my main reason was actually b) - while the adapter pattern is nice, you're 
not really adapting the resource to something, you rather use it as a short cut 
to avoid boilerplate code; I know that we have this in various places and I 
think this is bad and we shouldn't have done it in the first place. But equally 
important this prevents adapting a context resource to such a configuration 
annotation directly. Which in turn prevents reuse of the configuration 
annotation. I think the resulting code is confusing, what does:
  resource.adaptTo(Foo.class) 
do ?
Does it adapt the resource directory to Foo because this might be a model class 
or does it first get a configuration resource and adapt it to Foo?


> Context-Aware Config: Allow direct adaption of configuration annotation 
> classes
> ---
>
> Key: SLING-6034
> URL: https://issues.apache.org/jira/browse/SLING-6034
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently for getting a configuration mapped to a configuration annotation 
> classes you need this code line:
> {code:java}
> SimpleConfig config = 
> resourcePage1.adaptTo(ConfigurationBuilder.class).as(SimpleConfig.class);
> {code}
> with a dynamic adapter factory it should be also possible to adapt directly 
> to the configuration class:
> {code:java}
> SimpleConfig config = resourcePage1.adaptTo(SimpleConfig.class);
> {code}



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

[jira] [Updated] (SLING-5874) Health Check Executor unnecessarily wastes 50ms

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-5874:
---
Affects Version/s: Health Check Core 1.2.4

> Health Check Executor unnecessarily wastes 50ms 
> 
>
> Key: SLING-5874
> URL: https://issues.apache.org/jira/browse/SLING-5874
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Affects Versions: Health Check Core 1.2.4
>Reporter: Georg Henzler
>Assignee: Bertrand Delacretaz
> Fix For: Health Check Core 1.2.6
>
>
> Currently the HC executor boldly waits for 50ms util it checks again if all 
> relevant futures have finished within the given timeout:
> https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L365
> This has the following disadvantages:
> * The HC executor never returns a request under 50ms (even if the actual 
> check only takes 1ms like a "all OSGi bundle started" check does)
> * Setting timeout values (e.g. via the HC servlet) lower than 50ms does not 
> work (effectively the timeout is increased to 50ms then)
> For most cases the current behaviour is not really a problem, but for using 
> the HC for a load balancer when response time should be optimised as much as 
> possible, the HC servlet should be able to return in only slightly more time 
> than the longest check requires (so if a request checks for started bundles 
> only it should return in ~3ms instead of the current ~53ms).
> To fix this the sleep shall be replaced with a 
> Object.wait()/Object.notifyAll() setup.



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

[jira] [Resolved] (SLING-5874) Health Check Executor unnecessarily wastes 50ms

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz resolved SLING-5874.

   Resolution: Fixed
Fix Version/s: Health Check Core 1.2.6

Thanks for your contribution! I have committed it in 
http://svn.apache.org/r1759278

And thanks for explaining the additional {{Runnable}} in a comment, that's a 
tricky one ;-)

> Health Check Executor unnecessarily wastes 50ms 
> 
>
> Key: SLING-5874
> URL: https://issues.apache.org/jira/browse/SLING-5874
> Project: Sling
>  Issue Type: Improvement
>  Components: Health Check
>Affects Versions: Health Check Core 1.2.4
>Reporter: Georg Henzler
>Assignee: Bertrand Delacretaz
> Fix For: Health Check Core 1.2.6
>
>
> Currently the HC executor boldly waits for 50ms util it checks again if all 
> relevant futures have finished within the given timeout:
> https://github.com/apache/sling/blob/eecc7e401a0894984a5eaa8992dedfcb5a18e0e5/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/core/impl/executor/HealthCheckExecutorImpl.java#L365
> This has the following disadvantages:
> * The HC executor never returns a request under 50ms (even if the actual 
> check only takes 1ms like a "all OSGi bundle started" check does)
> * Setting timeout values (e.g. via the HC servlet) lower than 50ms does not 
> work (effectively the timeout is increased to 50ms then)
> For most cases the current behaviour is not really a problem, but for using 
> the HC for a load balancer when response time should be optimised as much as 
> possible, the HC servlet should be able to return in only slightly more time 
> than the longest check requires (so if a request checks for started bundles 
> only it should return in ~3ms instead of the current ~53ms).
> To fix this the sleep shall be replaced with a 
> Object.wait()/Object.notifyAll() setup.



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

[jira] [Commented] (SLING-6025) Context-Aware Config: Provide configuration parameter metadata

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6025:
-

Can't we use the Metatype service for this? There are annotations for metatype 
service defined in the OSGi R6 spec.
And this seems exactly like a use case for the metatype service

> Context-Aware Config: Provide configuration parameter metadata
> --
>
> Key: SLING-6025
> URL: https://issues.apache.org/jira/browse/SLING-6025
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata 
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor 
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter 
> metadata. by default the annotation interface classes are used for this. they 
> have to be detected on the runtime in the classpath when a new bundle is 
> deployed using an osgi extender pattern (quite similar to sling models). to 
> the annotation classes further annotations can be applied an class and 
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for 
> configurations which are defined and accessed with annotation classes, not 
> when the application used direct valuemap access or the low-level 
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can 
> ship the default configuration providing metadata detected from the deployed 
> annotation classes, but leave a door open to add other sources as well.



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

[jira] [Updated] (SLING-5135) Whitelist legit usages of loginAdministrative and administrative ResourceResolver

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated SLING-5135:
---
Attachment: SLING-5135.patch

I have attached a new SLING-5135.patch including a default configuration that 
whitelists bundles that currently require loginAdmin and are included in in the 
Sling Launchpad . As discussed on our dev list at 
https://lists.apache.org/thread.html/5e47be07292b1d2eee8625ed2d27103c588a4b2b82ce5a3031cd0723@%3Cdev.sling.apache.org%3E

Also introduced a whitelist regexp configuration parameter, that's needed when 
running tests with Pax Exam for example which generates bundles with 
semi-random bundle symbolic names using a common prefix. That parameter is 
meant for testing and logs the following warning:

{code}
*WARN* [OsgiInstallerImpl] 
org.apache.sling.jcr.base.internal.LoginAdminWhitelistImpl A whitelist.regexp 
is configured, this is NOT RECOMMENDED for production: 
{code}

All tests pass with this patch applied to the current trunk.

@asanso, could you have a look before I commit this?

> Whitelist legit usages of loginAdministrative and administrative 
> ResourceResolver
> -
>
> Key: SLING-5135
> URL: https://issues.apache.org/jira/browse/SLING-5135
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Antonio Sanso
>Assignee: Bertrand Delacretaz
> Attachments: SLING-5135.patch, SLING-5135.patch
>
>
> {{AbstractSlingRepositoryManager}} contains a method that disable 
> loginAdministrative support
> {code}
> /**
>  * Returns whether to disable the
>  * {@code SlingRepository.loginAdministrative} method or not.
>  *
>  * @return {@code true} if {@code SlingRepository.loginAdministrative} is
>  * disabled.
>  */
> public final boolean isDisableLoginAdministrative() 
> {code}
> This is a global configuration. It would be nice to have an extension of such 
> mechanism that contains a white list of (few) legit usage of 
> {{loginAdministrative}}



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

[jira] [Commented] (SLING-6025) Context-Aware Config: Provide configuration parameter metadata

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6025:
---

feature branch:
https://github.com/stefanseifert/sling/commits/feature/SLING-6025-config-metadata

on the API side the additions are:
* new "Configuration" and "Property" annotation to optionally provide more 
metadata on the configuration annotation classes
* the "Configuration" annotation (without any parameter) is mandatory to be 
able to use a configuration annotation class with context-aware configuration
* new SPI 
{{org.apache.sling.contextaware.config.spi.ConfigurationMetadataProvider}} and 
related classes in package {{org.apache.sling.contextaware.config.spi.metadata}}

still thinking if we should name the annotations "Configuration" or 
"ContextAwareConfiguration".

> Context-Aware Config: Provide configuration parameter metadata
> --
>
> Key: SLING-6025
> URL: https://issues.apache.org/jira/browse/SLING-6025
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata 
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor 
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter 
> metadata. by default the annotation interface classes are used for this. they 
> have to be detected on the runtime in the classpath when a new bundle is 
> deployed using an osgi extender pattern (quite similar to sling models). to 
> the annotation classes further annotations can be applied an class and 
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for 
> configurations which are defined and accessed with annotation classes, not 
> when the application used direct valuemap access or the low-level 
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can 
> ship the default configuration providing metadata detected from the deployed 
> annotation classes, but leave a door open to add other sources as well.



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

[jira] [Commented] (SLING-6034) Context-Aware Config: Allow direct adaption of configuration annotation classes

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6034:
---

[~cziegeler] a draft implementation if this features was included in my 
prototype:
https://github.com/stefanseifert/sling-config/blob/develop/impl/src/main/java/org/apache/sling/config/impl/ConfigAdapterFactory.java

you did not take it over when contributing most parts of this prototype in this 
sling svn, beause you feared it may create problems. which problems did you 
mean?
a) the part parsing the bundle classpaths for configuration classes (but we 
need it anyway for SLING-6025)
b) or the part with the dynamic adapter factories for each configuration 
annotation class found (this is a similar mechanism used by sling models)

> Context-Aware Config: Allow direct adaption of configuration annotation 
> classes
> ---
>
> Key: SLING-6034
> URL: https://issues.apache.org/jira/browse/SLING-6034
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently for getting a configuration mapped to a configuration annotation 
> classes you need this code line:
> {code:java}
> SimpleConfig config = 
> resourcePage1.adaptTo(ConfigurationBuilder.class).as(SimpleConfig.class);
> {code}
> with a dynamic adapter factory it should be also possible to adapt directly 
> to the configuration class:
> {code:java}
> SimpleConfig config = resourcePage1.adaptTo(SimpleConfig.class);
> {code}



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

[jira] [Commented] (SLING-6034) Context-Aware Config: Allow direct adaption of configuration annotation classes

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6034:
---

the feature to detect all configuration classes of a deployed bundle via 
scanning its class path in all packages defined as a bundle header named 
{{Sling-ContextAware-Config-Packages}} we already have in place for SLING-6025.

so the only addition in this ticket would be the dynamic adapter factory.

> Context-Aware Config: Allow direct adaption of configuration annotation 
> classes
> ---
>
> Key: SLING-6034
> URL: https://issues.apache.org/jira/browse/SLING-6034
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently for getting a configuration mapped to a configuration annotation 
> classes you need this code line:
> {code:java}
> SimpleConfig config = 
> resourcePage1.adaptTo(ConfigurationBuilder.class).as(SimpleConfig.class);
> {code}
> with a dynamic adapter factory it should be also possible to adapt directly 
> to the configuration class:
> {code:java}
> SimpleConfig config = resourcePage1.adaptTo(SimpleConfig.class);
> {code}



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

[jira] [Created] (SLING-6034) Context-Aware Config: Allow direct adaption of configuration annotation classes

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6034:
-

 Summary: Context-Aware Config: Allow direct adaption of 
configuration annotation classes
 Key: SLING-6034
 URL: https://issues.apache.org/jira/browse/SLING-6034
 Project: Sling
  Issue Type: New Feature
  Components: Extensions
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: Context-Aware Configuration 1.0.0


currently for getting a configuration mapped to a configuration annotation 
classes you need this code line:
{code:java}
SimpleConfig config = 
resourcePage1.adaptTo(ConfigurationBuilder.class).as(SimpleConfig.class);
{code}

with a dynamic adapter factory it should be also possible to adapt directly to 
the configuration class:
{code:java}
SimpleConfig config = resourcePage1.adaptTo(SimpleConfig.class);
{code}




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

o.a.s.testing.paxeam, how to handle temporary SNAPSHOT requirements?

[Bertrand Delacretaz]

Hi,

Working on SLING-5135 requires upgrading the jcr.base and
jcr.oak-server bundles simultaneously.

For the oak-server integration tests to pass I had to add this to
OakServerTestSupport in that module:

  protected Option launchpad() {
+// TODO can we get this version number from our pom??
+SlingOptions.versionResolver.setVersion("org.apache.sling",
"org.apache.sling.jcr.base", "2.4.1-SNAPSHOT");

Is there a better way?

Like maybe "for this list of bundles, take the versions from the pom" ?

(that's not committed yet, I'll attach a patch to that ticket soon)

-Bertrand

[jira] [Comment Edited] (SLING-6028) Replace Sightly references with HTL in both code and documentation

[Radu Cotescu (JIRA)]

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

Radu Cotescu edited comment on SLING-6028 at 9/5/16 9:38 AM:
-

Code updated in https://svn.apache.org/r1758968, documentation updated in 
https://svn.apache.org/r1758970.

Renamed Sightly Maven Plugin to HTL Maven Plugin in 
https://svn.apache.org/r1759219.


was (Author: radu.cotescu):
Code updated in https://svn.apache.org/r1758968, documentation updated in 
https://svn.apache.org/r1758970.



> Replace Sightly references with HTL in both code and documentation
> --
>
> Key: SLING-6028
> URL: https://issues.apache.org/jira/browse/SLING-6028
> Project: Sling
>  Issue Type: Task
>  Components: Documentation, Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>
> Sightly references should be replaced with HTL in both code and documentation 
> in order to follow the renaming of the language. API and bundle names 
> providing it should not be changed.
> 1. https://docs.adobe.com/content/docs/en/htl/update.html
> 2. https://github.com/Adobe-Marketing-Cloud/htl-spec



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

[RESULT][VOTE] Release Apache Sling Discovery Oak 1.2.10

[Stefan Egli]

Hi,

The vote passed with 5 binding votes.

Thanks for voting, I'll finish up the release.

Cheers,
Stefan

On 31/08/16 18:16, "Stefan Egli"  wrote:

>Hi,
>
>We solved 1 issue in this release:
>
>https://issues.apache.org/jira/browse/SLING/fixforversion/12337849
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1516
>
>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 1516 /tmp/sling-staging
>
>Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
>This majority vote is open for at least 72 hours.
>
>Cheers,
>Stefan
>
>

[jira] [Commented] (SLING-5356) New ResourceBuilder module - fluent API to create content structures

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5356:


I agree that supporting absolute paths makes sense.

Wouldn't that cover your B) case then, using absolute paths?

{code}
resourceBuilder = 
getService(ResourceBuilder.class).forResolver(resourceResolver);
resourceBuilder.resource("/content/page1");
resourceBuilder.resource("/content/page2");
{code}

If you need changes to support that B) case I'm open to that, but if they break 
any existing tests please rediscuss.

I don't have much time to work on this at the moment but if you're willing to 
improve this module that's great!

> New ResourceBuilder module - fluent API to create content structures
> 
>
> Key: SLING-5356
> URL: https://issues.apache.org/jira/browse/SLING-5356
> Project: Sling
>  Issue Type: New Feature
>  Components: General
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> As discussed recently on our dev list the {{ContentBuilder}} currently 
> provided by the Sling Mocks library [1] can be very useful in testing.  
> _(edit: while implementing I have diverged from that idea and created a new, 
> more powerful {{ResourceBuilder}} API, for now that {{ContentBuilder}} stays 
> unchanged)_.
> In order to make it usable for both client-side and server-side testing (as 
> well as in server-side code) I'm planning to
> * Extract it into its own module
> * Define an API that allows for creating nodes and properties, importing JSON 
> and other files via the Sling ContentLoader and providing a simple a way to 
> cleanup the test content
> * Implement (first) a server-side version of that API
> * Implement (as a second priority) a client-side version that can be used in 
> test run via HTTP
> This shouldn't affect the existing Sling Mocks library users, except maybe 
> forcing them to rebuild their tests to use the new API.
> [1] 
> https://sling.apache.org/documentation/development/sling-mock.html#building-content



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