[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=15469114#comment-15469114
 ] 

Carsten Ziegeler commented on SLING-6025:
-

Ok, so the resource/performance problems could be solved, but what I don't like 
is that once you configure the package in the header, everything in the package 
is scanned. You have no way of filtering out classes. This might sound like a 
wired use case, but imagine you have three classes with annotations in that 
package but you want only metadata for two of them - and of course you want all 
three classes in that bundle. Then there is no way.
The tooling approach with explicit descriptors give you full power about what 
is used at runtime, there is no magic. Sure, it puts the burden on the build 
environment. The contrast is doing a full scan at runtime, which clearly puts 
the burden at runtime, with no way to opt out. The header with package names is 
in the middle of these two extremes, but as imho the disadvantage that you 
still need tooling at build time (to generate the header), but you don't have 
that fine control.

For the tooling, I guess if we do a bnd plugin that shouldn't too complicated. 

I really like the build time approach, but if I'm the only one arguing for it, 
well, then I can live with the compromise of bundle headers.

> 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

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6025:
---

bq.  However I think we should move the heavy work to the build time and 
process the annotations at build time and generate descriptor files (being it 
XML or something else)
this would be easy to implement - but it would require all developers using 
sling config to integrate a new maven plugin in their POMs only to generate 
this metadata.
do we really want this? this is no longer lightweight to integrate. it could 
also become complicated when version of annotations, config impl, maven plugin 
are released and wrong versions are mixed together. we get the same complex 
maintaining scenario as for scr plugin, scr annotations, scr generator etc.

wouldn't it be enough to do the classpath scanning lazily not before the 
information it is really requested by any client, see also [this 
comment|https://issues.apache.org/jira/browse/SLING-6025?focusedCommentId=15465187#comment-15465187].
 this would mitigate concerns to slow down bundle deployments with unnecessary 
classpath scanning.
btw. the classpath scanning would only take place A) when the specific bundle 
header is present for the bundle and B) only for the packages this bundle 
header defines.

> 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-5768) Introduce sling:resourceTypes as extension to Oak permission system

[ASF GitHub Bot (JIRA)]

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

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

Github user ghenzler closed the pull request at:

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


> Introduce sling:resourceTypes as extension to Oak permission system
> ---
>
> Key: SLING-5768
> URL: https://issues.apache.org/jira/browse/SLING-5768
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Fix For: Oak Restrictions 1.0.0
>
>
> Oak allows to extend its permissions management by using custom restrictions 
> \[1], also the standard oak restrictions are based on this and are 
> implemented in a fairly straight-forward way \[2] (example is for 
> rep:ntNames). 
> It would be nice to have sling level restrictions using sling properties in 
> general. This issue is about introducing a restriction on resource types - 
> the following should be possible:
> {code}
> - /content/mynode 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   sling:resourceTypes (String[]) = 
> [myproj/resourcetype1,myproj/resourcetype2]
> {code}
> The example would only grant "rep:write" for the resource types 
> myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
> resources under path /content/mynode would not have "rep:write" permissions. 
> Additionally to strict resource type matching it shall be possible to 
> automatically match a resource with a given resource type including all 
> children. Also, not all content nodes have a resource type, therefore it 
> should be possible to match against a child node by appending \@path to the 
> resource type: 
> {code}
> - /content/myprj 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   sling:resourceTypesWithChildren (String[]) = 
> [myproj/resourcetype1@jcr:content]
> {code}
> To achieve this any path match attempt traverses the parents and checks for a 
> match (but only up to the base path, /content/myprj in this example). For AEM 
> use cases, this can match a whole page structure (e.g. something like 
> /content/myprj/path/to/newsoverview, the whole news section can be easily 
> matched by having a distinct news overview template). 
> \[1]
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability
> \[2]
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java



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

[jira] [Commented] (SLING-6042) Use sling:resourceTypesWithDescendants instead of sling:resourceTypesWithChildren

[ASF GitHub Bot (JIRA)]

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

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

GitHub user ghenzler opened a pull request:

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

SLING-6042 using sling:resourceTypesWithDescendants instead of 
sling:resourceTypesWithChildren now



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

$ git pull https://github.com/ghenzler/sling 
feature/SLING-6042-using-resourceTypesWithDescendants-as-name

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

https://github.com/apache/sling/pull/168.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 #168


commit a4690ba5e2eda941a88357ac813a4cf92bfba140
Author: georg.henzler 
Date:   2016-09-01T18:13:36Z

SLING-6042 using sling:resourceTypesWithDescendants instead of
sling:resourceTypesWithChildren now




> Use sling:resourceTypesWithDescendants instead of 
> sling:resourceTypesWithChildren
> -
>
> Key: SLING-6042
> URL: https://issues.apache.org/jira/browse/SLING-6042
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Fix For: Oak Restrictions 1.0.0
>
>
> After some discussion at [1], the current version of the oak restrictions 
> initially committed with SLING-5768 should be updated to use 
> sling:resourceTypesWithDescendants instead of sling:resourceTypesWithChildren 
> (the latter is semantically not correct as not only the children are matched 
> but all descendants, thanks [~jsedding] for pointing this out). 
> The documentation has already been updated via SLING-5890 and is available at 
> [2]
> [1] https://www.mail-archive.com/dev@sling.apache.org/msg58935.html
> [2] https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html



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

[GitHub] sling pull request #168: SLING-6042 using sling:resourceTypesWithDescendants...

[ghenzler]

GitHub user ghenzler opened a pull request:

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

SLING-6042 using sling:resourceTypesWithDescendants instead of 
sling:resourceTypesWithChildren now



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

$ git pull https://github.com/ghenzler/sling 
feature/SLING-6042-using-resourceTypesWithDescendants-as-name

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

https://github.com/apache/sling/pull/168.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 #168


commit a4690ba5e2eda941a88357ac813a4cf92bfba140
Author: georg.henzler 
Date:   2016-09-01T18:13:36Z

SLING-6042 using sling:resourceTypesWithDescendants instead of
sling:resourceTypesWithChildren now




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

[GitHub] sling pull request #163: SLING-5768 using sling:resourceTypesWithDescendants...

[ghenzler]

Github user ghenzler closed the pull request at:

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


---
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-5768) Introduce sling:resourceTypes as extension to Oak permission system

[Georg Henzler (JIRA)]

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

Georg Henzler commented on SLING-5768:
--

Created follow up ticket for PR: SLING-6042

> Introduce sling:resourceTypes as extension to Oak permission system
> ---
>
> Key: SLING-5768
> URL: https://issues.apache.org/jira/browse/SLING-5768
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Georg Henzler
>Assignee: Robert Munteanu
> Fix For: Oak Restrictions 1.0.0
>
>
> Oak allows to extend its permissions management by using custom restrictions 
> \[1], also the standard oak restrictions are based on this and are 
> implemented in a fairly straight-forward way \[2] (example is for 
> rep:ntNames). 
> It would be nice to have sling level restrictions using sling properties in 
> general. This issue is about introducing a restriction on resource types - 
> the following should be possible:
> {code}
> - /content/mynode 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   sling:resourceTypes (String[]) = 
> [myproj/resourcetype1,myproj/resourcetype2]
> {code}
> The example would only grant "rep:write" for the resource types 
> myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other 
> resources under path /content/mynode would not have "rep:write" permissions. 
> Additionally to strict resource type matching it shall be possible to 
> automatically match a resource with a given resource type including all 
> children. Also, not all content nodes have a resource type, therefore it 
> should be possible to match against a child node by appending \@path to the 
> resource type: 
> {code}
> - /content/myprj 
>- rep:policy (rep:ACL)
>  - allow (rep:GrantACE)
>+ principalName (String) = "myAuthorizable"
>+ rep:privileges (Name[]) = "rep:write"
>- rep:restrictions (rep:Restrictions)
>   +   sling:resourceTypesWithChildren (String[]) = 
> [myproj/resourcetype1@jcr:content]
> {code}
> To achieve this any path match attempt traverses the parents and checks for a 
> match (but only up to the base path, /content/myprj in this example). For AEM 
> use cases, this can match a whole page structure (e.g. something like 
> /content/myprj/path/to/newsoverview, the whole news section can be easily 
> matched by having a distinct news overview template). 
> \[1]
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability
> \[2]
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java



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

