[jira] [Commented] (SLING-8279) Having a Resource + ResourceMetadata should be sufficient for roundtrip link mapping.
[ https://issues.apache.org/jira/browse/SLING-8279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771651#comment-16771651 ] Konrad Windszus commented on SLING-8279: IMHO constructing a URL from a repo path should rather be done in the view (i.e. HTL) or even in the rewriter. Why do you need the mapping in the model? > Having a Resource + ResourceMetadata should be sufficient for roundtrip link > mapping. > - > > Key: SLING-8279 > URL: https://issues.apache.org/jira/browse/SLING-8279 > Project: Sling > Issue Type: Wish > Components: ResourceResolver >Reporter: Mark Adamcin >Priority: Major > > With Sling Models, it is very easy to construct composite model types from > more than one resource, usually addressable as a subtree of the repository. > However, a pattern is emerging where mapping is being performed to create > related links within the model, which mandates that SlingHttpServletRequest > be used as the adaptable type, because a Resource adaptable would not provide > sufficient context for ResourceResolver.map(). Without a request for context, > .map() would likely return incorrect links based on a default base request > URL of "http://localhost/;. > While on one hand, it might be argued that link mapping should only occur in > the view, after the model graph has been constructed, on the other hand, link > resolution and resource mapping are so fundamental to the correct behavior of > a web application that we should take advantage of every opportunity to make > these activities more convenient and less error prone. > If you trace the code for resource resolution and mapping, you will find that > it relies on just four discrete contextual properties that are currently > available only from a request object (i.e. not available from a Resource or > its ResourceMetadata): > # scheme > # host > # port > # contextPath > In addition, given that the ResourceResolver used by servlets when handling a > request is generally retrieved from the Sling Request itself using > getResourceResolver(), it seems redundant in concept, not to mention clumsy > in practice, to require passing the request as an argument back to the > resource resolver (that was created specifically for the request in question) > in order to render links for any resources resolved while servicing that > request. > I think it is time to change the expected behavior of > ResourceResolver.resolve(String), ResourceResolver.map(String path), and > other ResourceResolver methods that return resources without an explicit > HttpServletRequest parameter, such that: > # request.getResourceResolver().resolve(path) returns the same Resource as > (any ResourceResolver).resolve(request, path) > # request.getResourceResolver().map(path) returns the same String as (any > ResourceResolver).map(request, path) > # > request.getResourceResolver().getResource(somePath).getResourceResolver().resolve(path) > returns the same Resource as request.getResourceResolver().resolve(path) > # > request.getResourceResolver().findResources(someQuery).next().getResourceResolver().resolve(path) > returns the same Resource as request.getResourceResolver().resolve(path) > # etc. > # ResourceResolverFactory.getResourceResolver(Map) and > ResourceResolverFactory.getServiceResourceResolver(Map) would return > ResourceResolvers that continue to use > [http://localhost:80|http://localhost/] as the default context url. > If these constraints can not be satisfied reasonably using the existing > resolve(String) and map(String) methods, I would propose adding overloads > that accept a context Resource in place of the context HttpServletRequest, > with additional properties added to ResourceMetadata during request resource > resolution that persist the four request context properties listed above > (scheme, host, port, contextPath). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] rombert commented on issue #1: SLING-8278 improve chrome audit score
rombert commented on issue #1: SLING-8278 improve chrome audit score URL: https://github.com/apache/sling-org-apache-sling-starter-content/pull/1#issuecomment-464966446 A SonarQube report for the changes added _only by this pull request_ was generated. Please review it at https://builds.apache.org/job/Sling/job/sling-org-apache-sling-starter-content/job/PR-1/1/artifact/target/sonar/issues-report/issues-report-light.html This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (SLING-8279) Having a Resource + ResourceMetadata should be sufficient for roundtrip link mapping.
[ https://issues.apache.org/jira/browse/SLING-8279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Adamcin updated SLING-8279: Description: With Sling Models, it is very easy to construct composite model types from more than one resource, usually addressable as a subtree of the repository. However, a pattern is emerging where mapping is being performed to create related links within the model, which mandates that SlingHttpServletRequest be used as the adaptable type, because a Resource adaptable would not provide sufficient context for ResourceResolver.map(). Without a request for context, .map() would likely return incorrect links based on a default base request URL of "http://localhost/;. While on one hand, it might be argued that link mapping should only occur in the view, after the model graph has been constructed, on the other hand, link resolution and resource mapping are so fundamental to the correct behavior of a web application that we should take advantage of every opportunity to make these activities more convenient and less error prone. If you trace the code for resource resolution and mapping, you will find that it relies on just four discrete contextual properties that are currently available only from a request object (i.e. not available from a Resource or its ResourceMetadata): # scheme # host # port # contextPath In addition, given that the ResourceResolver used by servlets when handling a request is generally retrieved from the Sling Request itself using getResourceResolver(), it seems redundant in concept, not to mention clumsy in practice, to require passing the request as an argument back to the resource resolver (that was created specifically for the request in question) in order to render links for any resources resolved while servicing that request. I think it is time to change the expected behavior of ResourceResolver.resolve(String), ResourceResolver.map(String path), and other ResourceResolver methods that return resources without an explicit HttpServletRequest parameter, such that: # request.getResourceResolver().resolve(path) returns the same Resource as (any ResourceResolver).resolve(request, path) # request.getResourceResolver().map(path) returns the same String as (any ResourceResolver).map(request, path) # request.getResourceResolver().getResource(somePath).getResourceResolver().resolve(path) returns the same Resource as request.getResourceResolver().resolve(path) # request.getResourceResolver().findResources(someQuery).next().getResourceResolver().resolve(path) returns the same Resource as request.getResourceResolver().resolve(path) # etc. # ResourceResolverFactory.getResourceResolver(Map) and ResourceResolverFactory.getServiceResourceResolver(Map) would return ResourceResolvers that continue to use [http://localhost:80|http://localhost/] as the default context url. If these constraints can not be satisfied reasonably using the existing resolve(String) and map(String) methods, I would propose adding overloads that accept a context Resource in place of the context HttpServletRequest, with additional properties added to ResourceMetadata during request resource resolution that persist the four request context properties listed above (scheme, host, port, contextPath). was: With Sling Models, it is very easy to construct composite model types from more than one resource, usually addressable as a subtree of the repository. However, a pattern is emerging where mapping is being performed to create related links within the model, which mandates that SlingHttpServletRequest be used as the adaptable type, because a Resource adaptable would not provide sufficient context for ResourceResolver.map(). Without a request for context, .map() would likely return incorrect links based on a default base request URL of "http://localhost/;. While on one hand, it might be argued that link mapping should only occur in the view, after the model graph has been constructed, on the other hand, link resolution and resource mapping are so fundamental to the correct behavior of a web application that we should take advantage of every opportunity to make these activities more convenient and less error prone. If you trace the code for resource resolution and mapping, you will find that it relies on just four discrete contextual properties that are currently available only from a request object (i.e. not available from a Resource or its ResourceMetadata): # scheme # host # port # contextPath In addition, given that the ResourceResolver used by servlets when handling a request is generally retrieved from the Sling Request itself using getResourceResolver(), it seems redundant in concept, not to mention clumsy in practice, to require passing the request as an argument back to the resource resolver (that was created specifically for the request in question) in
[jira] [Updated] (SLING-8279) Having a Resource + ResourceMetadata should be sufficient for roundtrip link mapping.
[ https://issues.apache.org/jira/browse/SLING-8279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Adamcin updated SLING-8279: Description: With Sling Models, it is very easy to construct composite model types from more than one resource, usually addressable as a subtree of the repository. However, a pattern is emerging where mapping is being performed to create related links within the model, which mandates that SlingHttpServletRequest be used as the adaptable type, because a Resource adaptable would not provide sufficient context for ResourceResolver.map(). Without a request for context, .map() would likely return incorrect links based on a default base request URL of "http://localhost/;. While on one hand, it might be argued that link mapping should only occur in the view, after the model graph has been constructed, on the other hand, link resolution and resource mapping are so fundamental to the correct behavior of a web application that we should take advantage of every opportunity to make these activities more convenient and less error prone. If you trace the code for resource resolution and mapping, you will find that it relies on just four discrete contextual properties that are currently available only from a request object (i.e. not available from a Resource or its ResourceMetadata): # scheme # host # port # contextPath In addition, given that the ResourceResolver used by servlets when handling a request is generally retrieved from the Sling Request itself using getResourceResolver(), it seems redundant in concept, not to mention clumsy in practice, to require passing the request as an argument back to the resource resolver (that was created specifically for the request in question) in order to render links for any resources resolved while servicing that request. I think it is time to change the expected behavior of ResourceResolver.resolve(String), ResourceResolver.map(String path), and other ResourceResolver methods that return resources without an explicit HttpServletRequest parameter, such that: # request.getResourceResolver().resolve(path) returns the same Resource as (any ResourceResolver).resolve(request, path) # request.getResourceResolver().map(path) returns the same String as (any ResourceResolver).map(request, path) # request.getResourceResolver().getResource(somePath).getResourceResolver().resolve(path) returns the same Resource as request.getResourceResolver().resolve(path) # request.getResourceResolver().findResources(someQuery).next().getResourceResolver().resolve(path) returns the same Resource as request.getResourceResolver().resolve(path) # etc. If these constraints can not be satisfied reasonably using the existing resolve(String) and map(String) methods, I would propose adding overloads that accept a context Resource in place of the context HttpServletRequest, with additional properties added to ResourceMetadata during request resource resolution that persist the four request context properties listed above (scheme, host, port, contextPath). was: With Sling Models, it is very easy to construct composite model types from more than one resource, usually addressable as a subtree of the repository. However, a pattern is emerging where mapping is being performed to create related links within the model, which mandates that SlingHttpServletRequest be used as the adaptable type, because a Resource adaptable would not provide sufficient context for ResourceResolver.map(). Without a request for context, .map() would likely return incorrect links based on a default base request URL of "http://localhost/;. If you trace the code for resource resolution and mapping, you will find that it relies on just four discrete contextual properties that are currently available only from a request object (and not available from a Resource or ResourceMetadata): # scheme # host # port # contextPath In addition, given that the ResourceResolver used by servlets when handling a request is generally retrieved from the Sling Request itself using getResourceResolver(), it seems redundant in concept, not to mention clumsy in practice, to require passing the request as an argument back to the resource resolver (that was created specifically for the request in question) in order to render links for any resources resolved while servicing that request. I think it is time to change the expected behavior of ResourceResolver.resolve(String), ResourceResolver.map(String path), and other ResourceResolver methods that return resources without an explicit HttpServletRequest parameter, such that: # request.getResourceResolver().resolve(path) returns the same Resource as (any ResourceResolver).resolve(request, path) # request.getResourceResolver().map(path) returns the same String as (any ResourceResolver).map(request, path) #
[jira] [Created] (SLING-8279) Having a Resource + ResourceMetadata should be sufficient for roundtrip link mapping.
Mark Adamcin created SLING-8279: --- Summary: Having a Resource + ResourceMetadata should be sufficient for roundtrip link mapping. Key: SLING-8279 URL: https://issues.apache.org/jira/browse/SLING-8279 Project: Sling Issue Type: Wish Components: ResourceResolver Reporter: Mark Adamcin With Sling Models, it is very easy to construct composite model types from more than one resource, usually addressable as a subtree of the repository. However, a pattern is emerging where mapping is being performed to create related links within the model, which mandates that SlingHttpServletRequest be used as the adaptable type, because a Resource adaptable would not provide sufficient context for ResourceResolver.map(). Without a request for context, .map() would likely return incorrect links based on a default base request URL of "http://localhost/;. If you trace the code for resource resolution and mapping, you will find that it relies on just four discrete contextual properties that are currently available only from a request object (and not available from a Resource or ResourceMetadata): # scheme # host # port # contextPath In addition, given that the ResourceResolver used by servlets when handling a request is generally retrieved from the Sling Request itself using getResourceResolver(), it seems redundant in concept, not to mention clumsy in practice, to require passing the request as an argument back to the resource resolver (that was created specifically for the request in question) in order to render links for any resources resolved while servicing that request. I think it is time to change the expected behavior of ResourceResolver.resolve(String), ResourceResolver.map(String path), and other ResourceResolver methods that return resources without an explicit HttpServletRequest parameter, such that: # request.getResourceResolver().resolve(path) returns the same Resource as (any ResourceResolver).resolve(request, path) # request.getResourceResolver().map(path) returns the same String as (any ResourceResolver).map(request, path) # request.getResourceResolver().getResource(somePath).getResourceResolver().resolve(path) returns the same Resource as request.getResourceResolver().resolve(path) # request.getResourceResolver().findResources(someQuery).next().getResourceResolver().resolve(path) returns the same Resource as request.getResourceResolver().resolve(path) # etc. If these constraints can not be satisfied reasonably using the existing resolve(String) and map(String) methods, I would propose adding overloads that accept a context Resource in place of the context HttpServletRequest, with additional properties added to ResourceMetadata during request resource resolution that persist the four request context properties listed above (scheme, host, port, contextPath). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] reusr1 opened a new pull request #1: SLING-8278 improve chrome audit score
reusr1 opened a new pull request #1: SLING-8278 improve chrome audit score URL: https://github.com/apache/sling-org-apache-sling-starter-content/pull/1 increase accessibility and seo score to 100/100, best practices to 87/100 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (SLING-8278) improve chrome audit score
Ruben Reusser created SLING-8278: Summary: improve chrome audit score Key: SLING-8278 URL: https://issues.apache.org/jira/browse/SLING-8278 Project: Sling Issue Type: Improvement Components: Starter Reporter: Ruben Reusser google chrome audit currently lists a set of accessibility and seo problems with the sling starter content. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[Jenkins] Sling » sling-org-apache-sling-launchpad-testing » master #21 is FIXED
Please see https://builds.apache.org/job/Sling/job/sling-org-apache-sling-launchpad-testing/job/master/21/ for details. No further emails will be sent until the status of the build is changed.
Re: [Jenkins] Sling » sling-org-apache-sling-launchpad-testing » master #20 is BROKEN
On Mon, 2019-02-18 at 13:27 +, Apache Jenkins Server wrote: > [INFO] > [INFO] Results: > [INFO] > [ERROR] Failures: > [ERROR] SlingJSPTaglibTest.testTaglib:80- > >RenderingTestBase.assertContains:3 Failed to push the updated ITs after the latest JSP Taglib release. Should be fixed now with https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/commit/daf0aea Thanks, Robert
[Jenkins] Sling » sling-org-apache-sling-launchpad-testing » master #20 is BROKEN
[INFO] --- slingstart-maven-plugin:1.7.16:stop (stop-container) @
org.apache.sling.launchpad.testing ---
[INFO] Stopping 1 Launchpad instances
[INFO] Stopping Launchpad '_-41000'
18.02.2019 13:25:48.794 *INFO * [Apache Sling Terminator] Java VM is shutting
down
18.02.2019 13:25:48.794 *INFO * [Apache Sling Terminator] Stopping Apache Sling
18.02.2019 13:25:56.153 *INFO * [Sling Notifier] Apache Sling has been stopped
[INFO]
[INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @
org.apache.sling.launchpad.testing ---
[INFO] Checking legal files in:
org.apache.sling.launchpad.testing-12-SNAPSHOT.jar
[INFO] Checking legal files in:
org.apache.sling.launchpad.testing-12-SNAPSHOT-sources.jar
[INFO]
[INFO] --- apache-rat-plugin:0.11:check (default) @
org.apache.sling.launchpad.testing ---
[INFO] 51 implicit excludes (use -debug for more details).
[INFO] Exclude: DEPENDENCIES
[INFO] Exclude: src/main/appended-resources/META-INF/*
[INFO] Exclude: velocity.log
[INFO] Exclude: target/*
[INFO] Exclude: README.md
[INFO] Exclude: maven-eclipse.xml
[INFO] Exclude: .*
[INFO] Exclude: .*/**
[INFO] Exclude: **/*.json
[INFO] Exclude: DEPENDENCIES
[INFO] Exclude: **/*.rej
[INFO] Exclude: hs_err_*.log
[INFO] Exclude: **/repository/index/*/index-details.txt
[INFO] Exclude: bnd.bnd
[INFO] 7 resources included (use -debug for more details)
[INFO] Rat check: Summary of files. Unapproved: 0 unknown: 0 generated: 0
approved: 6 licence.
[INFO]
[INFO] --- maven-failsafe-plugin:2.21.0:verify (default) @
org.apache.sling.launchpad.testing ---
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 03:39 min
[INFO] Finished at: 2019-02-18T13:25:57Z
[INFO]
[INFO] [jenkins-event-spy] Generated
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master@tmp/withMavenff05028d/maven-spy-20190218-132217-6261697087512898123252.log
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-failsafe-plugin:2.21.0:verify (default) on
project org.apache.sling.launchpad.testing: There are test failures.
[ERROR]
[ERROR] Please refer to
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master/target/failsafe-reports
for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump,
[date].dumpstream and [date]-jvmRun[N].dumpstream.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[Pipeline] }
[withMaven] junitPublisher - Archive test results for Maven artifact
org.apache.sling:org.apache.sling.launchpad.testing:slingstart:12-SNAPSHOT
generated by maven-surefire-plugin:test (default-test):
target/surefire-reports/*.xml
Recording test results
None of the test reports contained any result
[withMaven] junitPublisher - Archive test results for Maven artifact
org.apache.sling:org.apache.sling.launchpad.testing:slingstart:12-SNAPSHOT
generated by maven-failsafe-plugin:integration-test (default):
target/failsafe-reports/*.xml
Recording test results
[withMaven] Publishers: Pipeline Graph Publisher: 7 ms, Generated Artifacts
Publisher: 624 ms, Junit Publisher: 68448 ms, Dependencies Fingerprint
Publisher: 2231 ms, JGiven Publisher: 2 ms, Open Task Scanner Publisher: 153 ms
[Pipeline] // withMaven
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // timeout
[Pipeline] stage
[Pipeline] { (Notifications)
[Pipeline] echo
Status change is BROKEN, notifications will be sent.
[Pipeline] emailext
[jira] [Closed] (SLING-8266) Stop embedding ESAPI
[ https://issues.apache.org/jira/browse/SLING-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-8266. -- > Stop embedding ESAPI > > > Key: SLING-8266 > URL: https://issues.apache.org/jira/browse/SLING-8266 > Project: Sling > Issue Type: Improvement > Components: Scripting >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Scripting JSP Taglib 2.4.0 > > Time Spent: 3.5h > Remaining Estimate: 0h > > Since we now have an XSS API in Sling we should use this instead of embedding > the ESAPI jars, since: > - bundle size will be reduced > - possibility to embed an out-of-date version is removed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-8019) Use XSS API
[ https://issues.apache.org/jira/browse/SLING-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-8019. -- > Use XSS API > --- > > Key: SLING-8019 > URL: https://issues.apache.org/jira/browse/SLING-8019 > Project: Sling > Issue Type: Improvement > Components: Scripting >Reporter: Carsten Ziegeler >Assignee: Robert Munteanu >Priority: Major > Fix For: Scripting JSP Taglib 2.4.0, Scripting JSP Taglib Compat > 1.0.0 > > > For XSS support, the jsp taglib currently embeds its own copy of an xss > library. Instead it should rather use the xss api to avoid a copy > In addition, we should move the package > org.apache.sling.scripting.jsp.taglib.helpers to a separate bundle to free > the taglib bundle completely from that stuff -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-8270) Switch scripting JSP taglib to use commons-lang 3
[ https://issues.apache.org/jira/browse/SLING-8270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-8270. -- > Switch scripting JSP taglib to use commons-lang 3 > - > > Key: SLING-8270 > URL: https://issues.apache.org/jira/browse/SLING-8270 > Project: Sling > Issue Type: Sub-task > Components: Scripting >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Scripting JSP Taglib 2.4.0 > > > Will be done as a side effect of SLING-8266 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-8274) Revert changes that broke backwards compatibility
[ https://issues.apache.org/jira/browse/SLING-8274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-8274. -- > Revert changes that broke backwards compatibility > - > > Key: SLING-8274 > URL: https://issues.apache.org/jira/browse/SLING-8274 > Project: Sling > Issue Type: Bug > Components: Scripting >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Scripting JSP Taglib 2.4.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Some cleanups in the JSP taglib bundle meant that we bumped the major version > component for two packages: > * org.apache.sling.scripting.jsp.taglib > * org.apache.sling.scripting.jsp.taglib.helpers > These are not typically meant to be used from OSGi bundles but from JSPs. > However, I think that since they are exported we should manage these exports > carefully and revert them to the old state3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-8267) Add Missing CA Config Expression Language Functions
[ https://issues.apache.org/jira/browse/SLING-8267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-8267. -- > Add Missing CA Config Expression Language Functions > --- > > Key: SLING-8267 > URL: https://issues.apache.org/jira/browse/SLING-8267 > Project: Sling > Issue Type: Improvement >Affects Versions: Scripting JSP Taglib 2.3.0 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Major > Fix For: Scripting JSP Taglib 2.4.0 > > > In 2.3.0 we introduced tags to support for Context Aware configurations, > however, the CA config support did not expose the Expression Language > functions. The same functionality should be supported via Expression Language > functions and tags. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[RESULT] [VOTE] Release Apache Sling Scripting JSP Tag Library 2.4.0, Apache Sling Scripting JSP Tag Library (Compat) 1.0.0
Hi, The vote has passed with the following result: +1 (binding): Robert Munteanu, Carsten Ziegeler, Daniel Klco I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. Thanks all for voting. Robert
