[SLING-2803] Sling Validation Module
Hello Sling devs, I've proposed a new feature on JIRA [1], which is to create a Validation module that is able to validate requests or resources. More details can be read in the issue's description or in one of the comments [2]. Please tell me what are your thoughts on this. Best regards, Radu [1] - https://issues.apache.org/jira/browse/SLING-2803 [2] - https://issues.apache.org/jira/browse/SLING-2803?focusedCommentId=13616296page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13616296 [http://wwwimages.adobe.com/www.adobe.com/include/style/default/SiteHeader/logo.png] Radu Cotescu Computer Scientist Adobe Systems Romania +4(0) 314 133 693 (tel) +4(0) 744 406 353 (cell) cote...@adobe.commailto:cote...@adobe.com Anchor Plaza, 9th Floor 26Z Timisoara Blvd 061331, Bucharest, Romania www.adobe.comhttp://www.adobe.com
Re: Sling Posthandling - thougts about the current behavior
Something might come up this afternoon for SLING-2803 [1]. :) [1] - https://issues.apache.org/jira/browse/SLING-2803 As for validation: This is something we are sourely lacking in Sling anyway. I think input validation is definitely something which should be part of the default Sling POST Servlet processing. But it should also be a feature, which is available independently for those cases, where the POST request is fully handled outside of the POST servlet.
SLING-2803 implementation proposal
Hello, Finally I've had some time to finish a prototype for SLING-2803 [1]. I've attached a ZIP file (md5sum 6cd656b493f1adc0dd635aee9cb6de0d) to the issue with the proposed API, a default implementation bundle and a test services bundle that provides a simple HTTP integration test. More details are in the README.md file from the attached archive. Most, if not all, of the code is commented and it should be pretty obvious what it does. I'm looking forward for your feedback. If you like the API and the implementation maybe we can move them to the contrib/extensions section so that more developers can work on extending the module. Have a nice weekend! Regards, Radu [1] - https://issues.apache.org/jira/browse/SLING-2803
Re: SLING-2803 validation module, hierarchical structures and extensible types
Hi, Found what Alex was talking about in the org.apache.sling.jcr.resource.JcrPropertyMap class. I'm sorry for my previous answer. The implementation wasn't that obvious at first. What do you think the best approach would be given the hierarchical structures problem and the currently proposed validation API? The ValidationModel could describe the expected tree structure if we change the Fields to allow them to have children (in which case, judging from a JCR perspective, these Fields would actually translate to nodes instead of properties). Thanks, Radu Radu Cotescu | Software Engineer, Tech Blogger, Author Web:radu.cotescu.comEmail:radu@cotescu.comCell:+40 744 406 353 On Wed, Jul 3, 2013 at 10:18 PM, Carsten Ziegeler cziege...@apache.orgwrote: 2013/7/3 Alexander Klimetschek aklim...@adobe.com On 03.07.2013, at 17:34, Radu Cotescu r...@apache.org wrote: 1. Currently there's no support for hierarchical structures. ValueMap doesn't provide this kind of support. Yes, the jcr property value map implementation supports relative paths. This should definitely be supported, as you very quickly have a nested structure with JCR and the sling post servlet. So field names supporting relative paths should all there is required - this is in line with the sling post servlet. It was a mistake to add support for paths to the jcr value map - note that the jcr implementation of the modifiable value map does not support setting a property with a path - same with the whole create and update stuff in Sling's resource api. Other resource implementations don't allow paths for properties. If I could turn back the time I wouldn't add path support to the value map. It creates several problems implementation wise and blures the difference between a resource and its properties. For all future things we should have clean approaches. There might be resource types which require child resource (types) to exist - and we need a way to validate this. I think the correct way would be to have a validator which checks for such a child resource of a type and have separate validator sets for both, the parent and the child resource. Carsten 2. As long as the Field from the ValidationModel specifies a certain Validator to be used for validating the field's value I don't see why we couldn't have a Validator that checks the data in an external system. The single current constraint of a Validator is that it has to provide a validate method, returning a boolean. The implementation can be done however the developer sees fit. If the Validator is a service/component, then it can easily reference other services. Cheers, Alex -- Carsten Ziegeler cziege...@apache.org
Re: SLING-2803 validation module, hierarchical structures and extensible types
To sum things up: a. there's also a need for hierarchical structures validation b. we shouldn't rely on the ValueMap to provide the properties of child resources - there's only one ValueMap implementation that provides this, and only for read operations The proposed API currently: a. does not assume hierarchical structures - they could be defined in the ValidationModel (by extending the Field concept to also contain children) b. validates only ValueMaps and, given the recent discussions, should not assume that the ValueMaps provide the properties of a tree-like structure c. can be used to validate requests and resources as long as we don't expect tree-like structures However the ValueMap accepted by the validation service could contain path-like keys if it was obtained by adapting a request to it. Depending on what we need in Sling I see two solutions: 1. extend the current API and implementation to be able to validate tree-like structures - better suited for validating requests rather than resources, given that most ValueMap implementations don't provide us with the children's properties 2. erase and start over with a new validation framework at the ResourceResolver level that would handle validation right before the commit phase - this implies that we actually validate changed resources (credits to Carsten for this idea) Devs, which solution sounds better to you and why? Thanks, Radu On Thu, Jul 4, 2013 at 8:54 AM, Carsten Ziegeler cziege...@apache.orgwrote: As I wrote, a hierarchy is only supported by a single implementation for reading - not for writing, so it doesn't make sense to me to support this in validation as this can't be written through the resource api in the same way. The post servlet is splitting paths and creates a resource for each part of the path except the last part which is the property on the last resource. Carsten 2013/7/4 Radu Cotescu r...@cotescu.com Hi, Found what Alex was talking about in the org.apache.sling.jcr.resource.JcrPropertyMap class. I'm sorry for my previous answer. The implementation wasn't that obvious at first. What do you think the best approach would be given the hierarchical structures problem and the currently proposed validation API? The ValidationModel could describe the expected tree structure if we change the Fields to allow them to have children (in which case, judging from a JCR perspective, these Fields would actually translate to nodes instead of properties). Thanks, Radu Radu Cotescu | Software Engineer, Tech Blogger, Author Web:radu.cotescu.comEmail:radu@cotescu.comCell:+40 744 406 353 On Wed, Jul 3, 2013 at 10:18 PM, Carsten Ziegeler cziege...@apache.org wrote: 2013/7/3 Alexander Klimetschek aklim...@adobe.com On 03.07.2013, at 17:34, Radu Cotescu r...@apache.org wrote: 1. Currently there's no support for hierarchical structures. ValueMap doesn't provide this kind of support. Yes, the jcr property value map implementation supports relative paths. This should definitely be supported, as you very quickly have a nested structure with JCR and the sling post servlet. So field names supporting relative paths should all there is required - this is in line with the sling post servlet. It was a mistake to add support for paths to the jcr value map - note that the jcr implementation of the modifiable value map does not support setting a property with a path - same with the whole create and update stuff in Sling's resource api. Other resource implementations don't allow paths for properties. If I could turn back the time I wouldn't add path support to the value map. It creates several problems implementation wise and blures the difference between a resource and its properties. For all future things we should have clean approaches. There might be resource types which require child resource (types) to exist - and we need a way to validate this. I think the correct way would be to have a validator which checks for such a child resource of a type and have separate validator sets for both, the parent and the child resource. Carsten 2. As long as the Field from the ValidationModel specifies a certain Validator to be used for validating the field's value I don't see why we couldn't have a Validator that checks the data in an external system. The single current constraint of a Validator is that it has to provide a validate method, returning a boolean. The implementation can be done however the developer sees fit. If the Validator is a service/component, then it can easily reference other services. Cheers, Alex -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
Re: SLING-2803 validation module, hierarchical structures and extensible types
Hi, Apart from Carsten nobody else provided me with an answer to my question, which in the end boils down to what kind of validation is needed in Sling: Depending on what we need in Sling I see two solutions: 1. extend the current API and implementation to be able to validate tree-like structures - better suited for validating requests rather than resources, given that most ValueMap implementations don't provide us with the children's properties 2. erase and start over with a new validation framework at the ResourceResolver level that would handle validation right before the commit phase - this implies that we actually validate changed resources (credits to Carsten for this idea) Devs, which solution sounds better to you and why? What would be the minimum requirements for adding some validation bundles (api + impl) in contrib? Thanks, Radu On Mon, Jul 8, 2013 at 3:24 PM, Dominik Süß dominik.su...@gmail.com wrote: +1 - validation can also be necessary on dataimport through services, to have a default integration of this service in the default Post Handler is IMHO a mandatory but not stricktly bound extension to this service. Dominik On Mon, Jul 8, 2013 at 12:19 PM, Carsten Ziegeler cziege...@apache.org wrote: Even if there is processing overhead - and I think this is really minimal compared to persisting the data - storing unvalidated and therefore maybe wrong data might haver a much higher impact on the application. And I totally agree, this needs to be configurable (controllable) - but limiting this to the post servlet is way too restrictive. Carsten 2013/7/8 Alexander Klimetschek aklim...@adobe.com On 04.07.2013, at 14:56, Carsten Ziegeler cziege...@apache.org wrote: Adding this - maybe as an optional service - into the resource resolver makes it also impossible to bypass validation - the validation is always done regardless whether the changes are done through the post servlet, any other servlet, or some server side code running in the background. We should be careful with the imposed new processing overhead of this. There needs to be control over it, and IMO an active whitelisting for which validators (i.e. resource types) this would happen and when. And the simplest way to do that is to have custom application code call the validation service (one-liner) themselves and do it automatically only in the post servlet (but also with an option to enable/disable individual validators). Cheers, Alex -- Carsten Ziegeler cziege...@apache.org
release for org.apache.sling.commons.log
Hello, Could someone please cut a release for org.apache.sling.commons.log? There haven't been any releases since Aug. 26th and I'd like to have the fix for SLING-3045 [0] in the bundle. Thanks, Radu [0] - https://issues.apache.org/jira/browse/SLING-3045
Re: [jira] [Created] (SLING-3244) Upgrade sling.api in commons/testing
Hi, Since SLING-3244 was fixed could we also get a 2.0.16 release for org.apache.sling.commons.testing? Thanks, Radu On Wed, Nov 13, 2013 at 12:57 PM, Bertrand Delacretaz (JIRA) j...@apache.org wrote: Bertrand Delacretaz created SLING-3244: -- Summary: Upgrade sling.api in commons/testing Key: SLING-3244 URL: https://issues.apache.org/jira/browse/SLING-3244 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Commons Testing 2.0.14 Reporter: Bertrand Delacretaz Priority: Minor The commons/testing module still refers to org.apache.sling.api 2.1.0, so its mock classes are not compatible with later versions, which is troublesome when testing more modern code. The module should be updated to the latest sling.api, and mock classes adapted accordingly. -- This message was sent by Atlassian JIRA (v6.1#6144)
SLING-3320 Execution order of BindingsValuesProvider
Hi, I've attached a patch [1] for SLING-3320 [2]. Could somebody please review it and eventually apply it to trunk? Thanks, Radu [1] - https://issues.apache.org/jira/secure/attachment/12627387/SLING-3320_1.diff [2] - https://issues.apache.org/jira/browse/SLING-3320
release for org.apache.sling.maven-sling-plugin
Hello, Can someone please release the new org.apache.sling.maven-sling-plugin (2.1.2)? In my build process I would like to rely on this plugin to correctly fail the build if the bundle was not installed on the instance (see [0]). Thanks, Radu [0] - https://github.com/apache/sling/commit/771615f20ec9c269d0c8cb7c75db3bb06719a369
Re: [jira] [Created] (SLING-3464) The DynamicClassLoaderManager doesn't reload classes when a bundle transitions from STARTED to RESOLVED
Hi, Could someone please take a look at this and confirm if we're talking about a bug or a feature? Thanks, Radu On Wednesday, March 19, 2014, Radu Cotescu (JIRA) j...@apache.org wrote: Radu Cotescu created SLING-3464: --- Summary: The DynamicClassLoaderManager doesn't reload classes when a bundle transitions from STARTED to RESOLVED Key: SLING-3464 URL: https://issues.apache.org/jira/browse/SLING-3464 Project: Sling Issue Type: Bug Components: Commons Affects Versions: Commons ClassLoader 1.3.0 Reporter: Radu Cotescu Fix For: Commons ClassLoader 1.3.2 The bundle activator from org.apache.sling.commons.classloader also acts as a SynchronousBundleListener, taking care to clean the DynamicClassLoaderManager (DCLM) when a bundle changes its state. However, the DCLM doesn't get cleaned when a bundle transitions from STARTED to RESOLVED, which is inconsistent: for example no services will be resolved from that bundle, however classes already loaded through DCLM will get solved. -- This message was sent by Atlassian JIRA (v6.2#6252)
[org.apache.sling.commons.classloader] release 1.3.2
Hi, Could one of the committers please release a new version for org.apache.sling.commons.classloader? I would need the fixes from SLING-3071 and SLING-3464. Thanks, Radu
Re: [VOTE] Release Apache Sling Commons Classloader 1.3.2
+1 On Sat, Apr 12, 2014 at 4:06 PM, Carsten Ziegeler cziege...@apache.orgwrote: +1 2014-04-12 11:19 GMT+02:00 Carsten Ziegeler cziege...@apache.org: Hi, We solved some issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12321292 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1048 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1048 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards Carsten -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
[PROPOSAL] Sightly donation to Apache Sling
Hello, On behalf of Adobe Systems Inc. I'd like to contribute two modules to Apache Sling: - org.apache.sling.scripting.sightly - org.apache.sling.xss Sightly is the new web templating language shipped with Adobe Experience Manager 6.0 [0]. Our contribution to Apache Sling is a Java-based implementation, fully compliant with the language's specification. However, the language's specification is and will be owned by Adobe. For Sightly's contextual-based automated XSS escaping feature we're also donating the org.apache.sling.xss bundle that provides two useful services meant to help escaping or filtering user-submitted content that might be prone to XSS attacks. While the XSS module contains a decent amount of unit tests, the Sightly implementation was tested using a proprietary (for now) UI testing framework. I'm currently working on porting those tests into a test runner that will be made available under an Apache License on Maven Central; this runner could easily be integrated into Sightly's build process in the near future. SLING-3959 [1] has been opened to track the donation progress and the bundles are attached there. If the Sling community finds this donation interesting we can carry on with the IP clearance. Thanks, Radu *Sightly Credits:* Senol Tas, Honwai Wong - initial language specification and implementation Gabriel Walt - product manager, language specification Marius Dănilă, Radu Cotescu, Sameer Charles - Java implementation and JavaScript Use-API support Cătălin Buzoiu - engineering manager Feike Visser, Florin Iordache - early adopters implementing projects with Sightly, who provided valuable feedback during Sightly's development process [0] - http://docs.adobe.com/content/docs/en/aem/6-0/develop/sightly.html [1] - *https://issues.apache.org/jira/browse/SLING-3959 https://issues.apache.org/jira/browse/SLING-3959*
Re: [PROPOSAL] Sightly donation to Apache Sling
Hi Carsten, The specification will be available soon on GitHub [2] (matter of days). Until then the resource from [0] should give you an idea on how Sightly expressions look like and what plugins are available. Regards, Radu [2] - https://github.com/Adobe-Marketing-Cloud On Tue, Sep 23, 2014 at 7:07 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi Radu, thanks for the offering. This definitely looks very interesting for Sling. Is the spec downloadable from somewhere? When do you think the test suite will be available? Regards Carsten 2014-09-22 10:59 GMT+02:00 Radu Cotescu r...@apache.org: Hello, On behalf of Adobe Systems Inc. I'd like to contribute two modules to Apache Sling: - org.apache.sling.scripting.sightly - org.apache.sling.xss Sightly is the new web templating language shipped with Adobe Experience Manager 6.0 [0]. Our contribution to Apache Sling is a Java-based implementation, fully compliant with the language's specification. However, the language's specification is and will be owned by Adobe. For Sightly's contextual-based automated XSS escaping feature we're also donating the org.apache.sling.xss bundle that provides two useful services meant to help escaping or filtering user-submitted content that might be prone to XSS attacks. While the XSS module contains a decent amount of unit tests, the Sightly implementation was tested using a proprietary (for now) UI testing framework. I'm currently working on porting those tests into a test runner that will be made available under an Apache License on Maven Central; this runner could easily be integrated into Sightly's build process in the near future. SLING-3959 [1] has been opened to track the donation progress and the bundles are attached there. If the Sling community finds this donation interesting we can carry on with the IP clearance. Thanks, Radu *Sightly Credits:* Senol Tas, Honwai Wong - initial language specification and implementation Gabriel Walt - product manager, language specification Marius Dănilă, Radu Cotescu, Sameer Charles - Java implementation and JavaScript Use-API support Cătălin Buzoiu - engineering manager Feike Visser, Florin Iordache - early adopters implementing projects with Sightly, who provided valuable feedback during Sightly's development process [0] - http://docs.adobe.com/content/docs/en/aem/6-0/develop/sightly.html [1] - *https://issues.apache.org/jira/browse/SLING-3959 https://issues.apache.org/jira/browse/SLING-3959* -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[PROPOSAL] Integrate the Validation Framework prototype from SLING-2803 into contrib
Hello, I've updated my prototype of the Apache Sling Generic Validation Framework from SLING-2803 [0] in order to implement the features suggested in the issues' comments. If you think that this new API and current implementation would benefit Sling I'd be more than happy to donate this code to Apache Sling and help maintain it in the future. Thanks, Radu [0] - https://issues.apache.org/jira/browse/SLING-2803
Re: [PROPOSAL] Sightly donation to Apache Sling
Hi Carsten, I realised that I only half-answered your question. Ideally the TCK should be ready in 2, max. 3 weeks. As soon as we manage to push it to Maven Central it should be ready to be consumed in Sling. In parallel I'm working on a Sling bundle that should contain the TCK input scripts and a content structure that would allow running them as expected by the TCK such that we can test the Sling implementation. HTH, Radu On Tue, Sep 23, 2014 at 10:13 AM, Radu Cotescu r...@apache.org wrote: Hi Carsten, The specification will be available soon on GitHub [2] (matter of days). Until then the resource from [0] should give you an idea on how Sightly expressions look like and what plugins are available. Regards, Radu [2] - https://github.com/Adobe-Marketing-Cloud On Tue, Sep 23, 2014 at 7:07 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi Radu, thanks for the offering. This definitely looks very interesting for Sling. Is the spec downloadable from somewhere? When do you think the test suite will be available? Regards Carsten 2014-09-22 10:59 GMT+02:00 Radu Cotescu r...@apache.org: Hello, On behalf of Adobe Systems Inc. I'd like to contribute two modules to Apache Sling: - org.apache.sling.scripting.sightly - org.apache.sling.xss Sightly is the new web templating language shipped with Adobe Experience Manager 6.0 [0]. Our contribution to Apache Sling is a Java-based implementation, fully compliant with the language's specification. However, the language's specification is and will be owned by Adobe. For Sightly's contextual-based automated XSS escaping feature we're also donating the org.apache.sling.xss bundle that provides two useful services meant to help escaping or filtering user-submitted content that might be prone to XSS attacks. While the XSS module contains a decent amount of unit tests, the Sightly implementation was tested using a proprietary (for now) UI testing framework. I'm currently working on porting those tests into a test runner that will be made available under an Apache License on Maven Central; this runner could easily be integrated into Sightly's build process in the near future. SLING-3959 [1] has been opened to track the donation progress and the bundles are attached there. If the Sling community finds this donation interesting we can carry on with the IP clearance. Thanks, Radu *Sightly Credits:* Senol Tas, Honwai Wong - initial language specification and implementation Gabriel Walt - product manager, language specification Marius Dănilă, Radu Cotescu, Sameer Charles - Java implementation and JavaScript Use-API support Cătălin Buzoiu - engineering manager Feike Visser, Florin Iordache - early adopters implementing projects with Sightly, who provided valuable feedback during Sightly's development process [0] - http://docs.adobe.com/content/docs/en/aem/6-0/develop/sightly.html [1] - *https://issues.apache.org/jira/browse/SLING-3959 https://issues.apache.org/jira/browse/SLING-3959* -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [PROPOSAL] Sightly donation to Apache Sling
Hi Justin, Sounds good to me. As I said before, the process of completing the work on the TCK should take me max. 3 weeks. Cheers, Radu On Fri, Sep 26, 2014 at 4:41 PM, Carsten Ziegeler cziege...@apache.org wrote: +1, yepp sounds like a good idea Carsten 2014-09-26 15:31 GMT+02:00 Justin Edelson jus...@justinedelson.com: Thanks Radu. If possible, I would suggest is to start the IP clearance process but that we don't vote on the inclusion until the TCK/spec are ready. On Thu, Sep 25, 2014 at 10:51 AM, Radu Cotescu r...@apache.org wrote: Hi Carsten, I realised that I only half-answered your question. Ideally the TCK should be ready in 2, max. 3 weeks. As soon as we manage to push it to Maven Central it should be ready to be consumed in Sling. In parallel I'm working on a Sling bundle that should contain the TCK input scripts and a content structure that would allow running them as expected by the TCK such that we can test the Sling implementation. HTH, Radu On Tue, Sep 23, 2014 at 10:13 AM, Radu Cotescu r...@apache.org wrote: Hi Carsten, The specification will be available soon on GitHub [2] (matter of days). Until then the resource from [0] should give you an idea on how Sightly expressions look like and what plugins are available. Regards, Radu [2] - https://github.com/Adobe-Marketing-Cloud On Tue, Sep 23, 2014 at 7:07 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi Radu, thanks for the offering. This definitely looks very interesting for Sling. Is the spec downloadable from somewhere? When do you think the test suite will be available? Regards Carsten 2014-09-22 10:59 GMT+02:00 Radu Cotescu r...@apache.org: Hello, On behalf of Adobe Systems Inc. I'd like to contribute two modules to Apache Sling: - org.apache.sling.scripting.sightly - org.apache.sling.xss Sightly is the new web templating language shipped with Adobe Experience Manager 6.0 [0]. Our contribution to Apache Sling is a Java-based implementation, fully compliant with the language's specification. However, the language's specification is and will be owned by Adobe. For Sightly's contextual-based automated XSS escaping feature we're also donating the org.apache.sling.xss bundle that provides two useful services meant to help escaping or filtering user-submitted content that might be prone to XSS attacks. While the XSS module contains a decent amount of unit tests, the Sightly implementation was tested using a proprietary (for now) UI testing framework. I'm currently working on porting those tests into a test runner that will be made available under an Apache License on Maven Central; this runner could easily be integrated into Sightly's build process in the near future. SLING-3959 [1] has been opened to track the donation progress and the bundles are attached there. If the Sling community finds this donation interesting we can carry on with the IP clearance. Thanks, Radu *Sightly Credits:* Senol Tas, Honwai Wong - initial language specification and implementation Gabriel Walt - product manager, language specification Marius Dănilă, Radu Cotescu, Sameer Charles - Java implementation and JavaScript Use-API support Cătălin Buzoiu - engineering manager Feike Visser, Florin Iordache - early adopters implementing projects with Sightly, who provided valuable feedback during Sightly's development process [0] - http://docs.adobe.com/content/docs/en/aem/6-0/develop/sightly.html [1] - *https://issues.apache.org/jira/browse/SLING-3959 https://issues.apache.org/jira/browse/SLING-3959* -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [PROPOSAL] Sightly donation to Apache Sling
Hi Oliver, As Bertrand said in his reply in this thread, we haven't seen much interest in Sightly beyond Sling / AEM users. While there are two plugins that hint at Sling specifics (data-sly-resource / data-sly-include) we actually think that these functionalities exist in various other web frameworks, under different names: * data-sly-resource merely includes a resource from somewhere in your web app * data-sly-include provides a way to render a part of the output with a different view / controller combo in the context of the current request If in the future we see the interest of Sightly increasing outside of the Sling / AEM community we can always start a new project under the ASF umbrella and then provide a bridge for Sling. The specification will be hosted at https://github.com/Adobe-Marketing-Cloud in a few days. BTW, Brackets is an open-source code editor so it has nothing to do with Sightly, except for the fact that we've also developed an extension for it to ease web app development with Sightly in AEM. Cheers, Radu On Sat, Sep 27, 2014 at 3:23 PM, Oliver Lietz apa...@oliverlietz.de wrote: Good to see one more modern alternative to JSP and ESP, welcome Sightly! The open-sourcing is really an important step in the right direction, but I think there are better places for Sightly as template language. Do not tie Sightly to close to Sling (AEM) when it could also be useful for others in different projects and environments and prevent its proliferation unnecessarily. A templating language/engine like Sightly could reach momentum like Angular, Bootstrap, Font Awesome, Markdown or Brackets. Adobe has already some places where they host successful open-source web- related projects, e.g.: http://html.adobe.com/opensource/ https://github.com/adobe https://github.com/adobe-webplatform http://brackets.io http://topcoat.io So +1 for hosting the integration but -1 for hosting the language implementation. Which clearly means +1 for Sightly in general.
Re: [PROPOSAL] Integrate the Validation Framework prototype from SLING-2803 into contrib
Thanks for your support! What's the process of integrating this code into Sling? Is there anyone who could help with this? Does this thread act as a voting thread for integration into contrib? Thanks, Radu On Wed, Sep 24, 2014 at 2:56 PM, Oliver Lietz apa...@oliverlietz.de wrote: On Tuesday 23 September 2014 10:48:26 Radu Cotescu wrote: Hello, I've updated my prototype of the Apache Sling Generic Validation Framework from SLING-2803 [0] in order to implement the features suggested in the issues' comments. If you think that this new API and current implementation would benefit Sling I'd be more than happy to donate this code to Apache Sling and help maintain it in the future. +1 more than happy to have it in Sling O. Thanks, Radu [0] - https://issues.apache.org/jira/browse/SLING-2803
Re: [PROPOSAL] Sightly donation to Apache Sling
Hi, Should we start a voting thread for incorporating Sightly into Sling or would this thread count as one given that the PMC members have already started expressing their view? Also, who could help with the bureaucratic process of managing the donation? Thanks, Radu On Mon, Sep 29, 2014 at 11:58 AM, Radu Cotescu r...@apache.org wrote: Hi Oliver, As Bertrand said in his reply in this thread, we haven't seen much interest in Sightly beyond Sling / AEM users. While there are two plugins that hint at Sling specifics (data-sly-resource / data-sly-include) we actually think that these functionalities exist in various other web frameworks, under different names: * data-sly-resource merely includes a resource from somewhere in your web app * data-sly-include provides a way to render a part of the output with a different view / controller combo in the context of the current request If in the future we see the interest of Sightly increasing outside of the Sling / AEM community we can always start a new project under the ASF umbrella and then provide a bridge for Sling. The specification will be hosted at https://github.com/Adobe-Marketing-Cloud in a few days. BTW, Brackets is an open-source code editor so it has nothing to do with Sightly, except for the fact that we've also developed an extension for it to ease web app development with Sightly in AEM. Cheers, Radu On Sat, Sep 27, 2014 at 3:23 PM, Oliver Lietz apa...@oliverlietz.de wrote: Good to see one more modern alternative to JSP and ESP, welcome Sightly! The open-sourcing is really an important step in the right direction, but I think there are better places for Sightly as template language. Do not tie Sightly to close to Sling (AEM) when it could also be useful for others in different projects and environments and prevent its proliferation unnecessarily. A templating language/engine like Sightly could reach momentum like Angular, Bootstrap, Font Awesome, Markdown or Brackets. Adobe has already some places where they host successful open-source web- related projects, e.g.: http://html.adobe.com/opensource/ https://github.com/adobe https://github.com/adobe-webplatform http://brackets.io http://topcoat.io So +1 for hosting the integration but -1 for hosting the language implementation. Which clearly means +1 for Sightly in general.
Re: [jira] [Created] (SLING-3987) move from Subversion to Git
Hi, I know that I'm just an occasional contributor to Sling and I noticed that this talk is mostly between PMC members. However, here's my big +1 for what Robert proposed. Currently if somebody wants to contribute a new module to Sling they have to build the full project to get a running launchpad, which (assuming that they didn't use -DskipTests) takes a while. Just my €0.02. Cheers, Radu On Thu, Oct 2, 2014 at 4:14 PM, Robert Munteanu romb...@apache.org wrote: Or do we we guarantee that the Launchpad is always buildable outside the reactor by banning SNAPSHOT dependencies
Re: [PROPOSAL] Sightly donation to Apache Sling
Hello Carsten, The official Sightly specification has been published at [2]. The TCK should be ready by the end of next week. Regards, Radu [2] - https://github.com/Adobe-Marketing-Cloud/sightly-spec On Tue, Sep 23, 2014 at 8:07 AM, Carsten Ziegeler cziege...@apache.org wrote: thanks for the offering. This definitely looks very interesting for Sling. Is the spec downloadable from somewhere? When do you think the test suite will be available?
Re: [PROPOSAL] Sightly donation to Apache Sling
Hi, You are right. It leaks implementation details which have not been abstracted enough. I've reformatted that section to provide a more generic description for Use-API objects. Thanks for your feedback! Regards, Radu On Mon, Oct 6, 2014 at 2:00 PM, Carsten Ziegeler cziege...@apache.org wrote: Thanks Radu, I think it's strange that the spec defines something in the Apache Sling namespace (Java Use-API). A spec defined outside of Apache should not define anything in an Apache space. In addition I think for a general purpose templating language this isn't appropriate anyway. Carsten 2014-10-06 12:43 GMT+02:00 Radu Cotescu r...@apache.org: Hello Carsten, The official Sightly specification has been published at [2]. The TCK should be ready by the end of next week. Regards, Radu [2] - https://github.com/Adobe-Marketing-Cloud/sightly-spec On Tue, Sep 23, 2014 at 8:07 AM, Carsten Ziegeler cziege...@apache.org wrote: thanks for the offering. This definitely looks very interesting for Sling. Is the spec downloadable from somewhere? When do you think the test suite will be available? -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [PROPOSAL] Integrate the Validation Framework prototype from SLING-2803 into contrib
Thank you very much, Bertrand! I noticed that there's already an enhancement request - see SLING-4010 [1]. [1] - https://issues.apache.org/jira/browse/SLING-4010 On Tue, Oct 7, 2014 at 6:13 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Wed, Oct 1, 2014 at 3:09 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...Unless someone objects, I'll commit this under contrib tomorrow or Friday... done at http://svn.apache.org/r1629907 and it's not even Friday yet. (ok, ok depends on which Friday ;-) -Bertrand
Re: [jira] [Resolved] (SLING-4010) Allow validator to set a custom failure message
Hi, While I do understand the need for clearer messages about why a validator returns false for a simple validation operation I would not rely on Strings for getting the result. Instead I would return something similar to the ValidationResult - an object encapsulating a boolean value for the result, together with a ListString for retrieving more detailed messages about the Validator's reasons for returning false. WDYT? On Wed, Oct 8, 2014 at 12:14 PM, Bertrand Delacretaz (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/SLING-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-4010. Resolution: Fixed Assignee: Bertrand Delacretaz That was quick! Committed in revision 1630039, thanks for your contribution. Allow validator to set a custom failure message --- Key: SLING-4010 URL: https://issues.apache.org/jira/browse/SLING-4010 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Konrad Windszus Assignee: Bertrand Delacretaz Labels: validation, validator Currently the Validator may only return a boolean value or an exception in case the validator was called with invalid parametrization ( https://github.com/apache/sling/blob/trunk/contrib/validation/api/src/main/java/org/apache/sling/validation/api/Validator.java ). In some cases the validator could give some important information about why the validation failed. This is e.g. the cause for a reference validator where the cause for a failed validation could be: # referenced resource is not existent # referenced resource is not having the right resource type # referenced resource is not activated So instead of only returning a boolean value, it should also be possible to return a failure message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [PROPOSAL] Sightly donation to Apache Sling
Hi Dan, Thank you for your feedback! Please check my inline answers below: On Wed, Oct 8, 2014 at 5:21 PM, Daniel Klco dk...@apache.org wrote: 1. Performance: I found JSP to be roughly 10x faster in contrived tests than Sightly. I've uploaded a package which can be run on an AEM6 instance showing the performance difference between the JSP and Sightly text components here: https://www.danklco.com/assets/Sightly%20Performance%20Test.zip The Sightly foundation components from AEM 6.0 use JavaScript Use-API objects evaluated in Rhino. The Sightly JS Use provider shipped with AEM6.0 suffered from a performance hit due to the fact that Rhino seems to be slower when compiling JS objects than when evaluating them directly. In 6.0 SP1 JS Use-API objects are evaluated, which greatly reduced rendering time for components using JS Use-API objects. On my machine, with SP1, the rendering time ratio is 1:5 in favour of JSPs with your test (these rendering ratios should more or less be the same, irrespective of the CPUs we have, right?!). However some performance gains can be obtained if: 1. the Use-API objects are written in Java (and / or) 2. you configure the Use providers so that they're evaluated in the order which will most likely return a success outcome (e.g. if your Use-API objects are in the JCR repo, then it would make sense for the PojoUseProvider to run first) Now, keep in mind that Sightly is designed with the primary goal of simplifying component development. Obviously, this shouldn't come with a severe performance cost. But simplified component development means that components should be easily implemented by web developers, whose knowledge is more geared towards HTML, CSS and JavaScript. That's one of the reasons there's a JS Use-API - consider it as an enablement feature for the typical web developer. After releasing the TCK I will concentrate my efforts in improving several areas which could offer us a performance gain without requiring manual tuning or Use-objects migration. The end-goal is to have a performance ratio = 1:2. 2. Casting: It's somewhat concerning to me that we don't see more examples of how casting works here. What about Dates? Longs? How would a byte[] be handled? Additionally, the handling of booleans is very concerning. Complicated value coersion rules for boolean logic is one of the worst things in JavaScript in my opinion. At the very least there should be the equivalent of === Sightly is not a strongly typed programming language, it's a web templating language. Since JavaScript is the de-facto scripting language for the web we decided to implement its coercion rules when it comes to casting to boolean. I'll add more examples in the casting section. However, the current implementation handles casting to Strings for primitives and collections. For all objects you can call the toString method in your templates. 3. Extension: Is there an API for adding new statements or options to Sightly? I didn't see this in the spec. Currently we don't support adding new block elements through an API. Options could be added in any implementation without breaking the spec. However I don't think the way options are added to expressions should be part of a specification that aims to be independent of the implementation. These are more implementation-specific details. I'll make sure to document these for Sling. 4. Sling Integration: First, I'd echo the concerns of others that if this is going to be a general-use language, Sling specific integrations should be part of a separate integration package. Also, is there an equivalent of the Sling Resource Access tags in Sightly? What I see this being useful for is basic display logic where some of the properties may not be on the current Resource. For example if you have a structure to represent a carousel like this: ... /carousel /carousel-item-0 /carousel-item-1 /carousel-item-2 Would it be possible to loop through the carousel-item child resources and access their properties? I think the case could be made for creating separate components or having some external logic be executed, I was just wondering if this would be possible. There's no equivalent for Sling Resource Access tags - at the core of a Sightly script is the resource which was accessed. You could iterate over child resources and perform some processing in an Use-object, or, like you suggested, create separate components and include the child resources with data-sly-include. I'm really thankful for your constructive reviews. I think most of the questions will find their answers once we can build a Sling launchpad with Sightly support. Thanks, Radu
Re: [PROPOSAL] Sightly donation to Apache Sling
Hello, I'd like to provide you with an update regarding Sightly as we've just released the Adobe Sightly TCK [3] (also available on Maven Central). Two requirements to integrate Sightly into Sling were: 1. have a published language specification [2] 2. provide some tests to validate the implementation donated to Sling; this is now implemented by integrating [3] into the Sightly build process from the updated org.apache.sling.scripting.sightly.zip archive from SLING-3959 Thanks, Radu [2] - https://github.com/Adobe-Marketing-Cloud/sightly-spec [3] - https://github.com/Adobe-Marketing-Cloud/sightly-tck On Fri, Oct 10, 2014 at 11:49 AM, Gabriel Walt gw...@adobe.com wrote: Hi Daniel, Glad to get your feedback on this DL as you're getting started with Sightly! :) I just wanted to add one small clarification to what Radu said concerning your point 2 (Casting): The Sightly == operator works like the JavaScript == operator, but with the limitation of only accepting variables of the same type. This means that the Sightly == operator corresponds to the common behavior of the JS == and === operators, and where they differ, it currently throws an error. This is the safest to make sure users don't start messing around with types, while staying as close as possible to the JS spec. Best, Gabriel On 08/10/14 16:21, Daniel Klco dk...@apache.org wrote: Hi Radu, I have been metaphorically kicking the tires of Sightly over the last few days and have a few questions / concerns. 1. Performance: I found JSP to be roughly 10x faster in contrived tests than Sightly. I've uploaded a package which can be run on an AEM6 instance showing the performance difference between the JSP and Sightly text components here: https://www.danklco.com/assets/Sightly%20Performance%20Test.zip 2. Casting: It's somewhat concerning to me that we don't see more examples of how casting works here. What about Dates? Longs? How would a byte[] be handled? Additionally, the handling of booleans is very concerning. Complicated value coersion rules for boolean logic is one of the worst things in JavaScript in my opinion. At the very least there should be the equivalent of === 3. Extension: Is there an API for adding new statements or options to Sightly? I didn't see this in the spec. 4. Sling Integration: First, I'd echo the concerns of others that if this is going to be a general-use language, Sling specific integrations should be part of a separate integration package. Also, is there an equivalent of the Sling Resource Access tags in Sightly? What I see this being useful for is basic display logic where some of the properties may not be on the current Resource. For example if you have a structure to represent a carousel like this: ... /carousel /carousel-item-0 /carousel-item-1 /carousel-item-2 Would it be possible to loop through the carousel-item child resources and access their properties? I think the case could be made for creating separate components or having some external logic be executed, I was just wondering if this would be possible. Thanks, Dan On Mon, Oct 6, 2014 at 7:46 AM, Radu Cotescu r...@cotescu.com wrote: Hi, You are right. It leaks implementation details which have not been abstracted enough. I've reformatted that section to provide a more generic description for Use-API objects. Thanks for your feedback! Regards, Radu On Mon, Oct 6, 2014 at 2:00 PM, Carsten Ziegeler cziege...@apache.org wrote: Thanks Radu, I think it's strange that the spec defines something in the Apache Sling namespace (Java Use-API). A spec defined outside of Apache should not define anything in an Apache space. In addition I think for a general purpose templating language this isn't appropriate anyway. Carsten 2014-10-06 12:43 GMT+02:00 Radu Cotescu r...@apache.org: Hello Carsten, The official Sightly specification has been published at [2]. The TCK should be ready by the end of next week. Regards, Radu [2] - https://github.com/Adobe-Marketing-Cloud/sightly-spec On Tue, Sep 23, 2014 at 8:07 AM, Carsten Ziegeler cziege...@apache.org wrote: thanks for the offering. This definitely looks very interesting for Sling. Is the spec downloadable from somewhere? When do you think the test suite will be available? -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [PROPOSAL] Sightly donation to Apache Sling
Hi Oliver, Indeed Adobe hosts multiple open-source projects in various locations. Nevertheless, Adobe is also committed to the projects it started at Apache Software Foundation through Day Software, and also after the acquisition of Day (see Apache DeviceMap, Apache Cordova, Apache Flex, etc.). Given the fact that Sightly was built for AEM and also that some of its language features were built with Sling in mind1) it only makes sense for us to contribute the Java implementation, currently tied to the dynamic classloader from Sling and to the resource and servlets API, to Apache Sling. If we manage to build a community around Sightly itself, and that community would want Sightly to be decoupled from Apache Sling, nothing stops us from creating a Sightly top-level project, as mentioned in the previous emails. Like Robert and Bertrand said in this thread, we're currently trying to build a community for Sightly where it makes most sense now and we believe that this place is Apache Sling, one of the core open-source project on top of which we build AEM. Thanks, Radu 1) see data-sly-resource and data-sly-include; however these concepts, although not named the same, exist in other web frameworks as well: Django, Struts 2 On Thu, Oct 23, 2014 at 4:12 PM, Robert Munteanu romb...@apache.org wrote: On Thu, Oct 23, 2014 at 4:01 PM, Oliver Lietz apa...@oliverlietz.de wrote: On Monday 29 September 2014 10:58:05 Radu Cotescu wrote: Hi Oliver, Hi Radu, As Bertrand said in his reply in this thread, we haven't seen much interest in Sightly beyond Sling / AEM users. While there are two plugins that hint at Sling specifics (data-sly-resource / data-sly-include) we actually think that these functionalities exist in various other web frameworks, under different names: * data-sly-resource merely includes a resource from somewhere in your web app * data-sly-include provides a way to render a part of the output with a different view / controller combo in the context of the current request If in the future we see the interest of Sightly increasing outside of the Sling / AEM community we can always start a new project under the ASF umbrella and then provide a bridge for Sling. Let me rephrase and expand on that a little bit, but through my perception rather than Radu's. This will also be an exercise in community-building. I believe that it's easier to focus attention of developers in both the consumer and contributor role to Sling and Sightly by putting them under the same umbrella rather than by keeping them apart. Once Sightly attracts enough attention it can move to another location if that's beneficial to the project. But I don't think that a scripting language tied deeply as an implementation to Sling and JCR should live outside Sling from the beginning. Well, maybe someone will be interested enough to decouple Sightly from JCR and from Sling and make it usable as a standalone project. But for that we need contributors ( see my second paragraph :-) ). So IMO the best location for Sightly is Sling and we should accept the donation as it was made. Cheers, Robert The specification will be hosted at https://github.com/Adobe-Marketing-Cloud in a few days. BTW, Brackets is an open-source code editor so it has nothing to do with Sightly, except for the fact that we've also developed an extension for it to ease web app development with Sightly in AEM. sure, Brackets and Topcoat are just examples for Adobe hosting open source web projects on top level. Regards, O. Cheers, Radu On Sat, Sep 27, 2014 at 3:23 PM, Oliver Lietz apa...@oliverlietz.de wrote: Good to see one more modern alternative to JSP and ESP, welcome Sightly! The open-sourcing is really an important step in the right direction, but I think there are better places for Sightly as template language. Do not tie Sightly to close to Sling (AEM) when it could also be useful for others in different projects and environments and prevent its proliferation unnecessarily. A templating language/engine like Sightly could reach momentum like Angular, Bootstrap, Font Awesome, Markdown or Brackets. Adobe has already some places where they host successful open-source web- related projects, e.g.: http://html.adobe.com/opensource/ https://github.com/adobe https://github.com/adobe-webplatform http://brackets.io http://topcoat.io So +1 for hosting the integration but -1 for hosting the language implementation. Which clearly means +1 for Sightly in general.
Re: [Sightly] API vs. Implementation
Hi Felix, The API reorganisation looks good to me. On Wed, Nov 19, 2014 at 10:49 PM, Felix Meschberger fmesc...@adobe.com wrote: Apart from splitting the base .api package, this are further discussions: * Exceptions are forming a hierarchy with SightlyEngineException being the root and itself extending from SlingException Sure, it makes sense. * I wonder, whether we should really drop the *Component abstract classes (RuntimeExtensionComponent and UseProviderComponent). I don’t think they provide real value at all but have an activate method, which they expect to be called and which they expect to be a DS component annotated with the Felix annotations. I think this is brittle. The abstract classes were written specifically for that activate method, in order to avoid writing those lines of code for every implementation. * UseProvider defines an ordering method and declares itself being Comparable. I think this is wrong. The UseProviders should be sorted using regular OSGi service ranking. If we make the service.ranking property configurable (metatype = true) I guess we could use the OSGi ranking. Theoretically the Use providers can be configured to be called in a pre-determined order, depending on how the Sightly projects from an instance make use of the Use-API (Java Use-API objects deployed in bundles / Java Use objects near the component script in the repo / JS Use-API, etc.). Having the Use providers called in the most favourable way can increase performance for Sightly applications. * I wonder, whether we really have to have all this API exported at all: Some API I don’t see implemented at all (e.g. BaseRenderUnit — or is that the base class for the Java classes generated from the Sightly templates ?) The BaseRenderUnit is indeed the base class for classes generated from Sightly scripts, which is why we need to export the other classes as well. In this regard Sightly is no different from the JSP engine. * Last but not least (actually most important of all): There is close to no JavaDoc. Before cutting a release of this bundle, JavaDoc must be provided for the API. For example I am not sure, what the Record or the ObjectModel interfaces are really used for. It's on my TODO list. Thanks, Radu
Re: [Sightly] API vs. Implementation
Hi Felix, I pushed all the required changes to the forked repo. Things left to do: * check what we actually need to export for preventing class loading problems * expand JavaDoc At this point I think that we can create a patch with our changes and apply it to trunk. Cheers, Radu On Thu, Nov 20, 2014 at 6:53 PM, Felix Meschberger fmesc...@adobe.com wrote: Hi Thanks for your reply. For those interested in following, Radu and I are cooperating on these changes in my GitHub fork at https://github.com/fmeschbe/sling Am 19.11.2014 um 22:53 schrieb Radu Cotescu r...@cotescu.com: Hi Felix, The API reorganisation looks good to me. On Wed, Nov 19, 2014 at 10:49 PM, Felix Meschberger fmesc...@adobe.com wrote: Apart from splitting the base .api package, this are further discussions: * Exceptions are forming a hierarchy with SightlyEngineException being the root and itself extending from SlingException Sure, it makes sense. Done in the fork. The „root“ exception for Sightly is not SightlyException (SightlyEngineException renamed to SightlyException). * I wonder, whether we should really drop the *Component abstract classes (RuntimeExtensionComponent and UseProviderComponent). I don’t think they provide real value at all but have an activate method, which they expect to be called and which they expect to be a DS component annotated with the Felix annotations. I think this is brittle. The abstract classes were written specifically for that activate method, in order to avoid writing those lines of code for every implementation. We are working on removing these abstract classes by leveraging service properties for * UseProvider ranking (service.ranking) * ExtensionProvider naming * UseProvider defines an ordering method and declares itself being Comparable. I think this is wrong. The UseProviders should be sorted using regular OSGi service ranking. If we make the service.ranking property configurable (metatype = true) I guess we could use the OSGi ranking. Theoretically the Use providers can be configured to be called in a pre-determined order, depending on how the Sightly projects from an instance make use of the Use-API (Java Use-API objects deployed in bundles / Java Use objects near the component script in the repo / JS Use-API, etc.). Having the Use providers called in the most favourable way can increase performance for Sightly applications. Yes, the service.ranking property can be added to metatype for configurable ranking. * I wonder, whether we really have to have all this API exported at all: Some API I don’t see implemented at all (e.g. BaseRenderUnit — or is that the base class for the Java classes generated from the Sightly templates ?) The BaseRenderUnit is indeed the base class for classes generated from Sightly scripts, which is why we need to export the other classes as well. In this regard Sightly is no different from the JSP engine. Ok. We’d have to test this more. But I suspect we don’t really need to export the BaseRenderUnit abstract class. IIRC the reason for exporting the base JSP servlet is that other classes in the same package must be exported. * Last but not least (actually most important of all): There is close to no JavaDoc. Before cutting a release of this bundle, JavaDoc must be provided for the API. For example I am not sure, what the Record or the ObjectModel interfaces are really used for. It's on my TODO list. Cool. Thanks. Regards Felix
Re: [Sightly] API vs. Implementation
Hi Felix, I've pushed some new changes: BaseRenderUnit is now a part of impl. RenderContext should indeed become an interface. Also, I think that we can get rid of the UnitLocator interface, therefore reducing the size of the exported API to the bare minimum. Thanks, Radu On Mon, Nov 24, 2014 at 12:36 PM, Felix Meschberger fmesc...@adobe.com wrote: Hi Radu Am 21.11.2014 um 18:39 schrieb Radu Cotescu r...@apache.org: Hi Felix, I pushed all the required changes to the forked repo. Things left to do: * check what we actually need to export for preventing class loading problems Excellent. I would prefer to really not export most of the RenderUnit stuff incl. BaseRenderUnit and RenderContext. At one point I had a change, where I actually had RenderContext as an interface with a subset of the API, basically just getWriter (does that need to be a StackedWriter after all ?) and a RenderContextImpl which had all the rest but was internal. * expand JavaDoc At this point I think that we can create a patch with our changes and apply it to trunk. We might want to continue on the fork to find the classes that we really want/need to export. Because this may cause further shuffling of packages etc. Thanks Felix Cheers, Radu On Thu, Nov 20, 2014 at 6:53 PM, Felix Meschberger fmesc...@adobe.com wrote: Hi Thanks for your reply. For those interested in following, Radu and I are cooperating on these changes in my GitHub fork at https://github.com/fmeschbe/sling Am 19.11.2014 um 22:53 schrieb Radu Cotescu r...@cotescu.com: Hi Felix, The API reorganisation looks good to me. On Wed, Nov 19, 2014 at 10:49 PM, Felix Meschberger fmesc...@adobe.com wrote: Apart from splitting the base .api package, this are further discussions: * Exceptions are forming a hierarchy with SightlyEngineException being the root and itself extending from SlingException Sure, it makes sense. Done in the fork. The „root“ exception for Sightly is not SightlyException (SightlyEngineException renamed to SightlyException). * I wonder, whether we should really drop the *Component abstract classes (RuntimeExtensionComponent and UseProviderComponent). I don’t think they provide real value at all but have an activate method, which they expect to be called and which they expect to be a DS component annotated with the Felix annotations. I think this is brittle. The abstract classes were written specifically for that activate method, in order to avoid writing those lines of code for every implementation. We are working on removing these abstract classes by leveraging service properties for * UseProvider ranking (service.ranking) * ExtensionProvider naming * UseProvider defines an ordering method and declares itself being Comparable. I think this is wrong. The UseProviders should be sorted using regular OSGi service ranking. If we make the service.ranking property configurable (metatype = true) I guess we could use the OSGi ranking. Theoretically the Use providers can be configured to be called in a pre-determined order, depending on how the Sightly projects from an instance make use of the Use-API (Java Use-API objects deployed in bundles / Java Use objects near the component script in the repo / JS Use-API, etc.). Having the Use providers called in the most favourable way can increase performance for Sightly applications. Yes, the service.ranking property can be added to metatype for configurable ranking. * I wonder, whether we really have to have all this API exported at all: Some API I don’t see implemented at all (e.g. BaseRenderUnit — or is that the base class for the Java classes generated from the Sightly templates ?) The BaseRenderUnit is indeed the base class for classes generated from Sightly scripts, which is why we need to export the other classes as well. In this regard Sightly is no different from the JSP engine. Ok. We’d have to test this more. But I suspect we don’t really need to export the BaseRenderUnit abstract class. IIRC the reason for exporting the base JSP servlet is that other classes in the same package must be exported. * Last but not least (actually most important of all): There is close to no JavaDoc. Before cutting a release of this bundle, JavaDoc must be provided for the API. For example I am not sure, what the Record or the ObjectModel interfaces are really used for. It's on my TODO list. Cool. Thanks. Regards Felix
Re: [Sightly] API vs. Implementation
Hi Felix, The API refactoring should now be completed - I've refactored the RenderContext as well and there's no UnitLocator anymore (its usage was restricted to only the RenderUnitProvider which can locate units by itself). We can review the changes before deciding to merge them to Sling trunk if you think that we might improve some other areas. Regards, Radu On Tue, Nov 25, 2014 at 12:05 AM, Radu Cotescu r...@apache.org wrote: Hi Felix, I've pushed some new changes: BaseRenderUnit is now a part of impl. RenderContext should indeed become an interface. Also, I think that we can get rid of the UnitLocator interface, therefore reducing the size of the exported API to the bare minimum. Thanks, Radu On Mon, Nov 24, 2014 at 12:36 PM, Felix Meschberger fmesc...@adobe.com wrote: Hi Radu Am 21.11.2014 um 18:39 schrieb Radu Cotescu r...@apache.org: Hi Felix, I pushed all the required changes to the forked repo. Things left to do: * check what we actually need to export for preventing class loading problems Excellent. I would prefer to really not export most of the RenderUnit stuff incl. BaseRenderUnit and RenderContext. At one point I had a change, where I actually had RenderContext as an interface with a subset of the API, basically just getWriter (does that need to be a StackedWriter after all ?) and a RenderContextImpl which had all the rest but was internal. * expand JavaDoc At this point I think that we can create a patch with our changes and apply it to trunk. We might want to continue on the fork to find the classes that we really want/need to export. Because this may cause further shuffling of packages etc. Thanks Felix Cheers, Radu On Thu, Nov 20, 2014 at 6:53 PM, Felix Meschberger fmesc...@adobe.com wrote: Hi Thanks for your reply. For those interested in following, Radu and I are cooperating on these changes in my GitHub fork at https://github.com/fmeschbe/sling Am 19.11.2014 um 22:53 schrieb Radu Cotescu r...@cotescu.com: Hi Felix, The API reorganisation looks good to me. On Wed, Nov 19, 2014 at 10:49 PM, Felix Meschberger fmesc...@adobe.com wrote: Apart from splitting the base .api package, this are further discussions: * Exceptions are forming a hierarchy with SightlyEngineException being the root and itself extending from SlingException Sure, it makes sense. Done in the fork. The „root“ exception for Sightly is not SightlyException (SightlyEngineException renamed to SightlyException). * I wonder, whether we should really drop the *Component abstract classes (RuntimeExtensionComponent and UseProviderComponent). I don’t think they provide real value at all but have an activate method, which they expect to be called and which they expect to be a DS component annotated with the Felix annotations. I think this is brittle. The abstract classes were written specifically for that activate method, in order to avoid writing those lines of code for every implementation. We are working on removing these abstract classes by leveraging service properties for * UseProvider ranking (service.ranking) * ExtensionProvider naming * UseProvider defines an ordering method and declares itself being Comparable. I think this is wrong. The UseProviders should be sorted using regular OSGi service ranking. If we make the service.ranking property configurable (metatype = true) I guess we could use the OSGi ranking. Theoretically the Use providers can be configured to be called in a pre-determined order, depending on how the Sightly projects from an instance make use of the Use-API (Java Use-API objects deployed in bundles / Java Use objects near the component script in the repo / JS Use-API, etc.). Having the Use providers called in the most favourable way can increase performance for Sightly applications. Yes, the service.ranking property can be added to metatype for configurable ranking. * I wonder, whether we really have to have all this API exported at all: Some API I don’t see implemented at all (e.g. BaseRenderUnit — or is that the base class for the Java classes generated from the Sightly templates ?) The BaseRenderUnit is indeed the base class for classes generated from Sightly scripts, which is why we need to export the other classes as well. In this regard Sightly is no different from the JSP engine. Ok. We’d have to test this more. But I suspect we don’t really need to export the BaseRenderUnit abstract class. IIRC the reason for exporting the base JSP servlet is that other classes in the same package must be exported. * Last but not least (actually most important of all): There is close to no JavaDoc. Before cutting a release of this bundle, JavaDoc must be provided for the API. For example I am not sure, what the Record
[Sightly] provide access to the Script Resource Resolver in RenderContext
Hi, There are cases when Sightly RuntimeExtensions might need to access the repository. Since creating multiple ResourceResolvers is not a cheap operation, especially with Jackrabbit, wouldn't it be better to enhance the RenderContext to make it provide the ResourceResolver available in the ScriptContext? This ResourceResolver is already used by the Sightly engine for script rendering, so IMO it could also be passed down to RuntimeExtensions: final ResourceResolver scriptResourceResolver = (ResourceResolver) scriptContext.getAttribute(SlingScriptConstants.ATTR_SCRIPT_RESOURCE_RESOLVER, SlingScriptConstants.SLING_SCOPE); // line 78 of org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine WDYT? Cheers, Radu
Re: [SLING-4275] API: RuntimeExtension and ExtensionInstance
Hi, I've created https://issues.apache.org/jira/browse/SLING-4313 to address this. Regards, Radu On Mon, Jan 12, 2015 at 8:09 PM, Radu Cotescu r...@apache.org wrote: Hi, I think we could get rid of the ExtensionInstance objects and modify the RuntimeExtension API: * remove the provide method * create a call method: Object call(RenderContext renderContext, Object ... arguments) Cheers, Radu On Mon, Jan 12, 2015 at 11:44 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi all Carsten started to review the Sightly Engine API in SLING-4275 [1]. Since this issue covers 4 topics, I think it would be best to quickly discuss these topic in separate threads. #2 RuntimeExtension and ExtensionInstance Currently the RuntimeExtension is a service and called to return an ExtensionInstance. For each evaluation of a Sightly Template an ExtensionInstance is created. The downside of this is a double indirection: Not the RuntimeExtension itself is used. Rather the RuntimeExtension is a factory of ExtensionInstance objects. The upside is that these ExtensionInstances can hold instance data for the duration of the Sightly template evaluation. Question is whether there actually is a use case for such instance data, which could not be held in bindings and whether it would be possible for RuntimeExtensions to implement such instance data in different ways. WDYT ? Regards Felix [1] https://issues.apache.org/jira/browse/SLING-4275
Re: Sightly Integration Test execution fails for me
Hi Konrad, The code does indeed rely on the default platform encoding. However, on my Mac, the default encoding is UTF-8. mvn -version Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T09:29:23-08:00) Maven home: /usr/local/Cellar/maven/3.2.5/libexec Java version: 1.7.0_67, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: mac os x, version: 10.10.2, arch: x86_64, family: mac Is the encoding different on your box? Regards, Radu On Thu, Feb 19, 2015 at 4:13 AM, Konrad Windszus konra...@gmx.de wrote: I just tried to execute the Sightly Integration Tests and I get the following error: ... Tests run: 336, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.994 sec FAILURE! - in io.sightly.tck.TestsRunner String Expressions: String quotes and escaping - #unicode_escape(io.sightly.tck.tests.TestBuilder$1) Time elapsed: 0.007 sec FAILURE! junit.framework.AssertionFailedError: Expected value 'This 'Atilde;' is a string with unicode escaping' for selector '#unicode_escape'. Instead we got 'This '??' is a string with unicode escaping'. Please check the expected markup from /testfiles/output/exprlang/strings.html. at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at io.sightly.tck.tests.TestBuilder$1.runTest(TestBuilder.java:146) Results : Failed tests: TestBuilder$1.runTest:146 Expected value 'This 'Atilde;' is a string with unicode escaping' for selector '#unicode_escape'. Instead we got 'This '??' is a string with unicode escaping'. Please check the expected markup from /testfiles/output/exprlang/strings.html. Tests run: 340, Failures: 1, Errors: 0, Skipped: 0 ... This happens with the most recent trunk and I just recompiled the XSS module on my own before that. I am using JDK 1.7.0_55 on a Mac. Any ideas what might be wrong? Is the code relying on the default encoding maybe? Thanks, Konrad
Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 1:59 PM, Oliver Lietz apa...@oliverlietz.de wrote: Whatever the approach is, if we want to allow multiple scripting engines to use the same extension we need to refactor the code from the SlingScriptEngineManager. Why? The ScriptEngine itself can decide if it kicks in for a script based on the paths patterns. Because currently the script engines are just template processors. The SlingServletResolver is the component that maps a request to the script engine that will provide the output, with the help of the SlingScriptAdapterFactory and the SlingScriptEngineManager.
Re: Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 1:15 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Good point - we can consider that notation say anywhere in the first 200 chars of the script, so ?xml version=1.0 encoding=UTF-8? !-- sling:language: thymeleaf -- foo/ would work, the pattern being sling:language followed by whitespace and one word which is the language name. This has the disadvantage that the Servlet Resolver would have to parse the first n characters of the script and then the Script Engine would parse again the whole file. We should not increase the number of resource reads, if not really needed. If we want to have a conflict resolution mechanism we could add a property on component nodes (but they must be sling:Folder / nt:unstructured) that would handle which of the multiple scripting engines registered for the same extension should be used: sling:script - html:thymeleaf This would essentially say that for the *.html scripts for this component, Thymeleaf should be used. However, this adds an unnecessary step for component developers. I think the configurable patterns on the ScriptEngineFactories is simpler, as this is essentially a deployment issue. Whatever the approach is, if we want to allow multiple scripting engines to use the same extension we need to refactor the code from the SlingScriptEngineManager.
Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 2:08 PM, Robert Munteanu rob...@lmn.ro wrote: If we configure various ScriptEngine implementations it becomes harder to get an overview of what it configured where. It's even possible to have conflicting patterns in two scripting engines. We could have a master component that provides the needed configuration for all engines, simplifying the configuration issue you mentioned.
Re: Use Provide-Capability for the org.apache.sling.scripting.sightly bundle
Hi Bertrand, I also had a look at the other thread but I think that for the Sightly bundle we should aim to offer a vendor independent capability name, in case somebody else would like to provide the same capability from a bundle not related to Apache Sling. Would this be too far-fetched? Thanks, Radu On Tue, Jan 27, 2015 at 6:39 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jan 27, 2015 at 5:35 PM, Radu Cotescu r...@apache.org wrote: ...Should the value of this header be different?... I saw SLING-4358 fly by and just started a thread here about defining a Sling standard for those values. -Bertrand
Use Provide-Capability for the org.apache.sling.scripting.sightly bundle
Hi, Given the recent update [0] of the Sightly language specification I'm tempted to use the Provide-Capability OSGi header [1] for the org.apache.sling.scripting.sightly bundle to provide information about which specification version is actually implemented: Provide-Capability: io.sightly; version=1.1 Do you think this would be a good idea? Should the value of this header be different? Thanks, Radu [0] - https://github.com/Adobe-Marketing-Cloud/sightly-spec/blob/1.1/SPECIFICATION.md [1] - http://wiki.osgi.org/wiki/Provide-Capability
Re: [SLING-4275] API: RenderContext Object Traversal
Hi, We could extract those methods into a utility class. Cheers, Radu On Mon, Jan 12, 2015 at 1:45 PM, Carsten Ziegeler cziege...@apache.org wrote: Am 12.01.15 um 10:44 schrieb Felix Meschberger: Hi all Carsten started to review the Sightly Engine API in SLING-4275 [1]. Since this issue covers 4 topics, I think it would be best to quickly discuss these topic in separate threads. #4 RenderContext Object Traversal The Sightly Engine provides functionality for extensions to transparently travers object hierarchies to implement Sightly Expressions. The methods to do so are currently exposed in the RenderContext object which is created for each evaluation of a Sightly Template/Script. Question is whether we should expose this traversal functionality as a service. As such this traversal would be „globally applicable“ and could not be adapted to each call. Also extensions would have another reference to a service. We also have the option to make an utility class out of it. I think this stuff has general purpose and the RenderContext class itself is not really the right place for it. The least we should do is move this to a separate interface and have a getXYZ method in the RenderContext to avoid bloating of that RenderContext interface with utility stuff. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [SLING-4275] API: ResourceResolution helper
Hi, The ResourceResolution class provides helper methods for resource resolution which are not available directly from the ResourceResolver / ResourceUtil classes. The most important one, albeit named poorly, is org.apache.sling.scripting.sightly.ResourceResolution#resolveComponentRelative, which handles resource inheritance chains. I would argue that their use is more general than just scripting and that the Sling API would be the correct place for them. However, I also don't like the fact that we'd have to depend on a newer Sling API version in Sightly. Regards, Radu On Mon, Jan 12, 2015 at 1:43 PM, Carsten Ziegeler cziege...@apache.org wrote: Am 12.01.15 um 10:44 schrieb Felix Meschberger: Hi all Carsten started to review the Sightly Engine API in SLING-4275 [1]. Since this issue covers 4 topics, I think it would be best to quickly discuss these topic in separate threads. #5 ResourceResolution helper The ResourceResolution helper kind of duplicates and/or extends functionality attributable to Script and Servlet Resolution. The question is whether we want to move this API to the Sling API at the expense of increasing the respective API package version and thus requiring an update to other bundles just to cope with this extended methods … (This actually blends into another discussion we should be having on the evolution of the Sling API itself: Whenever we update something in the Sling API, it has a potential dramatic ripple-down effect to other bundles. Lets not discuss this here and now, though) If this API is of general (scripting) use, we should put it into a common place; if it's just for scripting we have the scripting api; if it's more general, I think Sling API is the place. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [SLING-4275] API: Record Interface
Hi, We could do this, but in this case I'd suggest to go for something like: T getValueForProperty(String propertyName) instead of T get(String name) SetString getPropertyNames() instead of SetString properties() WDYT? Radu On Tue, Jan 13, 2015 at 12:49 PM, Carsten Ziegeler cziege...@apache.org wrote: Can we at least rename the properties() method to getPropertyNames() Carsten Am 12.01.15 um 18:55 schrieb Radu Cotescu: Hi, The Record interface is more complex. Besides being used in the JS Use Provider code for injecting global objects to the current bindings, the interface is also used to allow Sightly templates (defined through data-sly-template) to contain other templates (imbricated data-sly-template block elements). Since Sightly templates are loaded through the Use API (e.g. div data-sly-use.tmplLibrary=/apps/myproj/components/templates.html...), templates become objects in a Sightly script. Templates embedded in another template become properties of the main template object. The Record interface provides this flexibility. HTH, Radu On Mon, Jan 12, 2015 at 11:44 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi all Carsten started to review the Sightly Engine API in SLING-4275 [1]. Since this issue covers 4 topics, I think it would be best to quickly discuss these topic in separate threads. #3 Record Interface The Record interface is used primarily by the Java POJO UseProvider to inject properties back into the Sightly template bindings: If the object loaded by the provider happens to implement the Record interface, the respective properties are injected into the current bindings. The Question is whether this interface is specific to the Java POJO UseProvider or not ? If it is specific, it should probably be moved into a pojo sub package. WDYT ? Regards Felix [1] https://issues.apache.org/jira/browse/SLING-4275 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [SLING-4275] API: ResourceResolution helper
Sure. I created https://issues.apache.org/jira/browse/SLING-4304. On Tue, Jan 13, 2015 at 12:56 PM, Carsten Ziegeler cziege...@apache.org wrote: Alright, so what about doing the renaming/javadoc update first and then see where to put it?
Re: [SLING-4275] API: RenderContext Object Traversal
However, I just realised that those methods need to be accessible outside of the o.a.s.s.sightly bundle for people who implement RuntimeExtensions. On Tue, Jan 13, 2015 at 12:54 PM, Carsten Ziegeler cziege...@apache.org wrote: Am 13.01.15 um 10:03 schrieb Radu Cotescu: Hi, We could extract those methods into a utility class. I would prefer that, but on the other hand if its just me... :) Carsten Cheers, Radu On Mon, Jan 12, 2015 at 1:45 PM, Carsten Ziegeler cziege...@apache.org wrote: Am 12.01.15 um 10:44 schrieb Felix Meschberger: Hi all Carsten started to review the Sightly Engine API in SLING-4275 [1]. Since this issue covers 4 topics, I think it would be best to quickly discuss these topic in separate threads. #4 RenderContext Object Traversal The Sightly Engine provides functionality for extensions to transparently travers object hierarchies to implement Sightly Expressions. The methods to do so are currently exposed in the RenderContext object which is created for each evaluation of a Sightly Template/Script. Question is whether we should expose this traversal functionality as a service. As such this traversal would be „globally applicable“ and could not be adapted to each call. Also extensions would have another reference to a service. We also have the option to make an utility class out of it. I think this stuff has general purpose and the RenderContext class itself is not really the right place for it. The least we should do is move this to a separate interface and have a getXYZ method in the RenderContext to avoid bloating of that RenderContext interface with utility stuff. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [SLING-4275] API: RuntimeExtension and ExtensionInstance
Hi, I think we could get rid of the ExtensionInstance objects and modify the RuntimeExtension API: * remove the provide method * create a call method: Object call(RenderContext renderContext, Object ... arguments) Cheers, Radu On Mon, Jan 12, 2015 at 11:44 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi all Carsten started to review the Sightly Engine API in SLING-4275 [1]. Since this issue covers 4 topics, I think it would be best to quickly discuss these topic in separate threads. #2 RuntimeExtension and ExtensionInstance Currently the RuntimeExtension is a service and called to return an ExtensionInstance. For each evaluation of a Sightly Template an ExtensionInstance is created. The downside of this is a double indirection: Not the RuntimeExtension itself is used. Rather the RuntimeExtension is a factory of ExtensionInstance objects. The upside is that these ExtensionInstances can hold instance data for the duration of the Sightly template evaluation. Question is whether there actually is a use case for such instance data, which could not be held in bindings and whether it would be possible for RuntimeExtensions to implement such instance data in different ways. WDYT ? Regards Felix [1] https://issues.apache.org/jira/browse/SLING-4275
Re: cannot commit to Sling repo
For debugging purposes this is what I see in my local clone: svn info Path: . Working Copy Root Path: /Users/radu/sling URL: https://svn.apache.org/repos/asf/sling/trunk Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1658678 Node Kind: directory Schedule: normal Last Changed Author: stefanegli Last Changed Rev: 1658661 Last Changed Date: 2015-02-10 12:42:27 +0200 (Tue, 10 Feb 2015) On Tue, Feb 10, 2015 at 1:22 PM, Radu Cotescu r...@apache.org wrote: Hi, Apparently I cannot commit anything to the Sling repo: svn ci Sending extensions/xss/src/main/java/org/apache/sling/xss/impl/XSSAPIImpl.java Sending extensions/xss/src/test/java/org/apache/sling/xss/impl/XSSAPIImplTest.java Transmitting file data .svn: E195023: Commit failed (details follow): svn: E195023: Changing file '/Users/radu/sling/contrib/extensions/xss/src/test/java/org/apache/sling/xss/impl/XSSAPIImplTest.java' is forbidden by the server svn: E175013: Access to '/repos/asf/!svn/txr/1658677-10d77/sling/trunk/contrib/extensions/xss/src/test/java/org/apache/sling/xss/impl/XSSAPIImplTest.java' forbidden svn: E195023: Your commit message was left in a temporary file: svn: E195023:'/Users/radu/sling/svn-commit.2.tmp' Can someone please check if my user is added to the correct groups? Thanks, Radu
cannot commit to Sling repo
Hi, Apparently I cannot commit anything to the Sling repo: svn ci Sending extensions/xss/src/main/java/org/apache/sling/xss/impl/XSSAPIImpl.java Sending extensions/xss/src/test/java/org/apache/sling/xss/impl/XSSAPIImplTest.java Transmitting file data .svn: E195023: Commit failed (details follow): svn: E195023: Changing file '/Users/radu/sling/contrib/extensions/xss/src/test/java/org/apache/sling/xss/impl/XSSAPIImplTest.java' is forbidden by the server svn: E175013: Access to '/repos/asf/!svn/txr/1658677-10d77/sling/trunk/contrib/extensions/xss/src/test/java/org/apache/sling/xss/impl/XSSAPIImplTest.java' forbidden svn: E195023: Your commit message was left in a temporary file: svn: E195023:'/Users/radu/sling/svn-commit.2.tmp' Can someone please check if my user is added to the correct groups? Thanks, Radu
Re: cannot commit to Sling repo
Hi, I've logged https://issues.apache.org/jira/browse/INFRA-9154 for this - apparently it's an LDAP issue. Until then I might bug one of the committers to apply my patches for the issues I'm working on. Thanks, Radu On Tue, Feb 10, 2015 at 1:24 PM, Radu Cotescu r...@apache.org wrote: For debugging purposes this is what I see in my local clone: svn info Path: . Working Copy Root Path: /Users/radu/sling URL: https://svn.apache.org/repos/asf/sling/trunk Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1658678 Node Kind: directory Schedule: normal Last Changed Author: stefanegli Last Changed Rev: 1658661 Last Changed Date: 2015-02-10 12:42:27 +0200 (Tue, 10 Feb 2015) On Tue, Feb 10, 2015 at 1:22 PM, Radu Cotescu r...@apache.org wrote: Hi, Apparently I cannot commit anything to the Sling repo: svn ci Sending extensions/xss/src/main/java/org/apache/sling/xss/impl/XSSAPIImpl.java Sending extensions/xss/src/test/java/org/apache/sling/xss/impl/XSSAPIImplTest.java Transmitting file data .svn: E195023: Commit failed (details follow): svn: E195023: Changing file '/Users/radu/sling/contrib/extensions/xss/src/test/java/org/apache/sling/xss/impl/XSSAPIImplTest.java' is forbidden by the server svn: E175013: Access to '/repos/asf/!svn/txr/1658677-10d77/sling/trunk/contrib/extensions/xss/src/test/java/org/apache/sling/xss/impl/XSSAPIImplTest.java' forbidden svn: E195023: Your commit message was left in a temporary file: svn: E195023:'/Users/radu/sling/svn-commit.2.tmp' Can someone please check if my user is added to the correct groups? Thanks, Radu
Re: Please welcome Radu Costescu as a Sling committer
Hello, Thank you for the warm welcome! I became familiar with Sling after I had joined the CQ team @Adobe in 2012. Since then I've started to appreciate its simplicity and ease of use and started to gradually contribute functionality through the validation API, the Sightly Java implementation and the XSS API. Although new to the Sling project, I'm also a committer and PMC member of the recently graduated Apache DeviceMap project [0]. I'm looking forward to officially start working on Sling. Regards, Radu [0] - http://devicemap.apache.org/
[VOTE] Release Apache Sling XSS Protection Bundle version 1.0.0
Hi, We solved 8 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12329024/ There are still some outstanding issues: http://s.apache.org/sling_xss_1.0.2 Staging repository: *https://repository.apache.org/content/repositories/orgapachesling-1213 https://repository.apache.org/content/repositories/orgapachesling-1213* You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1213 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu
Re: [VOTE] Release Apache Sling XSS Protection Bundle version 1.0.0
Hi Robert, Those are outstanding issues for the XSS module which will be addressed with 1.0.2. We're currently voting for 1.0.0. Cheers, Radu On Mon, Mar 16, 2015 at 2:02 PM, Robert Munteanu romb...@apache.org wrote: On Mon, 2015-03-16 at 13:33 +0200, Radu Cotescu wrote: There are still some outstanding issues: http://s.apache.org/sling_xss_1.0.2 Is this the right link? We're voting on 1.0.0 Robert
[VOTE CANCELLED] Release Apache Sling XSS Protection Bundle version 1.0.0
Cancelling this thread in order to start a clean one. :) Cheers, Radu On Tue, Mar 10, 2015 at 6:01 PM, Radu Cotescu r...@apache.org wrote: I'll re-release version 1.0.0 once SLING-4492 [0] is fixed. Sorry for the noise. Cheers, Radu [0] - https://issues.apache.org/jira/browse/SLING-4492 On Tue, Mar 10, 2015 at 2:26 PM, Radu Cotescu r...@apache.org wrote: Hi, I have updated the apache rat plugin configuration for the XSS module and I've restaged the release. Staging repository: *https://repository.apache.org/content/repositories/orgapachesling-1209 https://repository.apache.org/content/repositories/orgapachesling-1209* You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1209 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu
Re: [VOTE] Release Apache Sling XSS Protection Bundle version 1.0.0
Hi Daniel, The launchpad needs to provide that missing dependency: bundle groupIdjavax.mail/groupId artifactIdmail/artifactId version1.4.7/version startLevel20/startLevel /bundle Cheers, Radu On Mon, Mar 16, 2015 at 7:18 PM, Daniel Klco dk...@apache.org wrote: When I install the bundle into a vanilla Sling 7 instance, I get a missing dependency: javax.mail.internet -- Cannot be resolved Is this just a bundle not included in the released Sling 7 or is this a missing dependency? On Mon, Mar 16, 2015 at 10:24 AM, Robert Munteanu rob...@lmn.ro wrote: On Mon, Mar 16, 2015 at 4:17 PM, Radu Cotescu r...@apache.org wrote: Hi Robert, Those are outstanding issues for the XSS module which will be addressed with 1.0.2. We're currently voting for 1.0.0. You're right, of course. Sorry for the noise. Robert Cheers, Radu On Mon, Mar 16, 2015 at 2:02 PM, Robert Munteanu romb...@apache.org wrote: On Mon, 2015-03-16 at 13:33 +0200, Radu Cotescu wrote: There are still some outstanding issues: http://s.apache.org/sling_xss_1.0.2 Is this the right link? We're voting on 1.0.0 Robert -- Sent from my (old) computer
[RESULT] [VOTE] Release Apache Sling XSS Protection Bundle version 1.0.0
Hi, The vote has passed with the following result : +1 (binding): Bertrand Delacretaz, Robert Munteanu, Carsten Ziegeler I will copy this release to the Sling dist directory (if my account allows me, otherwise I'll ask someone from the PMC to do this) and promote the artifacts to the central Maven repository. Thanks, Radu
Re: [RESULT] [VOTE] Release Apache Sling XSS Protection Bundle version 1.0.0
Hi Robert, I've just taken care of the JIRA updates. How long should I wait until I update the site, given your experience with previous releases? Cheers, Radu On Fri, Mar 20, 2015 at 11:46 AM, Robert Munteanu romb...@apache.org wrote: Hi Radu, On Fri, 2015-03-20 at 10:54 +0200, Radu Cotescu wrote: Hi, I was able to complete most of the release promotion tasks, with the exception of moving the artifacts to Sling dist and updating the News Downloads pages - my account doesn't allow me to commit to Sling dist. Can someone from the PMC please help me with this? I have committed the artifacts to dist. For the other tasks, you should be able to edit the news download pages, those live under [1] . Also, can you please close the issues fixed in this release [2] and mark the issue as released ( see [3] for details ) ? Robert [1]: https://svn.apache.org/repos/asf/sling/site/ [2]: https://issues.apache.org/jira/issues/?jql=project%20%3D%20SLING% 20AND%20fixVersion%20%3D%20%22XSS%20Protection%20API%201.0.0%22%20ORDER% 20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC [3]: https://sling.apache.org/documentation/development/release-management.html#update-jira
Re: [RESULT] [VOTE] Release Apache Sling XSS Protection Bundle version 1.0.0
Hi, I was able to complete most of the release promotion tasks, with the exception of moving the artifacts to Sling dist and updating the News Downloads pages - my account doesn't allow me to commit to Sling dist. Can someone from the PMC please help me with this? Thanks, Radu On Fri, Mar 20, 2015 at 10:01 AM, Radu Cotescu r...@apache.org wrote: Hi, The vote has passed with the following result : +1 (binding): Bertrand Delacretaz, Robert Munteanu, Carsten Ziegeler I will copy this release to the Sling dist directory (if my account allows me, otherwise I'll ask someone from the PMC to do this) and promote the artifacts to the central Maven repository. Thanks, Radu
Re: [jira] [Issue Comment Deleted] (SLING-4524) Provide the properties of the current Resource as a ValueMap via the sling:defineObjects tag
Hi,
For Sightly we also need the properties object in the scope of a script.
Currently this is handled with the help of a BindingsValuesProvider. Given
that probably most scripting engines rely on some of the objects defined by
sling:defineObjects wouldn't it be better, from a developer-friendliness
point of view, if we actually add a generic BVP that provides these
objects? Alternatively we could restrict the BVP to only a sub-set of the
available scripting languages (e.g. JSP, Groovy, Sightly and maybe
Thymeleaf).
The org.apache.sling.scripting.jsp.taglib bundle could then just extract
what it needs for its sling:defineObjects tag and expose the objects:
public int doEndTag() {
final SlingBindings bindings =
(SlingBindings)pageContext.getRequest().getAttribute(SlingBindings.class.getName());
pageContext.setAttribute(propertiesName,
bindings.get(DEFAULT_PROPERTIES_NAME));
...
}
WDYT?
Cheers,
Radu
On Thu, Mar 19, 2015 at 2:56 PM, Olaf Otto (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/SLING-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olaf Otto updated SLING-4524:
-
Comment: was deleted
(was: Pull request: https://github.com/apache/sling/pull/74)
Provide the properties of the current Resource as a ValueMap via the
sling:defineObjects tag
Key: SLING-4524
URL: https://issues.apache.org/jira/browse/SLING-4524
Project: Sling
Issue Type: Wish
Reporter: Olaf Otto
One of the most common use cases in JSP views is accessing the
properties of the current resource. However, this currently requires
explicit adaptation of the current resource to ValueMap, which is
boilerplate. I'd thus love to see properties as one of the defaults
provided by the before mentioned tag library.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[VOTE] Release Apache Sling XSS Protection Bundle version 1.0.0
Hi, We solved 7 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12329024/ There are still some outstanding issues: http://s.apache.org/sling_xss_1.0.2 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1206 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1206 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu
Re: [VOTE] Release Apache Sling XSS Protection Bundle version 1.0.0
Hi Robert, Thanks for the heads up. I did include a rat file for the module since donating the code; I guess I just have to configure the plug-in to take it into consideration. Cheers, Radu On Mon, Mar 9, 2015 at 6:34 PM, Robert Munteanu romb...@apache.org wrote: Hi, On Mon, Mar 9, 2015 at 6:30 PM, Radu Cotescu r...@apache.org wrote: Hi, We solved 7 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12329024/ There are still some outstanding issues: http://s.apache.org/sling_xss_1.0.2 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1206 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1206 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu The -Prat build fails for me $ svn co https://svn.apache.org/repos/asf/sling/tags/org.apache.sling.xss-1.0.0/ $ cd org.apache.sling.xss-1.0.0/ $ mvn verify -Prat (snip...) [ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.10:check (default) on project org.apache.sling.xss: Too many files with unapproved license: 3 See RAT report in: /home/ADOBENET/rmuntean/w/workspace/org.apache.sling.xss-1.0.0/target/rat.txt - [Help 1] I think this should be fixed for the initial release, even if the failures are trivial. Thanks, Robert
Re: [VOTE] Release Apache Sling XSS Protection Bundle version 1.0.0
Hi, I have updated the apache rat plugin configuration for the XSS module and I've restaged the release. Staging repository: *https://repository.apache.org/content/repositories/orgapachesling-1209 https://repository.apache.org/content/repositories/orgapachesling-1209* You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1209 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu
review PR for SLING-4494
Hi devs, Could people familiar with the Apache Sling Performance Test Tools review the patch [0] proposed by Vlad Băilescu for SLING-4494 [1]? The patch helps us provide comparative performance tests for Sightly (see SLING-4493 [2]). Thanks, Radu [0] - https://github.com/apache/sling/pull/69/files?w=1 [1] - https://issues.apache.org/jira/browse/SLING-4494 [2] - https://issues.apache.org/jira/browse/SLING-4493
Re: [VOTE] Release Apache Sling XSS Protection Bundle version 1.0.0
I'll re-release version 1.0.0 once SLING-4492 [0] is fixed. Sorry for the noise. Cheers, Radu [0] - https://issues.apache.org/jira/browse/SLING-4492 On Tue, Mar 10, 2015 at 2:26 PM, Radu Cotescu r...@apache.org wrote: Hi, I have updated the apache rat plugin configuration for the XSS module and I've restaged the release. Staging repository: *https://repository.apache.org/content/repositories/orgapachesling-1209 https://repository.apache.org/content/repositories/orgapachesling-1209* You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1209 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu
[VOTE] Release Apache Sling XSS Protection Bundle 1.0.2
Hi, We solved 1 issue in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12329667/ There are still some outstanding issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12329844/ Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1221 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1221 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu
breaking changes in JCR Contentloader 2.2.0
Hello, SLING-4223 [0] and its related issues introduced major API and functionality changes for the o.a.s.jcr.contentloader bundle. The exported API increased from 0.1 to 1.0.0 and ignoring content importers doesn't work anymore. A major shift in API version is not really warranted. We should strive to propose backwards compatible API, if possible, hence why I'm suggesting to increase the API version to 0.2 instead of 1.0.0. This makes sure that systems where we'd need an upgraded contentloader don't have to also install an updated o.a.s.servlets.post bundle: org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.sling.jcr.jackrabbit.usermanager [55]: Unable to resolve 55.0: missing requirement [55.0] osgi.wiring.package; ((osgi.wiring.package=org.apache.sling.servlets.post)(version=2.1.0)(!(version=3.0.0))) [caused by: Unable to resolve 112.0: missing requirement [112.0] osgi.wiring.package; ((osgi.wiring.package=org.apache.sling.jcr.contentloader)(version=0.1.0)(!(version=1.0.0)))] Also we must make sure that we don't break existing functionality - ignoring content loaders for certain files is a very important feature. Currently we cannot, for example, import XML files into the repo as they're all considered content descriptors. I've created SLING-4537 [1] and SLING-4538 [2] to handle these problems. Thanks, Radu [0] - https://issues.apache.org/jira/browse/SLING-4223 [1] - https://issues.apache.org/jira/browse/SLING-4537 [2] - https://issues.apache.org/jira/browse/SLING-4538
Re: [VOTE] Release Apache Sling Performance Test Utilities 1.0.2
Hi Olli, I've mistakenly released 0.0.2 when the JIRA component for this bundle indicated a 1.0.2 version of the first release. We could do either one of: 1. change the JIRA version to 0.0.2 for the initial release, drop tags, restart the voting thread 2. change the JIRA version to 1.0.0 for the initial release, restart the voting thread 3. use 1.0.2 as the first release Cheers, Radu On 24 March 2015 at 10:41, Oliver Lietz apa...@oliverlietz.de wrote: On Monday 23 March 2015 22:47:52 Radu Cotescu wrote: Hi, hi Radu, We solved 7 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12327378 what's the point in tagging 0.0.2 and 1.0.2 (same code)? 0.0.2 as initial version is fine (as we don't sell a product and don't need a big number for marketing) and if you really need a major 1 why not going for 1.0.0? Regards, O. Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1218 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1218 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu
Re: [VOTE] Release Apache Sling Performance Test Utilities 1.0.2
Hi Olli, IMHO the nicest way to release something is to start from 1.0.0 (x.2 is Oracle's style). But the least work, given the circumstances, is option 3 since that's what has been set in JIRA previously. Let's see what other people think. I'm fine either way. I haven't yet started to think about adaptTo(), but this utility bundle is used for Sightly's performance tests (see SLING-4493 [0]). Cheers, Radu [0] - https://issues.apache.org/jira/browse/SLING-4493 On 25 March 2015 at 10:33, Oliver Lietz apa...@oliverlietz.de wrote: On Tuesday 24 March 2015 11:09:41 Radu Cotescu wrote: Hi Olli, Hi Radu, I've mistakenly released 0.0.2 when the JIRA component for this bundle indicated a 1.0.2 version of the first release. We could do either one of: 1. change the JIRA version to 0.0.2 for the initial release, drop tags, restart the voting thread 2. change the JIRA version to 1.0.0 for the initial release, restart the voting thread 3. use 1.0.2 as the first release I would go for 1. Are you planning to show some results at adaptTo()? Regards, O. Cheers, Radu On 24 March 2015 at 10:41, Oliver Lietz apa...@oliverlietz.de wrote: On Monday 23 March 2015 22:47:52 Radu Cotescu wrote: Hi, hi Radu, We solved 7 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12327378 what's the point in tagging 0.0.2 and 1.0.2 (same code)? 0.0.2 as initial version is fine (as we don't sell a product and don't need a big number for marketing) and if you really need a major 1 why not going for 1.0.0? Regards, O. Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1218 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1218 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu
Re: [VOTE] Release Apache Sling Performance Test Utilities 1.0.2
Then let's be lazy developers and start with 1.0.2, since JIRA was already set up like this. On 25 March 2015 at 11:15, Bertrand Delacretaz bdelacre...@apache.org wrote: I don't really care about the exact version numbers used, or if there are version number gaps between releases etc.
[RESULT] [VOTE] Release Apache Sling XSS Protection Bundle version 1.0.2
Hi, The vote has passed with the following result : +1 (binding): Stefan Egli, Daniel Klco, Robert Munteanu I can handle all the remaining release tasks except for copying the artifacts to the Sling dist directory. Can somebody from the PMC please do this for me? Thanks, Radu
[RESULT][VOTE] Release Apache Sling Scripting Sightly 1.0.0
Hi, The vote has passed with the following result : +1 (binding): Justin Edelson, Robert Munteanu, Bertrand Delacretaz I can handle all the remaining release tasks except for copying the artifacts to the Sling dist directory. Can somebody from the PMC please do this for me? Thanks, Radu
Re: [VOTE] Release Apache Sling Performance Test Utilities 1.0.2
Ping! :) On 25 March 2015 at 12:01, Robert Munteanu romb...@apache.org wrote: +1 Robert On Mon, Mar 23, 2015 at 10:47 PM, Radu Cotescu r...@apache.org wrote: Hi, We solved 7 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12327378 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1218 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1218 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu
Limited working time / offline for one week
Hi, Starting today I'm attending a week-long conference and I'll also be on PTO for a week from March 2nd. Please expect some delays in replying to emails / working on JIRA issues. Cheers, Radu
Re: Sightly Integration Test execution fails for me
It's cool that you figured out the culprit so fast. On Thu, Feb 19, 2015 at 11:53 PM, Konrad Windszus konra...@gmx.de wrote: Hi Radu, I use UTF-8 as default encoding as well. The issue only occurs when using it with JDK 1.7.0_55. Using JDK 1.7.0_60 or later solves the issue. So it is probably related to one issue being fixed in 1.7.0_60: http://www.oracle.com/technetwork/java/javase/2col/7u60-bugfixes-2202029.html http://www.oracle.com/technetwork/java/javase/2col/7u60-bugfixes-2202029.html Konrad On 20 Feb 2015, at 02:33, Radu Cotescu r...@cotescu.com wrote: Hi Konrad, The code does indeed rely on the default platform encoding. However, on my Mac, the default encoding is UTF-8. mvn -version Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T09:29:23-08:00) Maven home: /usr/local/Cellar/maven/3.2.5/libexec Java version: 1.7.0_67, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: mac os x, version: 10.10.2, arch: x86_64, family: mac Is the encoding different on your box? Regards, Radu On Thu, Feb 19, 2015 at 4:13 AM, Konrad Windszus konra...@gmx.de wrote: I just tried to execute the Sightly Integration Tests and I get the following error: ... Tests run: 336, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.994 sec FAILURE! - in io.sightly.tck.TestsRunner String Expressions: String quotes and escaping - #unicode_escape(io.sightly.tck.tests.TestBuilder$1) Time elapsed: 0.007 sec FAILURE! junit.framework.AssertionFailedError: Expected value 'This 'Atilde;' is a string with unicode escaping' for selector '#unicode_escape'. Instead we got 'This '??' is a string with unicode escaping'. Please check the expected markup from /testfiles/output/exprlang/strings.html. at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at io.sightly.tck.tests.TestBuilder$1.runTest(TestBuilder.java:146) Results : Failed tests: TestBuilder$1.runTest:146 Expected value 'This 'Atilde;' is a string with unicode escaping' for selector '#unicode_escape'. Instead we got 'This '??' is a string with unicode escaping'. Please check the expected markup from /testfiles/output/exprlang/strings.html. Tests run: 340, Failures: 1, Errors: 0, Skipped: 0 ... This happens with the most recent trunk and I just recompiled the XSS module on my own before that. I am using JDK 1.7.0_55 on a Mac. Any ideas what might be wrong? Is the code relying on the default encoding maybe? Thanks, Konrad
Re: [VOTE] Release Apache Sling Scripting Sightly 1.0.0
Hi Robert, I'm fine with dropping the o.a.s.scripting.sightly.testing artifact from this release, in which case the vote should still go on for the artifacts from 1216. I'll start a new release thread for o.a.s.scripting.sightly.testing once the o.a.s.performance.base artifact is released. Cheers, Radu On 24 March 2015 at 22:04, Robert Munteanu romb...@apache.org wrote: IMO you should either drop org.apache.sling.scripting.sightly.testing completely from this release or cancel the whole release and restart the process once org.apache.sling.performance.base has been released.
Re: [discussion] [contrib] Hypermedia API tools (with Sightly)
Hi Andrei, I'll try to guide you through the code contribution process, though at some point you'll need the PMC's help. First you would need to start a [VOTE] thread on sling-dev for integrating your contribution into Sling's codebase (e.g. [VOTE] accept Hypermedia API tools into contrib), reference SLING-4513 in this newly created thread and attach your source code to SLING-4513 as a zip archive. It's useful to also provide an md5 checksum file to make sure that people who will integrate your code into Sling's codebase don't end up with a corrupted archive. You need at least 3 +1 binding votes (coming from PMC members). The next step is the IP clearance form [3], which is usually SLING's PMC job, though you could help by providing them with a draft. An example of this filled form can be found at [4]. You also need to sign and send an iCLA form [5] to secretary [at] apache.org. If your code was developed at Adobe you might also need to add your name to Adobe's Corporate CLA. This IP stuff is usually tracked through another JIRA issue, usually created by the sponsoring PMC member, that will block SLING-4513 until all the IP issues are cleared. Let me know if you need any other details. Cheers, Radu [3] - http://incubator.apache.org/ip-clearance/index.html [4] - http://incubator.apache.org/ip-clearance/sling-sightly-xss.html [5] - https://www.apache.org/licenses/icla.txt On 17 March 2015 at 17:30, Andrei Dulvac andrei.dul...@gmail.com wrote: Hi, Thanks a lot, Felix for the confidence vote. I created *SLING-4513* to track this. Any chance someone can help with this? The codebase is quite tiny. Thank you, Andrei On Thu, Mar 12, 2015 at 12:34 PM Felix Meschberger fmesc...@adobe.com wrote: Hi all I just had a good discussion with Andrei on this topic. This really looks interesting and I even think this could be used as the basis for HTTP-based APIs. I suggest you, @Andrei, create a Sling issue from where we can move forward. Some more suggestions I already discussed with Andrei: * Investigate whether the HApiUse can be registered as a UseProvider service and thus not require to export it and also to make it easier to use, i.e. not having to know the fully qualified class name. * Having samples for JSP would be cool as well (We should also investigate how much a tag lib would help for JSP) All in all, things we might consider moving forward working towards a first release and not blocking adoption by Sling. And then: There HApi.js which IIUIC is used in the Node.js world to build web applications. We should investigate whether we would have to change the name of this feature. To summarise: Thanks for the offer. Lets move this forward. Oh, and yes: Do we have a volunteer to coach Andrei moving this contribution forward ? Thanks a lot ! Regards Felix Am 30.01.2015 um 18:57 schrieb Andrei Dulvac andrei.dul...@gmail.com : Hi, This is the first thread I initiate on sling dev, so I apologize in advance if I'm breaking any conventions. I've written a bundle that allows sling component developers to quickly define a hypermedia API for components. The tools contain a Sightly Use class for Sightly components, but also a generic utility that can be used anywhere, like in a jsp component. It uses hypermedia to drive the state of the application (e.g a consumer uses links and forms to change the state) and uses microdata [0] to define an easy to parse structure. The API can then be consumed by bots or used in testing, while using the same HTML as the media type for the API as the browser. You can find the bundle here [1] if you'd like to have a look. The readme has some examples and you can quickly try it out with a generic python client [2]. What do you think about putting this in the contrib/ dir in sling and about the idea in general? Looking forward to some responses. - Andrei Dulvac --- [0] http://www.w3.org/TR/microdata/ [1] https://github.com/dulvac/hapi [2] https://github.com/dulvac/hapi#consuming-the-api
Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 4:21 PM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: +1. This looks more safer and less disrupting as reading the property is cheaper. But we'd need a mixin, as scripts are usually nt:file nodes. Right?
Re: [Sightly] provide access to the Script Resource Resolver in RenderContext
Hi Rob, The RuntimeExtensions are meant to process the outcome of a Sightly expression. If such an extension would need to perform some processing based on component resolution it's fair to pass it the same resolver that the ServletResolver used. I'll document in the RenderContext that this resolver should only be used for component resolution, explicitly specifying that for content resolution the request's resolver (available from the RenderContext#getBindings) should be used. An extension can be called multiple times during the rendering of the same page; if this extension would be called 20 times for the rendering of one page and if the extension needs a resource resolver to handle its processing, I'd *really* like to avoid creating 20 resource resolvers if I could just use the ServletResolver RR, which is passed down anyways to script engines, through the ScriptContext. Regards, Radu On Fri, Jan 23, 2015 at 4:11 PM, Rob Ryan rr...@adobe.com wrote: We do *not* want to allow a resolver passed around from the ServletResolver to be abused for accessing general content. If Slightly RuntimeExtensions need more access than the ServletResolver they should manage a resolver themselves. Also, this sounds like premature optimization. If ResourceResolver creation is slow the ROI on making it faster is likely significant as multi-thread usage of a session in Oak degrades performance rapidly.
Re: [discussion] allow Script Engines to also render components based on paths
On Fri, Jan 23, 2015 at 4:41 PM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: Other way would be to leverage the jcr:mimeType on the child jcr:content node which are mostly of type nt:resource. text/thymeleaf, text/sightly, text/jsp...? :)
[VOTE] Release Apache Sling Scripting Sightly 1.0.0
Hi, We solved 54 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12329007 (44) https://issues.apache.org/jira/browse/SLING/fixforversion/12329008 (10) Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1216 The staging repository contains the following artifacts: org.apache.sling.scripting.sightly org.apache.sling.scripting.sightly.js.provider org.apache.sling.scripting.sightly.repl org.apache.sling.scripting.sightly.testing org.apache.sling.scripting.sightly.testing-content You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1216 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours.
[VOTE] Release Apache Sling Performance Test Utilities 1.0.2
Hi, We solved 7 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12327378 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1218 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1218 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu
Re: [VOTE] Release Apache Sling Scripting Sightly 1.0.0
Hi, I've started a release thread for org.apache.sling.performance.base at http://sling.markmail.org/thread/m7xyhb6saxfyqs6w. I've also dropped org.apache.sling.scripting.sightly.testing from staging repository 1216 and restaged this artifact at 1219. You can use this UNIX script to download the release and verify the signatures for org.apache.sling.scripting.sightly.testing: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1219 /tmp/sling-staging Thanks, Radu On Mon, Mar 23, 2015 at 7:25 PM, Radu Cotescu r...@apache.org wrote: Hi Robert, It would be better to release that snapshot dependency in order to provide a way to easily test Sightly artifacts. I'll take care of that this evening. Cheers, Radu On Monday, March 23, 2015, Robert Munteanu romb...@apache.org wrote: On Mon, 2015-03-23 at 10:50 -0400, Daniel Klco wrote: org.apache.sling.sightly.testing relies on a SNAPSHOT dependency: dependency groupIdorg.apache.sling/groupId artifactIdorg.apache.sling.performance.base/artifactId version0.0.1-SNAPSHOT/version scopetest/scope /dependency As this is a testing project, I'm not sure if this is a big deal or acceptable. Ideally, if we could make a release of this performance tools it would be good to apply performance tests across all of the scripting languages available in Sling. Good catch! I assumed the maven release plugin would be banning SNAPSHOTs, but apparently this is not the case ... We can't deploy SNAPSHOT depedencies on Maven Central and we should not as a general rule depend on SNAPSHOTs from releases, as the SNAPSHOTs will at some point go away and make the released artifact invalid. So we either release the org.apache.sling.performance.base artifact and depend on it or drop the org.apache.sling.sightly.testing artifact from the release. Radu? Robert -- Sent with clumsy fingers from a touchscreen
Re: [VOTE] Release Apache Sling Scripting Sightly 1.0.0
Hi Robert, 1216 contains: org.apache.sling.scripting.sightly org.apache.sling.scripting.sightly.js.provider org.apache.sling.scripting.sightly.repl org.apache.sling.scripting.sightly.testing-content as I've removed org.apache.sling.scripting.sightly.testing, since it was pointing to a snapshot dependency. 1219 contains: org.apache.sling.scripting.sightly.testing, which now points to org.apache.sling.performance.base 1.0.2. Thanks, Radu On Mon, Mar 23, 2015 at 11:37 PM, Robert Munteanu rob...@lmn.ro wrote: On Mon, Mar 23, 2015 at 11:29 PM, Radu Cotescu r...@apache.org wrote: Hi, I've started a release thread for org.apache.sling.performance.base at http://sling.markmail.org/thread/m7xyhb6saxfyqs6w. I've also dropped org.apache.sling.scripting.sightly.testing from staging repository 1216 and restaged this artifact at 1219. You can use this UNIX script to download the release and verify the signatures for org.apache.sling.scripting.sightly.testing: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1219 /tmp/sling-staging So on which repository/artifacts are we voting now? Both 1216 and 1219 seem to be active. Robert Thanks, Radu On Mon, Mar 23, 2015 at 7:25 PM, Radu Cotescu r...@apache.org wrote: Hi Robert, It would be better to release that snapshot dependency in order to provide a way to easily test Sightly artifacts. I'll take care of that this evening. Cheers, Radu On Monday, March 23, 2015, Robert Munteanu romb...@apache.org wrote: On Mon, 2015-03-23 at 10:50 -0400, Daniel Klco wrote: org.apache.sling.sightly.testing relies on a SNAPSHOT dependency: dependency groupIdorg.apache.sling/groupId artifactIdorg.apache.sling.performance.base/artifactId version0.0.1-SNAPSHOT/version scopetest/scope /dependency As this is a testing project, I'm not sure if this is a big deal or acceptable. Ideally, if we could make a release of this performance tools it would be good to apply performance tests across all of the scripting languages available in Sling. Good catch! I assumed the maven release plugin would be banning SNAPSHOTs, but apparently this is not the case ... We can't deploy SNAPSHOT depedencies on Maven Central and we should not as a general rule depend on SNAPSHOTs from releases, as the SNAPSHOTs will at some point go away and make the released artifact invalid. So we either release the org.apache.sling.performance.base artifact and depend on it or drop the org.apache.sling.sightly.testing artifact from the release. Radu? Robert -- Sent with clumsy fingers from a touchscreen -- Sent from my (old) computer
Re: [VOTE] Release Apache Sling Scripting Sightly 1.0.0
Hi Robert, It would be better to release that snapshot dependency in order to provide a way to easily test Sightly artifacts. I'll take care of that this evening. Cheers, Radu On Monday, March 23, 2015, Robert Munteanu romb...@apache.org wrote: On Mon, 2015-03-23 at 10:50 -0400, Daniel Klco wrote: org.apache.sling.sightly.testing relies on a SNAPSHOT dependency: dependency groupIdorg.apache.sling/groupId artifactIdorg.apache.sling.performance.base/artifactId version0.0.1-SNAPSHOT/version scopetest/scope /dependency As this is a testing project, I'm not sure if this is a big deal or acceptable. Ideally, if we could make a release of this performance tools it would be good to apply performance tests across all of the scripting languages available in Sling. Good catch! I assumed the maven release plugin would be banning SNAPSHOTs, but apparently this is not the case ... We can't deploy SNAPSHOT depedencies on Maven Central and we should not as a general rule depend on SNAPSHOTs from releases, as the SNAPSHOTs will at some point go away and make the released artifact invalid. So we either release the org.apache.sling.performance.base artifact and depend on it or drop the org.apache.sling.sightly.testing artifact from the release. Radu? Robert -- Sent with clumsy fingers from a touchscreen
Re: [VOTE] Release Apache Sling Performance Test Utilities 1.0.2
Hi, Kind reminder: this vote is one +1 away from allowing a release. Thanks, Radu On 30 March 2015 at 16:41, Daniel Klco dk...@apache.org wrote: +1 On Mon, Mar 30, 2015 at 7:22 AM, Radu Cotescu r...@apache.org wrote: Ping! :) On 25 March 2015 at 12:01, Robert Munteanu romb...@apache.org wrote: +1 Robert On Mon, Mar 23, 2015 at 10:47 PM, Radu Cotescu r...@apache.org wrote: Hi, We solved 7 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12327378 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1218 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1218 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu
[RESULT][VOTE] Release Apache Sling Scripting JavaScript Support 2.0.16
Hi, The vote passed with 4 binding +1 from: Carsten Ziegeler, Robert Munteanu, Daniel Klco, Oliver Lietz. I'll start promoting the release now. @PMC: could one of you please move the artifacts (org.apache.sling.scripting.javascript-2.0.16*) to dist? Thanks, Radu
Re: [VOTE] Release Apache Sling Scripting Sightly JS Use Provider 1.0.4
Kind reminder. :) On Fri, 10 Apr 2015 at 11:02 Robert Munteanu romb...@apache.org wrote: +1 Robert On Thu, Apr 9, 2015 at 7:46 PM, Radu Cotescu r...@apache.org wrote: Hi, We solved one issue in this release: *https://issues.apache.org/jira/browse/SLING/fixforversion/12331975 https://issues.apache.org/jira/browse/SLING/fixforversion/12331975* Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1233 The repository contains: org.apache.sling.scripting.sightly.js.provider-1.0.4 org.apache.sling.scripting.sightly.testing-content-1.0.4 org.apache.sling.scripting.sightly.testing-1.0.4 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1233 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu
Re: [VOTE] Release Apache Sling Scripting Sightly JS Use Provider 1.0.4
We're one vote shy of releasing the bundle. :) Thanks, Radu On Tue, 14 Apr 2015 at 23:02 Carsten Ziegeler cziege...@apache.org wrote: +1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[RESULT][VOTE] Release Apache Sling Scripting Sightly JS Use Provider 1.0.4
Hi, The release vote passed with 3 binding +1 votes: Robert Munteanu, Carsten Ziegeler, Stefan Egli. I'll start promoting the release. As usual, I'm relying on the PMC to move the released artifacts to dist. Thanks, Radu
[VOTE] Release Apache Sling Scripting JavaScript Support 2.0.16
Hi, We solved two issues in this release: *https://issues.apache.org/jira/browse/SLING/fixforversion/12327183 https://issues.apache.org/jira/browse/SLING/fixforversion/12327183* Staging repository: *https://repository.apache.org/content/repositories/orgapachesling-1238 https://repository.apache.org/content/repositories/orgapachesling-1238* You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1238 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu
Re: need access to Jenkins for setting up Sightly CI job
Hi Robert, Sightly doesn't appear to be built with all the contrib modules [0]. Cheers, Radu [0] - https://github.com/apache/sling/blob/trunk/contrib/pom.xml On Mon 6 Apr 2015 at 00:41 Robert Munteanu romb...@apache.org wrote: Hi Radu, On Sat, Apr 4, 2015 at 6:00 PM, Radu Cotescu r...@apache.org wrote: Hi, I'd like to set up a Jenkins job for Sightly in order to make sure that changes affecting the codebase don't actually break stuff. Isn't Sightly already part of the contrib build? Can somebody from the PMC please add my user to the hudson-jobadmin group? That would be the PMC chair, not any PMC members. Robert
Re: requirements for including Sightly into Sling Launchpad
Hi Robert, I'm definitely not in favour of snapshot dependencies in the launchpad, so we're on the same page here. What do you mean by tangled dependencies? I know that the launchpad usually doesn't contain bundles from contrib so I was thinking about what you're suggesting but I just wanted somebody from the PMC to say it. Cheers, Radu On Mon 6 Apr 2015 at 00:46 Robert Munteanu rob...@lmn.ro wrote: On Sat, Apr 4, 2015 at 7:19 PM, Radu Cotescu r...@apache.org wrote: Hi, Given the recent improvements of the Sightly implementation from Sling I think that having this scripting engine in the launchpad would be a nice feature. Sounds OK to me, as long as we don't introduce SNAPSHOT dependencies, as they will not be buildable in the same reactor. Wouldn't it be clearer though to move sightly and all its dependencies to /bundles/? I have a documented uneasy feeling about tangled dependencies between our reactor builds. Cheers, Robert What are the requirements for including Sightly into the launchpad? The following would be the list of bundles that need to be added to launchpad/slingstart/src/main/provisioning/sling.txt: # xss javax.mail/mail/1.4.7 org.apache.sling/org.apache.sling.xss/1.0.2 # contrib/extensions/xss # i18n org.apache.sling/org.apache.sling.i18n/2.3.2 # contrib/extensions/i18n # jcr compiler org.apache.sling/org.apache.sling.jcr.compiler/2.1.0 # contrib/jcr/compiler # sightly org.apache.sling/org.apache.sling.scripting.sightly/1.0.0 #contrib/scripting/sightly org.apache.sling/org.apache.sling.scripting.sightly.js.provider/1.0.0 #contrib/scripting/sightly org.apache.sling/org.apache.sling.scripting.sightly.repl/1.0.0 #contrib/scripting/sightly Cheers, Radu -- Sent from my (old) computer
[RESULT][VOTE] Release Apache Sling Scripting Sightly 1.0.2
Hi all, The vote passed with the following binding votes: Justin Edelson, Robert Munteanu, Stefan Egli. I'll promote the release and update JIRA accordingly. As always, I'm grateful to the PMC member who will move the artifacts to dist. ;) Thanks, Radu
Re: [VOTE] Release Apache Sling Scripting Sightly 1.0.2
Thank you for your votes! I guess I can now start the [RESULT] thread. Cheers, Radu
[VOTE] Release Apache Sling Scripting Sightly JS Use Provider 1.0.2
Hi, We solved one issue in this release: *https://issues.apache.org/jira/browse/SLING/fixforversion/12329864 https://issues.apache.org/jira/browse/SLING/fixforversion/12329864* Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1230/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1230 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu
Re: Using the provisioning model
Hi Carsten, Does the slingstart plugin provide support for creating custom launchpads (similar to the additional bundles feature of the launchpad plugin)? Thanks, Radu On Wed 8 Apr 2015 at 08:29, Carsten Ziegeler cziege...@apache.org wrote: Hi, as mentioned before I think we should move to the provisioning model and replace the old xml based bundle list. The major features are implemented and the latest maven slingstart plugin supports building and testing instances based on the provisioning model. However, as we have several modules currently using the sling launchpad plugin and the xml format, moving to the provisioning model is a larger task. My suggestion is to do this incrementally, starting with the launchpad and fixing things, implementing missing functionality when we hit them. While this has the downside that we will have failing builds for some time, I think it's the easier way and might lead to a more collaborative work. If no one objects I'll start the work in the coming days. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Cleaning up our documentation mess
Big +1 since most of the Google indexed links send you to the old pages, although most of them have been migrated. Cheers, Radu On Wed 8 Apr 2015 at 08:33, Carsten Ziegeler cziege...@apache.org wrote: Right now we have some of the old documentation still available at http://sling.apache.org/site/* with a marker on each page indicating that the doc is outdated. (Famous excuse our mess page at http://sling.apache.org/site-conversion.html) On the other hand, on the real pages we have a marker that this page is not completely migrated yet. We have this situation now for a very long time and fortunately some pages have been finished migrating. I suggested we now clean up the mess, simply create redirects for all old pages to the new ones and remove all the banners. The minor downside is that we might loose some changes that happened to the old pages after they have been converted. But the major advantage is that we don't look stupid anymore and have a single documenentation moving forward. WDYT? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
need access to Jenkins for setting up Sightly CI job
Hi, I'd like to set up a Jenkins job for Sightly in order to make sure that changes affecting the codebase don't actually break stuff. Can somebody from the PMC please add my user to the hudson-jobadmin group? [0] Thanks, Radu [0] - http://wiki.apache.org/general/Jenkins#How_do_I_get_an_account
requirements for including Sightly into Sling Launchpad
Hi, Given the recent improvements of the Sightly implementation from Sling I think that having this scripting engine in the launchpad would be a nice feature. What are the requirements for including Sightly into the launchpad? The following would be the list of bundles that need to be added to launchpad/slingstart/src/main/provisioning/sling.txt: # xss javax.mail/mail/1.4.7 org.apache.sling/org.apache.sling.xss/1.0.2 # contrib/extensions/xss # i18n org.apache.sling/org.apache.sling.i18n/2.3.2 # contrib/extensions/i18n # jcr compiler org.apache.sling/org.apache.sling.jcr.compiler/2.1.0 # contrib/jcr/compiler # sightly org.apache.sling/org.apache.sling.scripting.sightly/1.0.0 #contrib/scripting/sightly org.apache.sling/org.apache.sling.scripting.sightly.js.provider/1.0.0 #contrib/scripting/sightly org.apache.sling/org.apache.sling.scripting.sightly.repl/1.0.0 #contrib/scripting/sightly Cheers, Radu
[VOTE] Release Apache Sling Scripting Sightly 1.0.2
Hi, We solved 2 issues in this release: *https://issues.apache.org/jira/browse/SLING/fixforversion/12329315 https://issues.apache.org/jira/browse/SLING/fixforversion/12329315* Staging repositories (there were some problems with repository.apache.org during the release process, see INFRA-9363, INFRA-9372): https://repository.apache.org/content/repositories/orgapachesling-1226 (org.apache.sling.scripting.sightly-1.0.2) https://repository.apache.org/content/repositories/orgapachesling-1228 (org.apache.sling.scripting.sightly.testing-content-1.0.2) https://repository.apache.org/content/repositories/orgapachesling-1229 (org. apache.sling.scripting.sightly.testing-1.0.2) You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1226 /tmp/sling-staging sh check_staged_release.sh 1228 /tmp/sling-staging sh check_staged_release.sh 1229 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Radu