[jira] [Created] (SLING-6042) Use sling:resourceTypesWithDescendants instead of sling:resourceTypesWithChildren

[Georg Henzler (JIRA)]

Georg Henzler created SLING-6042:


 Summary: Use sling:resourceTypesWithDescendants instead of 
sling:resourceTypesWithChildren
 Key: SLING-6042
 URL: https://issues.apache.org/jira/browse/SLING-6042
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Georg Henzler
Assignee: Robert Munteanu
 Fix For: Oak Restrictions 1.0.0


After some discussion at [1], the current version of the oak restrictions 
initially committed with SLING-5768 should be updated to use 
sling:resourceTypesWithDescendants instead of sling:resourceTypesWithChildren 
(the latter is semantically not correct as not only the children are matched 
but all descendants, thanks [~jsedding] for pointing this out). 

The documentation has already been updated via SLING-5890 and is available at 
[2]

[1] https://www.mail-archive.com/dev@sling.apache.org/msg58935.html
[2] https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html




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

http-based/teleporter unit tests vs. paxexam integraiton tests (was: RE: flaky integration tests with teleporte rule)

[Stefan Seifert]

>To be honest, I see only 2, maybe 3 cases where managing tests over HTTP
>makes
>sense:
>
>1. you do not want to start your (fat and slow) application under test from
>the tests itself
>2. you need a different runner than PaxExam (runners and rules are gone in
>JUnit 5)
>3. reuse of tests like done in o.a.s.karaf-launchpad-oak-tar-integration-
>tests
>
>In any other case I would use Pax Exam and @Inject to ensure required
>services
>are available before tests are executed.


this may be true.

before again using a http-based test (also with latest slingstart/provisoining 
features and teleporter rule they are much nicer than before) i played some 
minutes with paxexam and was drawn back by two isses (without further thinking 
or researching on them):

1. within the codebase of org.apache.sling.testing.paxexam a long list of 
dependencies was hard-coded. this is usually not what i want. using slingstart 
i reference one sling launchpad version i want to target (e.g. 8) and deploy 
only few additional bundles. then i can be sure that my application works 
exactly with this versions of dependencies and felix framework, not only with 
the latest and greatest versions. if paxexam could be equipped with an 
"externalized" dependency management based on sling provisioning files and 
their modularization/overlay/inheritance features this would be great.

2. paxexam integration tests do not run in the IDE (at least not in 
eclipse/junit runner - the problem seems to be that the pom information is not 
available for version lookup). this is only nice-to-have.

stefan

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

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-5356:
---

[~bdelacretaz] is there any important open on this ticket - or can we close it?

there were some proposal for extenions 
[here|https://issues.apache.org/jira/browse/SLING-5356?focusedCommentId=15067793#comment-15067793]
 - but i think we can add them later on in separate tickets if required.

otherwise we can set this to resolved, and aim for a first 1.0 release in the 
next few weeks.

> 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: Extensions
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Resource Builder 1.0.0
>
>
> 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)

[GitHub] sling pull request #167: SLING-6040 Add ResourceBuilder Support to sling-moc...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-6040) Add ResourceBuilder Support to sling-mock

[Stefan Seifert (JIRA)]

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

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

Completed: At revision: 1759511  

sling-mock 1.x und sling-mock 2.x um ResourceBuilder support erweitert

> Add ResourceBuilder Support to sling-mock
> -
>
> Key: SLING-6040
> URL: https://issues.apache.org/jira/browse/SLING-6040
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions, Testing
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing Sling Mock 1.7.2, Testing Sling Mock 2.0.2, 
> Resource Builder 1.0.0
>
>
> we want to provide the Sling ResourceBuilder as alternative way in sling mock 
> to simply create test resources.
> currently sling mocks supports it's own "ContentBuilder" via the {{create()}} 
> method on the context.
> a new method {{build()}} should be added which provides a preconfigred 
> ResourceBuilder instance for the current resource resolver.
> alternatively the ResourceResolverFactory service can be accessed directly 
> form the test code.



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

[jira] [Commented] (SLING-6040) Add ResourceBuilder Support to sling-mock

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Add ResourceBuilder Support to sling-mock
> -
>
> Key: SLING-6040
> URL: https://issues.apache.org/jira/browse/SLING-6040
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions, Testing
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing Sling Mock 1.7.2, Testing Sling Mock 2.0.2, 
> Resource Builder 1.0.0
>
>
> we want to provide the Sling ResourceBuilder as alternative way in sling mock 
> to simply create test resources.
> currently sling mocks supports it's own "ContentBuilder" via the {{create()}} 
> method on the context.
> a new method {{build()}} should be added which provides a preconfigred 
> ResourceBuilder instance for the current resource resolver.
> alternatively the ResourceResolverFactory service can be accessed directly 
> form the test code.



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

[jira] [Updated] (SLING-6040) Add ResourceBuilder Support to sling-mock

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6040:
--
Fix Version/s: Testing Sling Mock 1.7.2

> Add ResourceBuilder Support to sling-mock
> -
>
> Key: SLING-6040
> URL: https://issues.apache.org/jira/browse/SLING-6040
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions, Testing
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing Sling Mock 1.7.2, Testing Sling Mock 2.0.2, 
> Resource Builder 1.0.0
>
>
> we want to provide the Sling ResourceBuilder as alternative way in sling mock 
> to simply create test resources.
> currently sling mocks supports it's own "ContentBuilder" via the {{create()}} 
> method on the context.
> a new method {{build()}} should be added which provides a preconfigred 
> ResourceBuilder instance for the current resource resolver.
> alternatively the ResourceResolverFactory service can be accessed directly 
> form the test code.



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

[jira] [Commented] (SLING-6040) Add ResourceBuilder Support to sling-mock

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6040:
---

Completed: At revision: 1759507  

split up resourcebuilder into impl and integration-test project

> Add ResourceBuilder Support to sling-mock
> -
>
> Key: SLING-6040
> URL: https://issues.apache.org/jira/browse/SLING-6040
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions, Testing
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing Sling Mock 2.0.2, Resource Builder 1.0.0
>
>
> we want to provide the Sling ResourceBuilder as alternative way in sling mock 
> to simply create test resources.
> currently sling mocks supports it's own "ContentBuilder" via the {{create()}} 
> method on the context.
> a new method {{build()}} should be added which provides a preconfigred 
> ResourceBuilder instance for the current resource resolver.
> alternatively the ResourceResolverFactory service can be accessed directly 
> form the test code.



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

[jira] [Commented] (SLING-6039) ResourceBuilder: Split up ResourceBuilder and ResourceBuilderFactory

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> ResourceBuilder: Split up ResourceBuilder and ResourceBuilderFactory
> 
>
> Key: SLING-6039
> URL: https://issues.apache.org/jira/browse/SLING-6039
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Resource Builder 1.0.0
>
>
> i do not understand why we combine the use cases
> * resource builder creation
> * resource builder usage
> in one single ResourceBuilder interface, with two implementations each only 
> supporting the one part or another, throwing exception when the other methods 
> are used.
> it think it would be quite cleaner and easier to understand to create a 
> separate ResourceBuilderFactory interface.



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

[GitHub] sling pull request #166: SLING-6039 ResourceBuilder: Split up ResourceBuilde...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-6039) ResourceBuilder: Split up ResourceBuilder and ResourceBuilderFactory

[Stefan Seifert (JIRA)]

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

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

Completed: At revision: 1759501  
applied patch

Completed: At revision: 1759502  
integration tests adapted

> ResourceBuilder: Split up ResourceBuilder and ResourceBuilderFactory
> 
>
> Key: SLING-6039
> URL: https://issues.apache.org/jira/browse/SLING-6039
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Resource Builder 1.0.0
>
>
> i do not understand why we combine the use cases
> * resource builder creation
> * resource builder usage
> in one single ResourceBuilder interface, with two implementations each only 
> supporting the one part or another, throwing exception when the other methods 
> are used.
> it think it would be quite cleaner and easier to understand to create a 
> separate ResourceBuilderFactory interface.



--
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=15468404#comment-15468404
 ] 

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

Github user asfgit closed the pull request at:

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


> 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] [Resolved] (SLING-6036) ResourceBuilder: Reusing ResourceBuilder instances

[Stefan Seifert (JIRA)]

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

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

> 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] [Resolved] (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 resolved SLING-6031.
---
Resolution: Fixed

Completed: At revision: 1759492  
update junit.core/junit.teleporter (with added constant)

Completed: At revision: 1759500  
updated repoinit and contextaware-config integration tests to remove WaitFor 
class

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

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-6037) sling pipes additionnal bindings should be configurable as resources

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier resolved SLING-6037.

Resolution: Not A Problem

basically this feature already exists with additionalBindings node

> 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)

Re: What's wrong with Sightly?

[Roy T. Fielding]

It was a response to a third party's legal demand, not a marketing fail. A 
change to the name used by the software is suggested, not just a change of the 
language name. In fact, the language name would not normally be an issue.

Roy


> On Sep 6, 2016, at 6:39 AM, Oliver Lietz  wrote:
> 
>> On Tuesday 06 September 2016 00:03:22 Justin Edelson wrote:
>> 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.
> 
> Sorry, I have to disagree. The language or spec is one thing, the 
> implementation(s) a different. Most prominent example is HTML itself and the 
> various rendering engines, e.g. Gecko, KHTML, WebKit, Presto, Tasman...
> 
> We now have a break between names and modules/packages and a bunch of dead 
> links. That mess is totally unnecessary. Marketing fail.
> 
> Adjusting the language name in Sling from Sighlty back to HTL (*sigh*) would 
> have been sufficient: Sling Sightly implementing (Adobe's) HTL.
> 
> @Radu, can you please revert the changes in Sling Launchpad 8 and Sling IDE 
> Tooling 1.1 release news? The name of the language was Sightly at that time.
> 
> Regards,
> O.
> 
>>> 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-6036) ResourceBuilder: Reusing ResourceBuilder instances

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6036:


Looks great, thanks!

> 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] [Commented] (SLING-6031) Teleporter.getService() should wait for required services

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6031:


Looks great, thanks! I would just add a constant for the default timeout in 
{{ServerSideTeleporter}}.

> 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] [Resolved] (SLING-6041) Avoid embedding httpasyncclient dependency in SCD core

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili resolved SLING-6041.

Resolution: Fixed

fixed in r1759441.

> Avoid embedding httpasyncclient dependency in SCD core
> --
>
> Key: SLING-6041
> URL: https://issues.apache.org/jira/browse/SLING-6041
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> Currently we embed _httpasyncclient_ in _org.apache.sling.distribution.core_, 
> that doesn't make much sense as it's possible to get it from OSGi bundles 
> from httpcomponents.
> The code is used only by {{RemoteEventDistributionTrigger}} which is 
> currently not used anywhere therefore it also makes sense to put the related 
> dependency as optional in Import-Package.



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

[jira] [Created] (SLING-6041) Avoid embedding httpasyncclient dependency in SCD core

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-6041:
--

 Summary: Avoid embedding httpasyncclient dependency in SCD core
 Key: SLING-6041
 URL: https://issues.apache.org/jira/browse/SLING-6041
 Project: Sling
  Issue Type: Improvement
  Components: Distribution
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: Content Distribution 0.2.0


Currently we embed _httpasyncclient_ in _org.apache.sling.distribution.core_, 
that doesn't make much sense as it's possible to get it from OSGi bundles from 
httpcomponents.
The code is used only by {{RemoteEventDistributionTrigger}} which is currently 
not used anywhere therefore it also makes sense to put the related dependency 
as optional in Import-Package.



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

[jira] [Commented] (SLING-6039) ResourceBuilder: Split up ResourceBuilder and ResourceBuilderFactory

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6039:


+1, obviously, thanks!

> ResourceBuilder: Split up ResourceBuilder and ResourceBuilderFactory
> 
>
> Key: SLING-6039
> URL: https://issues.apache.org/jira/browse/SLING-6039
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Resource Builder 1.0.0
>
>
> i do not understand why we combine the use cases
> * resource builder creation
> * resource builder usage
> in one single ResourceBuilder interface, with two implementations each only 
> supporting the one part or another, throwing exception when the other methods 
> are used.
> it think it would be quite cleaner and easier to understand to create a 
> separate ResourceBuilderFactory interface.



--
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=15467600#comment-15467600
 ] 

Carsten Ziegeler commented on SLING-6025:
-

Thanks for testing this [~sseif...@pro-vision.de]

Given the problems, it might be better to not use metatype. However I think we 
should move the heavy work to the build time and process the annotations at 
build time and generate descriptor files (being it XML or something else)

> 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)

Re: What's wrong with Sightly?

[Radu Cotescu]

Done in https://svn.apache.org/r1759438

On Tue, 6 Sep 2016 at 16:22 Radu Cotescu  wrote:

> There's one redirect that we need to put in place:
>
>
> https://sling.apache.org/documentation/bundles/scripting/scripting-sightly.html
>  -->
> https://sling.apache.org/documentation/bundles/scripting/scripting-htl.html
>
> I'll also revert the changes to the Sling Launchpad 8 and Sling IDE Tooling
> 1.1 release news pages.
>
> Thanks,
> Radu
>

Re: What's wrong with Sightly?

[Radu Cotescu]

There's one redirect that we need to put in place:

https://sling.apache.org/documentation/bundles/scripting/scripting-sightly.html
-->
https://sling.apache.org/documentation/bundles/scripting/scripting-htl.html

I'll also revert the changes to the Sling Launchpad 8 and Sling IDE Tooling
1.1 release news pages.

Thanks,
Radu

On Tue, 6 Sep 2016 at 16:14 Bertrand Delacretaz 
wrote:

> On Tue, Sep 6, 2016 at 3:53 PM, Oliver Lietz 
> wrote:
> > On Tuesday 06 September 2016 13:50:21 Radu Cotescu wrote:
> >> On Tue, 6 Sep 2016 at 15:40 Oliver Lietz  wrote:
> >> > We now have a break between names and modules/packages and a bunch of
> dead
> >> > links.
> >> Which dead links are you referring to?
> > The ones we don't control: search engine results, blog posts, slides, ...
>
> Good point - did any of our URLs change in this rename?
>
> If yes I think we should at least have proper redirects for them - if
> that's in our docs an entry in
> https://svn.apache.org/repos/asf/sling/site/trunk/content/.htaccess
> should do.
>
> I agree with Oliver that this rename is not strictly needed and should
> have been discussed on our dev list before implementing it, which I
> don't think happened.
>
> So let's try at least to make it as painless as possible for our users.
>
> -Bertrand
>

Re: What's wrong with Sightly?

[Bertrand Delacretaz]

On Tue, Sep 6, 2016 at 3:53 PM, Oliver Lietz  wrote:
> On Tuesday 06 September 2016 13:50:21 Radu Cotescu wrote:
>> On Tue, 6 Sep 2016 at 15:40 Oliver Lietz  wrote:
>> > We now have a break between names and modules/packages and a bunch of dead
>> > links.
>> Which dead links are you referring to?
> The ones we don't control: search engine results, blog posts, slides, ...

Good point - did any of our URLs change in this rename?

If yes I think we should at least have proper redirects for them - if
that's in our docs an entry in
https://svn.apache.org/repos/asf/sling/site/trunk/content/.htaccess
should do.

I agree with Oliver that this rename is not strictly needed and should
have been discussed on our dev list before implementing it, which I
don't think happened.

So let's try at least to make it as painless as possible for our users.

-Bertrand

Re: September Board Report

[Carsten Ziegeler]

Thanks, I submitted it.

Carsten
> On Mon, 2016-09-05 at 07:55 -0700, Carsten Ziegeler wrote:
>> Hi,
>>
>> I've prepared the September board report here:
>>
>> https://cwiki.apache.org/confluence/display/SLING/Status+Report+Septe
>> mber+2016
>>
>> Please review, adjust, comment
>>  
> 
> Looks good to me, thanks.
> 
> Robert
> 


 

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

Re: flaky integration tests with teleporte rule

[Oliver Lietz]

On Friday 02 September 2016 10:32:38 Stefan Seifert wrote:
> i've used the teleporter rules in the integration tests for the
> context-aware configs:
> https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/contextawar
> e-config/integration-tests
> 
> on my machines they run smooth on a fast machine, but flaky on a not-so-fast
> machine.
> 
> source of the problem is that the integration tests sometimes start before
> the ResourceResolverFactory service becomes available, it's a racing
> condition.
> 
> in the old HttpTestBase there was a concept with launchpad.ready.1 URLs
> defined which were checked to see if the instances was really ready - is
> there an equivalent concept in the teleporter rule, how to configure it?

To be honest, I see only 2, maybe 3 cases where managing tests over HTTP makes 
sense:

1. you do not want to start your (fat and slow) application under test from 
the tests itself
2. you need a different runner than PaxExam (runners and rules are gone in 
JUnit 5)
3. reuse of tests like done in o.a.s.karaf-launchpad-oak-tar-integration-tests

In any other case I would use Pax Exam and @Inject to ensure required services 
are available before tests are executed.

Regards,
O.

> stefan

Re: What's wrong with Sightly?

[Oliver Lietz]

On Tuesday 06 September 2016 13:50:21 Radu Cotescu wrote:
> On Tue, 6 Sep 2016 at 15:40 Oliver Lietz  wrote:
> > We now have a break between names and modules/packages and a bunch of dead
> > links.
> 
> Which dead links are you referring to?

The ones we don't control: search engine results, blog posts, slides, ...

> > @Radu, can you please revert the changes in Sling Launchpad 8 and Sling
> > IDE
> > Tooling 1.1 release news? The name of the language was Sightly at that
> > time.
> 
> Yes, I could.

Thanks,
O.

Re: What's wrong with Sightly?

[Radu Cotescu]

On Tue, 6 Sep 2016 at 15:40 Oliver Lietz  wrote:

>
> We now have a break between names and modules/packages and a bunch of dead
> links.
>
>
Which dead links are you referring to?


> @Radu, can you please revert the changes in Sling Launchpad 8 and Sling IDE
> Tooling 1.1 release news? The name of the language was Sightly at that
> time.
>
>
Yes, I could.

Re: What's wrong with Sightly?

[Oliver Lietz]

On Tuesday 06 September 2016 00:03:22 Justin Edelson wrote:
> 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.

Sorry, I have to disagree. The language or spec is one thing, the 
implementation(s) a different. Most prominent example is HTML itself and the 
various rendering engines, e.g. Gecko, KHTML, WebKit, Presto, Tasman...

We now have a break between names and modules/packages and a bunch of dead 
links. That mess is totally unnecessary. Marketing fail.

Adjusting the language name in Sling from Sighlty back to HTL (*sigh*) would 
have been sufficient: Sling Sightly implementing (Adobe's) HTL.

@Radu, can you please revert the changes in Sling Launchpad 8 and Sling IDE 
Tooling 1.1 release news? The name of the language was Sightly at that time.

Regards,
O.

> 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] [Assigned] (SLING-5991) [SCD] Evaluate avoiding to buffer the whole packages before streaming

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili reassigned SLING-5991:
--

Assignee: Tommaso Teofili

> [SCD] Evaluate avoiding to buffer the whole packages before streaming
> -
>
> Key: SLING-5991
> URL: https://issues.apache.org/jira/browse/SLING-5991
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Affects Versions: Content Distribution 0.2.0
>Reporter: Timothee Maret
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> As described in SLING-5990, It seems streaming only starts when the whole 
> binary is completely buffered (in memory and/or file). The buffering time 
> implies a latency which which could be avoided by streaming directly.



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

[jira] [Commented] (SLING-6040) Add ResourceBuilder Support to sling-mock

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6040:
-

[~sseif...@pro-vision.de] Please ignore my comment (definitely not awake 
yet...), I thought this is about the resourceresolver mock, but yes for 
sling-mock it's fine

> Add ResourceBuilder Support to sling-mock
> -
>
> Key: SLING-6040
> URL: https://issues.apache.org/jira/browse/SLING-6040
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions, Testing
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing Sling Mock 2.0.2, Resource Builder 1.0.0
>
>
> we want to provide the Sling ResourceBuilder as alternative way in sling mock 
> to simply create test resources.
> currently sling mocks supports it's own "ContentBuilder" via the {{create()}} 
> method on the context.
> a new method {{build()}} should be added which provides a preconfigred 
> ResourceBuilder instance for the current resource resolver.
> alternatively the ResourceResolverFactory service can be accessed directly 
> form the test code.



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

[jira] [Updated] (SLING-5994) Move from EventHandler to new ResourceChangeListener API

[Hanish Bansal (JIRA)]

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

Hanish Bansal updated SLING-5994:
-
Summary: Move from EventHandler to new ResourceChangeListener API  (was: 
Move from Deprecated EventHandler to new ResourceChangeListener API)

> Move from EventHandler to new ResourceChangeListener API
> 
>
> Key: SLING-5994
> URL: https://issues.apache.org/jira/browse/SLING-5994
> Project: Sling
>  Issue Type: Task
>  Components: API
>Reporter: Hanish Bansal
>
> This issue serves as the container for the issues for migrating all 
> implementations of EventHandler to new Resource Observation API in Sling Code.
> The new API that listens to the resource events is : 
> https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/observation/ResourceChangeListener.java
> API for the Resource Change Events : 
> https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/observation/ResourceChange.java



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

Re: What's wrong with Sightly?

[Radu Cotescu]

Hi,

Everything's already there - I've just published the update. :)

Cheers,
Radu

On Tue, 6 Sep 2016 at 13:37 Bertrand Delacretaz 
wrote:

> On Tue, Sep 6, 2016 at 11:32 AM, Stefan Seifert 
> wrote:
> > ...perhaps we should also add an addition like "formerly known as
> Sightly, renamed in August 2016" etc.,
> > so people do not get confused esp. as slightly still occurs in all
> technical names on this page...
>
> +1, searching the Web for "Sightly" should find that page.
>
> And Radu I also think we need a jira ticket that briefly explains what
> was renamed, to avoid repeating what's being said in this thread - the
> scripting-htl.html page can then link to that ticket for details.
>
> -Bertrand
>

Re: What's wrong with Sightly?

[Bertrand Delacretaz]

On Tue, Sep 6, 2016 at 11:32 AM, Stefan Seifert  wrote:
> ...perhaps we should also add an addition like "formerly known as Sightly, 
> renamed in August 2016" etc.,
> so people do not get confused esp. as slightly still occurs in all technical 
> names on this page...

+1, searching the Web for "Sightly" should find that page.

And Radu I also think we need a jira ticket that briefly explains what
was renamed, to avoid repeating what's being said in this thread - the
scripting-htl.html page can then link to that ticket for details.

-Bertrand

[jira] [Resolved] (SLING-5818) make sling pipe writer a persistent configuration

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-5818.

   Resolution: Fixed
Fix Version/s: Pipes 1.0.0

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

> make sling pipe writer a persistent configuration
> -
>
> Key: SLING-5818
> URL: https://issues.apache.org/jira/browse/SLING-5818
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Nicolas Peltier
>Assignee: Robert Munteanu
> Fix For: Pipes 1.0.0
>
> Attachments: SLING-5818.patch
>
>
> right now, the only way to configure the output of a pipe is to add a json as 
> parameter of the pipe request. Sometimes the output is as important/complex 
> as the pipe itself, and should be persisted.
> This could be also the opportunity to rewrite how writer is managed in a far 
> from ideal if/else block. 
> servlet/plumber should *always* take a writer in account, and call it each 
> time,
> default being path writer, writer should still be overridable through a 
> request parameter



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

[jira] [Assigned] (SLING-5818) make sling pipe writer a persistent configuration

[Robert Munteanu (JIRA)]

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

Robert Munteanu reassigned SLING-5818:
--

Assignee: Robert Munteanu

> make sling pipe writer a persistent configuration
> -
>
> Key: SLING-5818
> URL: https://issues.apache.org/jira/browse/SLING-5818
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Nicolas Peltier
>Assignee: Robert Munteanu
> Attachments: SLING-5818.patch
>
>
> right now, the only way to configure the output of a pipe is to add a json as 
> parameter of the pipe request. Sometimes the output is as important/complex 
> as the pipe itself, and should be persisted.
> This could be also the opportunity to rewrite how writer is managed in a far 
> from ideal if/else block. 
> servlet/plumber should *always* take a writer in account, and call it each 
> time,
> default being path writer, writer should still be overridable through a 
> request parameter



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

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

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-6032.

Resolution: Fixed

Applied in https://svn.apache.org/r1759409, thanks for your contribution!

> 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
>Assignee: Robert Munteanu
> Fix For: Pipes 1.0.0
>
> 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] [Assigned] (SLING-6032) Not sling pipe

[Robert Munteanu (JIRA)]

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

Robert Munteanu reassigned SLING-6032:
--

Assignee: Robert Munteanu

> 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
>Assignee: Robert Munteanu
> Fix For: Pipes 1.0.0
>
> 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-6032) Not sling pipe

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-6032:
---
Fix Version/s: Pipes 1.0.0

> 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
> Fix For: Pipes 1.0.0
>
> 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] [Commented] (SLING-6040) Add ResourceBuilder Support to sling-mock

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6040:
---

here is a proposal: https://github.com/apache/sling/pull/167

the change on sling-mock side is small: one new method, one new dependency.

on resource builder side we need no functional change, but we need to split up 
the project into two parts (impl and integration-test including the sling-mock 
based unit test) to remove the sling-mock dependency from the resourcebuilder 
impl project to avoid cyclic dependencies.

> Add ResourceBuilder Support to sling-mock
> -
>
> Key: SLING-6040
> URL: https://issues.apache.org/jira/browse/SLING-6040
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions, Testing
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing Sling Mock 2.0.2, Resource Builder 1.0.0
>
>
> we want to provide the Sling ResourceBuilder as alternative way in sling mock 
> to simply create test resources.
> currently sling mocks supports it's own "ContentBuilder" via the {{create()}} 
> method on the context.
> a new method {{build()}} should be added which provides a preconfigred 
> ResourceBuilder instance for the current resource resolver.
> alternatively the ResourceResolverFactory service can be accessed directly 
> form the test code.



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

[jira] [Commented] (SLING-6040) Add ResourceBuilder Support to sling-mock

[ASF GitHub Bot (JIRA)]

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

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

GitHub user stefanseifert opened a pull request:

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

SLING-6040 Add ResourceBuilder Support to sling-mock

depends on PR #166

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

$ git pull https://github.com/stefanseifert/sling 
feature/SLING-6040-slingmock-resourcebuilder

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

https://github.com/apache/sling/pull/167.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 #167


commit 79cce1881d2dd14731711ad187125ca47b368878
Author: sseifert 
Date:   2016-09-06T09:56:09Z

SLING-6039 ResourceBuilder: Split up ResourceBuilder and 
ResourceBuilderFactory

commit adcfe5ddc6376d781200efd9adbc53350aa81ce5
Author: Stefan Seifert 
Date:   2016-09-06T10:07:26Z

add infinitest.filters to ignore list

git-svn-id: https://svn.apache.org/repos/asf/sling/trunk@1759403 
13f79535-47bb-0310-9956-ffa450edef68

commit b4328855d6bc39b2306251496d3eaf288da1bc25
Author: sseifert 
Date:   2016-09-06T10:36:22Z

SLING-6040 add ResourceBuilder support to SlingContext

commit 1884dfc3b9e547a20d78866365aa2a13a034
Author: sseifert 
Date:   2016-09-06T10:50:29Z

SLING-6040 split up ResourceBuilder project into impl and integration-tests 
to remove dependency to sling-mock in impl project




> Add ResourceBuilder Support to sling-mock
> -
>
> Key: SLING-6040
> URL: https://issues.apache.org/jira/browse/SLING-6040
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions, Testing
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing Sling Mock 2.0.2, Resource Builder 1.0.0
>
>
> we want to provide the Sling ResourceBuilder as alternative way in sling mock 
> to simply create test resources.
> currently sling mocks supports it's own "ContentBuilder" via the {{create()}} 
> method on the context.
> a new method {{build()}} should be added which provides a preconfigred 
> ResourceBuilder instance for the current resource resolver.
> alternatively the ResourceResolverFactory service can be accessed directly 
> form the test code.



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

[GitHub] sling pull request #167: SLING-6040 Add ResourceBuilder Support to sling-moc...

[stefanseifert]

GitHub user stefanseifert opened a pull request:

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

SLING-6040 Add ResourceBuilder Support to sling-mock

depends on PR #166

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

$ git pull https://github.com/stefanseifert/sling 
feature/SLING-6040-slingmock-resourcebuilder

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

https://github.com/apache/sling/pull/167.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 #167


commit 79cce1881d2dd14731711ad187125ca47b368878
Author: sseifert 
Date:   2016-09-06T09:56:09Z

SLING-6039 ResourceBuilder: Split up ResourceBuilder and 
ResourceBuilderFactory

commit adcfe5ddc6376d781200efd9adbc53350aa81ce5
Author: Stefan Seifert 
Date:   2016-09-06T10:07:26Z

add infinitest.filters to ignore list

git-svn-id: https://svn.apache.org/repos/asf/sling/trunk@1759403 
13f79535-47bb-0310-9956-ffa450edef68

commit b4328855d6bc39b2306251496d3eaf288da1bc25
Author: sseifert 
Date:   2016-09-06T10:36:22Z

SLING-6040 add ResourceBuilder support to SlingContext

commit 1884dfc3b9e547a20d78866365aa2a13a034
Author: sseifert 
Date:   2016-09-06T10:50:29Z

SLING-6040 split up ResourceBuilder project into impl and integration-tests 
to remove dependency to sling-mock in impl project




---
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-6040) Add ResourceBuilder Support to sling-mock

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6040:
---

it's just one more dependency (to the very long list of dependency sling-mock 
already have).
making this optional may get complicated. is it's worth making it optional? the 
dependency is coming in transient, so not manual work here.

> Add ResourceBuilder Support to sling-mock
> -
>
> Key: SLING-6040
> URL: https://issues.apache.org/jira/browse/SLING-6040
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions, Testing
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing Sling Mock 2.0.2, Resource Builder 1.0.0
>
>
> we want to provide the Sling ResourceBuilder as alternative way in sling mock 
> to simply create test resources.
> currently sling mocks supports it's own "ContentBuilder" via the {{create()}} 
> method on the context.
> a new method {{build()}} should be added which provides a preconfigred 
> ResourceBuilder instance for the current resource resolver.
> alternatively the ResourceResolverFactory service can be accessed directly 
> form the test code.



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

[jira] [Commented] (SLING-6040) Add ResourceBuilder Support to sling-mock

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6040:
-

I'm fine with this as long as I can use the current sling-mock without this 
dependency. I don't want to add a bunch of testing dependencies each time

> Add ResourceBuilder Support to sling-mock
> -
>
> Key: SLING-6040
> URL: https://issues.apache.org/jira/browse/SLING-6040
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions, Testing
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing Sling Mock 2.0.2, Resource Builder 1.0.0
>
>
> we want to provide the Sling ResourceBuilder as alternative way in sling mock 
> to simply create test resources.
> currently sling mocks supports it's own "ContentBuilder" via the {{create()}} 
> method on the context.
> a new method {{build()}} should be added which provides a preconfigred 
> ResourceBuilder instance for the current resource resolver.
> alternatively the ResourceResolverFactory service can be accessed directly 
> form the test code.



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

[jira] [Created] (SLING-6040) Add ResourceBuilder Support to sling-mock

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6040:
-

 Summary: Add ResourceBuilder Support to sling-mock
 Key: SLING-6040
 URL: https://issues.apache.org/jira/browse/SLING-6040
 Project: Sling
  Issue Type: New Feature
  Components: Extensions, Testing
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: Testing Sling Mock 2.0.2, Resource Builder 1.0.0


we want to provide the Sling ResourceBuilder as alternative way in sling mock 
to simply create test resources.

currently sling mocks supports it's own "ContentBuilder" via the {{create()}} 
method on the context.
a new method {{build()}} should be added which provides a preconfigred 
ResourceBuilder instance for the current resource resolver.

alternatively the ResourceResolverFactory service can be accessed directly form 
the test code.



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

[jira] [Commented] (SLING-6039) ResourceBuilder: Split up ResourceBuilder and ResourceBuilderFactory

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6039:
---

the change would be quite simple, here is a proposal: 
https://github.com/apache/sling/pull/166

[~bdelacretaz] what do you think?

> ResourceBuilder: Split up ResourceBuilder and ResourceBuilderFactory
> 
>
> Key: SLING-6039
> URL: https://issues.apache.org/jira/browse/SLING-6039
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Resource Builder 1.0.0
>
>
> i do not understand why we combine the use cases
> * resource builder creation
> * resource builder usage
> in one single ResourceBuilder interface, with two implementations each only 
> supporting the one part or another, throwing exception when the other methods 
> are used.
> it think it would be quite cleaner and easier to understand to create a 
> separate ResourceBuilderFactory interface.



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

[jira] [Commented] (SLING-6039) ResourceBuilder: Split up ResourceBuilder and ResourceBuilderFactory

[ASF GitHub Bot (JIRA)]

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

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

GitHub user stefanseifert opened a pull request:

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

SLING-6039 ResourceBuilder: Split up ResourceBuilder and 
ResourceBuilderFactory



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

$ git pull https://github.com/stefanseifert/sling 
feature/SLING-6039-resourcebuilder-factory

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

https://github.com/apache/sling/pull/166.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 #166


commit 79cce1881d2dd14731711ad187125ca47b368878
Author: sseifert 
Date:   2016-09-06T09:56:09Z

SLING-6039 ResourceBuilder: Split up ResourceBuilder and 
ResourceBuilderFactory




> ResourceBuilder: Split up ResourceBuilder and ResourceBuilderFactory
> 
>
> Key: SLING-6039
> URL: https://issues.apache.org/jira/browse/SLING-6039
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Resource Builder 1.0.0
>
>
> i do not understand why we combine the use cases
> * resource builder creation
> * resource builder usage
> in one single ResourceBuilder interface, with two implementations each only 
> supporting the one part or another, throwing exception when the other methods 
> are used.
> it think it would be quite cleaner and easier to understand to create a 
> separate ResourceBuilderFactory interface.



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

[GitHub] sling pull request #166: SLING-6039 ResourceBuilder: Split up ResourceBuilde...

[stefanseifert]

GitHub user stefanseifert opened a pull request:

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

SLING-6039 ResourceBuilder: Split up ResourceBuilder and 
ResourceBuilderFactory



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

$ git pull https://github.com/stefanseifert/sling 
feature/SLING-6039-resourcebuilder-factory

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

https://github.com/apache/sling/pull/166.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 #166


commit 79cce1881d2dd14731711ad187125ca47b368878
Author: sseifert 
Date:   2016-09-06T09:56:09Z

SLING-6039 ResourceBuilder: Split up ResourceBuilder and 
ResourceBuilderFactory




---
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] [Created] (SLING-6039) ResourceBuilder: Split up ResourceBuilder and ResourceBuilderFactory

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6039:
-

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


i do not understand why we combine the use cases
* resource builder creation
* resource builder usage

in one single ResourceBuilder interface, with two implementations each only 
supporting the one part or another, throwing exception when the other methods 
are used.

it think it would be quite cleaner and easier to understand to create a 
separate ResourceBuilderFactory interface.



--
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=15467001#comment-15467001
 ] 

Antonio Sanso commented on SLING-5135:
--

bq. LoginAdminWhitelistImpl has a whitelist.bypass configuration parameter that 
completely bypasses the whitelist, I suppose that's what you mean?

yes thanks!! 

> 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

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-5135:


You're right that this might break some things in 
{{org.apache.sling.resourceresolver}}, at least the 
{{ResourceResolverWebConsolePlugin}}. 

Apart from that I suppose calls to 
{{ResourceResolverFactory.getAdministrativeResourceResolver}} ultimately end up 
in a call to {{loginAdministrative}} which is subject to the whitelist? I'd 
need to dig deeper to confirm.

At this point we might commit this, adding 
{{org.apache.sling.resourceresolver}} to the default whitelist, and create a 
distinct ticket for implementing a similar mechanism for 
{{ResourceResolverFactory.getAdministrativeResourceResolver}}. But I won't have 
time to work on the latter in the next few weeks, so I'm not sure if it's a 
good idea to leave this half-finished in this way, unless someone can pick that 
up.

bq. Do we want an extra boolean config thats says {{enableWhiteList}} ?

{{LoginAdminWhitelistImpl}} has a {{whitelist.bypass}} configuration parameter 
that completely bypasses the whitelist, I suppose that's what you mean?

> 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?

[Stefan Seifert]

>We have
>https://sling.apache.org/documentation/bundles/scripting/scripting-htl.html
>which
>documents most of the available bundles (except for the two new compilers -
>I'll add them soon).

perhaps we should also add an addition like "formerly known as Sightly, renamed 
in August 2016" etc., so people do not get confused esp. as slightly still 
occurs in all technical names on this page.

stefan

[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=15466944#comment-15466944
 ] 

Stefan Seifert commented on SLING-6025:
---

i played around with porting it to metatype and encountered some problems:
# biggest problem: the metatype service provides information about 
objectclasses and attributes definitions, but there is not longer any 
connection to the annotation class (which from an osgi perspective makes sense, 
because the class is only one convenience way of defining metatypes, and not 
the only way).
** for our use case this is problematic: we have a class in the config API, and 
need to look up at least the configuration name if not the default (class name) 
is used. we have no way of finding the attached metatype (unless its by chance 
the default = class name), and no way of reading it directly from the 
ObjectClass annotation because it is not available at runtime
** we also need this connection to look up the custom metadata we provide with 
custom annotations in the class
** the only attribute containing a hint for the class name (if a custom 
id/configname is used) is the "localization" property - but it does not seem to 
be safe/correct to try to parse the class name out of a string like 
{{OSGI-INF/l10n/org.apache.sling.testing.mock.osgi.metatype.SimpleConfig}}.
# if i understand the metatype service correctly the id (our configname) has 
only to be unique within the bundle.
** in our use case the config name has to be unique overall the instance.
** with the metatype service it's difficult to detect and generate a warning if 
someone by accidents defines a config name/objectclass id that is already in 
use by another application. at least a warning should be logged.
# nested annotation classes: out of the box the maven bundle plugin/bnd does 
not accept generating objectclass definitions for annotation classes containing 
other annotation classes with object class defintions on it.
** when setting a special bundle header {{-metatypeannotations-options=nested}} 
is it supported
** but the result is still wrong, the generated object class has attributes of 
type "String"
** we could remove the support for nested annotation classes, but this would be 
sad as it is useful and fits neatly into the resource hierarchy concept. 
perhaps it's only an issue in bndlib
** i've not yet looked up the metatype spec if the say anything about if and 
how nested metatypes should be supported

> 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)

Re: Build failed in Jenkins: sling-tooling-trunk-1.7 #262

[Radu Cotescu]

Thanks for this - fixed in
https://svn.apache.org/viewvc/sling/trunk/tooling/maven/pom.xml?r1=1759381=1759380=1759381
.

On Tue, 6 Sep 2016 at 10:31 Robert Munteanu  wrote:

> Looks like this is broken by the Sightly → HTL rename.
>
> Robert
>
>
> On Mon, 2016-09-05 at 16:12 +, Apache Jenkins Server wrote:
> > See  > s>
> >
> > Changes:
> >
> > [radu] releng: updated dependencies
> >
> > [radu] [maven-release-plugin] prepare for next development iteration
> >
> > [radu] [maven-release-plugin] prepare release htl-maven-plugin-1.0.0
> >
> > [radu] [maven-release-plugin] prepare for next development iteration
> >
> > [radu] [maven-release-plugin] prepare release no
> >
> > [radu] releng: updated dependencies
> >
> > [radu] trivial: removed empty folder
> >
> > --
> > Started by an SCM change
> > [EnvInject] - Loading node environment variables.
> > Building remotely on ubuntu-4 (Ubuntu yahoo-not-h2 ubuntu ubuntu4
> > docker) in workspace  > nk-1.7/ws/>
> > Cleaning up  > /trunk>
> > Deleting  > unk/maven-launchpad-plugin/target>
> > Deleting  > unk/sightly-maven-plugin/target>
> > Deleting  > unk/slingstart-maven-plugin/target>
> > Deleting  > unk/maven-jcrocm-plugin/target>
> > Deleting  > unk/target>
> > Deleting  > unk/archetypes/launchpad-standalone/target>
> > Deleting  > unk/archetypes/taglib/target>
> > Deleting  > unk/archetypes/initial-content/target>
> > Deleting  > unk/archetypes/slingstart/target>
> > Deleting  > unk/archetypes/target>
> > Deleting  > unk/archetypes/bundle/target>
> > Deleting  > unk/archetypes/bundle-for-jcrinstall/target>
> > Deleting  > unk/archetypes/parent/target>
> > Deleting  > unk/archetypes/launchpad-webapp/target>
> > Deleting  > unk/archetypes/servlet/target>
> > Deleting  > unk/maven-jspc-plugin/target>
> > Deleting  > unk/maven-sling-plugin/target>
> > Updating http://svn.apache.org/repos/asf/sling/trunk/tooling/maven at
> > revision '2016-09-05T16:12:22.425 +'
> > D sightly-maven-plugin
> > A htl-maven-plugin
> > A htl-maven-plugin/pom.xml
> > A htl-maven-plugin/src
> > A htl-maven-plugin/src/main
> > A htl-maven-plugin/src/main/resources
> > A htl-maven-plugin/src/main/resources/META-INF
> > A htl-maven-plugin/src/main/resources/META-INF/m2e
> > A htl-maven-plugin/src/main/resources/META-INF/m2e/lifecycle-
> > mapping-metadata.xml
> > A htl-maven-plugin/src/main/java
> > A htl-maven-plugin/src/main/java/org
> > A htl-maven-plugin/src/main/java/org/apache
> > A htl-maven-plugin/src/main/java/org/apache/sling
> > A htl-maven-plugin/src/main/java/org/apache/sling/maven
> > A htl-maven-plugin/src/main/java/org/apache/sling/maven/htl
> > A htl-maven-
> > plugin/src/main/java/org/apache/sling/maven/htl/ValidateMojo.java
> > A htl-maven-plugin/src/test
> > A htl-maven-plugin/src/test/java
> > A htl-maven-plugin/src/test/java/org
> > A htl-maven-plugin/src/test/java/org/apache
> > A htl-maven-plugin/src/test/java/org/apache/sling
> > A htl-maven-plugin/src/test/java/org/apache/sling/maven
> > A htl-maven-plugin/src/test/java/org/apache/sling/maven/htl
> > A htl-maven-
> > plugin/src/test/java/org/apache/sling/maven/htl/ValidateMojoTest.java
> > A htl-maven-
> > plugin/src/test/java/org/apache/sling/maven/htl/ProjectStub.java
> > A htl-maven-plugin/src/test/resources
> > A htl-maven-plugin/src/test/resources/test-project
> > A htl-maven-plugin/src/test/resources/test-project/explicit-
> > includes.pom.xml
> > A htl-maven-plugin/src/test/resources/test-project/explicit-
> > 

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]

Hi,

I've just replied in the other thread - there are no backwards
compatibility issues introduced by the rename as this was mostly cosmetic:
I've only changed projects' names and descriptions. None of the tests were
changed for these releases.

Thanks,
Radu

On Tue, 6 Sep 2016 at 09:41 Bertrand Delacretaz 
wrote:

> Hi,
>
> On Mon, Sep 5, 2016 at 6:59 PM, Radu Cotescu  wrote:
> > ...1. the modularisation of the Sightly engine - now renamed to HTL...
>
> Before voting on this release I have concerns about the name change
> and related backwards compatibility issues, added my thoughts in the
> "What's wrong with Sightly?" thread here.
>
> -Bertrand
>

Re: What's wrong with Sightly?

[Radu Cotescu]

Hi,

We have
https://sling.apache.org/documentation/bundles/scripting/scripting-htl.html
which
documents most of the available bundles (except for the two new compilers -
I'll add them soon).

The rename is mostly cosmetic - the bundles names and API are the same.
I've only changed the projects' names and updated the descriptions.

Please let me know if we need something more than that.

Thanks,
Radu

On Tue, 6 Sep 2016 at 09:39 Bertrand Delacretaz 
wrote:

> Hi,
>
> On Tue, Sep 6, 2016 at 2:03 AM, Justin Edelson 
> wrote:
> > ...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...
>
> I'm not opposed to renaming but I think we need a clear description of
> what changed, including possible backwards compatibility issues (due
> to name changes etc).
>
> I don't think we have a Sightly page at
> http://sling.apache.org/documentation/bundles.html, this might be a
> good opportunity to create one listing which bundles we provide and
> explaining the name change.
>
> Radu (as you've mostly been working on this), WDYT?
>
> -Bertrand
>

Re: Build failed in Jenkins: sling-tooling-trunk-1.7 #262

[Robert Munteanu]

Looks like this is broken by the Sightly → HTL rename.

Robert


On Mon, 2016-09-05 at 16:12 +, Apache Jenkins Server wrote:
> See  s>
> 
> Changes:
> 
> [radu] releng: updated dependencies
> 
> [radu] [maven-release-plugin] prepare for next development iteration
> 
> [radu] [maven-release-plugin] prepare release htl-maven-plugin-1.0.0
> 
> [radu] [maven-release-plugin] prepare for next development iteration
> 
> [radu] [maven-release-plugin] prepare release no
> 
> [radu] releng: updated dependencies
> 
> [radu] trivial: removed empty folder
> 
> --
> Started by an SCM change
> [EnvInject] - Loading node environment variables.
> Building remotely on ubuntu-4 (Ubuntu yahoo-not-h2 ubuntu ubuntu4
> docker) in workspace  nk-1.7/ws/>
> Cleaning up  /trunk>
> Deleting  unk/maven-launchpad-plugin/target>
> Deleting  unk/sightly-maven-plugin/target>
> Deleting  unk/slingstart-maven-plugin/target>
> Deleting  unk/maven-jcrocm-plugin/target>
> Deleting  unk/target>
> Deleting  unk/archetypes/launchpad-standalone/target>
> Deleting  unk/archetypes/taglib/target>
> Deleting  unk/archetypes/initial-content/target>
> Deleting  unk/archetypes/slingstart/target>
> Deleting  unk/archetypes/target>
> Deleting  unk/archetypes/bundle/target>
> Deleting  unk/archetypes/bundle-for-jcrinstall/target>
> Deleting  unk/archetypes/parent/target>
> Deleting  unk/archetypes/launchpad-webapp/target>
> Deleting  unk/archetypes/servlet/target>
> Deleting  unk/maven-jspc-plugin/target>
> Deleting  unk/maven-sling-plugin/target>
> Updating http://svn.apache.org/repos/asf/sling/trunk/tooling/maven at
> revision '2016-09-05T16:12:22.425 +'
> D sightly-maven-plugin
> A htl-maven-plugin
> A htl-maven-plugin/pom.xml
> A htl-maven-plugin/src
> A htl-maven-plugin/src/main
> A htl-maven-plugin/src/main/resources
> A htl-maven-plugin/src/main/resources/META-INF
> A htl-maven-plugin/src/main/resources/META-INF/m2e
> A htl-maven-plugin/src/main/resources/META-INF/m2e/lifecycle-
> mapping-metadata.xml
> A htl-maven-plugin/src/main/java
> A htl-maven-plugin/src/main/java/org
> A htl-maven-plugin/src/main/java/org/apache
> A htl-maven-plugin/src/main/java/org/apache/sling
> A htl-maven-plugin/src/main/java/org/apache/sling/maven
> A htl-maven-plugin/src/main/java/org/apache/sling/maven/htl
> A htl-maven-
> plugin/src/main/java/org/apache/sling/maven/htl/ValidateMojo.java
> A htl-maven-plugin/src/test
> A htl-maven-plugin/src/test/java
> A htl-maven-plugin/src/test/java/org
> A htl-maven-plugin/src/test/java/org/apache
> A htl-maven-plugin/src/test/java/org/apache/sling
> A htl-maven-plugin/src/test/java/org/apache/sling/maven
> A htl-maven-plugin/src/test/java/org/apache/sling/maven/htl
> A htl-maven-
> plugin/src/test/java/org/apache/sling/maven/htl/ValidateMojoTest.java
> A htl-maven-
> plugin/src/test/java/org/apache/sling/maven/htl/ProjectStub.java
> A htl-maven-plugin/src/test/resources
> A htl-maven-plugin/src/test/resources/test-project
> A htl-maven-plugin/src/test/resources/test-project/explicit-
> includes.pom.xml
> A htl-maven-plugin/src/test/resources/test-project/explicit-
> excludes.pom.xml
> A htl-maven-plugin/src/test/resources/test-project/fail-on-
> warnings.pom.xml
> A htl-maven-plugin/src/test/resources/test-project/src
> A htl-maven-plugin/src/test/resources/test-project/src/main
> A htl-maven-plugin/src/test/resources/test-
> project/src/main/resources
> A htl-maven-plugin/src/test/resources/test-
> 

Re: September Board Report

[Robert Munteanu]

On Mon, 2016-09-05 at 07:55 -0700, Carsten Ziegeler wrote:
> Hi,
> 
> I've prepared the September board report here:
> 
> https://cwiki.apache.org/confluence/display/SLING/Status+Report+Septe
> mber+2016
> 
> Please review, adjust, comment
> 

Looks good to me, thanks.

Robert

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

[Bertrand Delacretaz]

Hi,

On Mon, Sep 5, 2016 at 6:59 PM, Radu Cotescu  wrote:
> ...1. the modularisation of the Sightly engine - now renamed to HTL...

Before voting on this release I have concerns about the name change
and related backwards compatibility issues, added my thoughts in the
"What's wrong with Sightly?" thread here.

-Bertrand

Re: What's wrong with Sightly?

[Bertrand Delacretaz]

Hi,

On Tue, Sep 6, 2016 at 2:03 AM, Justin Edelson  wrote:
> ...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...

I'm not opposed to renaming but I think we need a clear description of
what changed, including possible backwards compatibility issues (due
to name changes etc).

I don't think we have a Sightly page at
http://sling.apache.org/documentation/bundles.html, this might be a
good opportunity to create one listing which bundles we provide and
explaining the name change.

Radu (as you've mostly been working on this), WDYT?

-Bertrand