Re: [RT] docs should be in bundles
On Wed 01 Apr 2009 15:10, Bertrand Delacretaz wrote: > I think it would be very hard to keep things in sync between svn and > the wiki, once our bundles have independent release cycles. Call me > pessimistic but I don't think we'd manage. > > We can still use the wiki for general/overview docs (though that might > also be an "overview" bundle with just docs), and use the bundle-based > docs for the reference stuff. JavaDocs and other "official" API docs should definitely be versioned and multiple versions should be available. Where they are matters less than whether they exist at all. Ideally, the website has multiple sections. Certain introduction material doesn't need replicated for each version. It can just be updated. But anything that specifically refers to code, such as tutorials, should ideally be available in different versions. Whether the wiki supports this setup or not is a different question from how the documentation should ideally be organized. -- J Aaron Farr jadetower.com[US] +1 724-964-4515 馮傑仁 cubiclemuses.com [HK] +852 8123-7905
Re: [RT] docs should be in bundles
On Wed, Apr 1, 2009 at 8:58 AM, Carsten Ziegeler wrote: >... I'm not happy about including these things into the bundle. And I'm also > not sure about having the docs in svn - but that's the old discussion > about the better way of editing/maintaining the docs (svn vs. wiki etc.)... I think it would be very hard to keep things in sync between svn and the wiki, once our bundles have independent release cycles. Call me pessimistic but I don't think we'd manage. We can still use the wiki for general/overview docs (though that might also be an "overview" bundle with just docs), and use the bundle-based docs for the reference stuff. > ...Let's keep the stuff separate, we have a bundle jar, a source jar, a > javadoc jar and maybe the docs jar. If someone needs all of these as a > single archive it's easy to create one out of those artifacts That might work, and what do you think about generating the docs of a particular Sling instance based on which bundles are installed? I think that's the key point in my proposal, exactly where the docs come from is more an implementation detail. With docs in a separate bundle, the docs service would need to list bundles for which there's no corresponding "docs" bundle installed, that shouldn't be too hard to do based on conventions on bundle symbolic names (i.e. foo.slingdocs is the docs of the foo bundle). And with an OBR (http://www.osgi.org/Repository/HomePage), docs bundles could be downloaded semi-automatically. -Bertrand (and I'm very serious BTW, as usual ;-)
Sling Release
Hi all, Just wanted to inform you all (at least the ones not sitting on felix-dev@), that the Felix project is currently voting on the 1.6.0 release of the Felix framework. I tested Sling with the release candidate and apart from a small issue in Sling [1], it works flawlessly. I assume that, given the vote passes, we should release Sling next week. WDYT ? Regards Felix
[jira] Created: (SLING-905) Sling does not properly startup with the latest Felix framework 1.5.0-SNAPSHOT (and 1.6.0 release candidate)
Sling does not properly startup with the latest Felix framework 1.5.0-SNAPSHOT (and 1.6.0 release candidate) Key: SLING-905 URL: https://issues.apache.org/jira/browse/SLING-905 Project: Sling Issue Type: Bug Components: Launchpad Launcher Affects Versions: Launchpad Base 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Launchpad Base 2.0.4 The launchpad base provides the property org.osgi.framework.startlevel in its sling.properties file, which is intended to define the initial start level for the framework. The latest R 4.2 Core Specification draft (dated 2009/03/10) defines this property to be org.osgi.framework.startlevel.beginning As a consequence Sling remains in start level 1 after startup. To fix this, the property should be renamed in the sling.properties file and the Sling launcher should migrate any occurrence of the older property org.osgi.framework.startlevel to the new name (as is already done with the previous Felix specific property felix.startlevel.framework) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-905) Sling does not properly startup with the latest Felix framework 1.5.0-SNAPSHOT (and 1.6.0 release candidate)
[ https://issues.apache.org/jira/browse/SLING-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-905. - Resolution: Fixed Implemented these changes in Rev. 760795. > Sling does not properly startup with the latest Felix framework > 1.5.0-SNAPSHOT (and 1.6.0 release candidate) > > > Key: SLING-905 > URL: https://issues.apache.org/jira/browse/SLING-905 > Project: Sling > Issue Type: Bug > Components: Launchpad Launcher >Affects Versions: Launchpad Base 2.0.4 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Launchpad Base 2.0.4 > > > The launchpad base provides the property > org.osgi.framework.startlevel > in its sling.properties file, which is intended to define the initial start > level for the framework. The latest R 4.2 Core Specification draft (dated > 2009/03/10) defines this property to be > org.osgi.framework.startlevel.beginning > As a consequence Sling remains in start level 1 after startup. > To fix this, the property should be renamed in the sling.properties file and > the Sling launcher should migrate any occurrence of the older property > org.osgi.framework.startlevel to the new name (as is already done with the > previous Felix specific property felix.startlevel.framework) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling Release
On Wed, Apr 1, 2009 at 9:37 AM, Felix Meschberger wrote: > Hi all, > > Just wanted to inform you all (at least the ones not sitting on > felix-dev@), that the Felix project is currently voting on the 1.6.0 > release of the Felix framework. I tested Sling with the release > candidate and apart from a small issue in Sling [1], it works flawlessly. > > I assume that, given the vote passes, we should release Sling next week. > > WDYT ? Great. Is there a list of issues that should be resolved before the release? And, more specifically, will SLING-880 [1] be on that list? :) [1] https://issues.apache.org/jira/browse/SLING-880 -- Vidar S. Ramdal - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway +47 21 531941, ext 2070
[jira] Closed: (SLING-510) google summer of code sling/scala code & problems.
[ https://issues.apache.org/jira/browse/SLING-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz closed SLING-510. - Resolution: Won't Fix Scala scripting engine is now available in contrib/scripting/scala/ > google summer of code sling/scala code & problems. > -- > > Key: SLING-510 > URL: https://issues.apache.org/jira/browse/SLING-510 > Project: Sling > Issue Type: New Feature > Components: Scripting >Reporter: Janandith Uditha Jayawardena >Priority: Minor > Attachments: error report from jetty.png, launchpad_error.jpg, > scala-standalone.tar.gz, scala.tar.gz > > > This Issue is created to submit the code of sling/scala which is a google > summer of code project. > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-905) Sling does not properly startup with the latest Felix framework 1.5.0-SNAPSHOT (and 1.6.0 release candidate)
[ https://issues.apache.org/jira/browse/SLING-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-905. --- This works, so this can be closed. > Sling does not properly startup with the latest Felix framework > 1.5.0-SNAPSHOT (and 1.6.0 release candidate) > > > Key: SLING-905 > URL: https://issues.apache.org/jira/browse/SLING-905 > Project: Sling > Issue Type: Bug > Components: Launchpad Launcher >Affects Versions: Launchpad Base 2.0.4 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Launchpad Base 2.0.4 > > > The launchpad base provides the property > org.osgi.framework.startlevel > in its sling.properties file, which is intended to define the initial start > level for the framework. The latest R 4.2 Core Specification draft (dated > 2009/03/10) defines this property to be > org.osgi.framework.startlevel.beginning > As a consequence Sling remains in start level 1 after startup. > To fix this, the property should be renamed in the sling.properties file and > the Sling launcher should migrate any occurrence of the older property > org.osgi.framework.startlevel to the new name (as is already done with the > previous Felix specific property felix.startlevel.framework) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [RT] docs should be in bundles
On Wed, Apr 1, 2009 at 8:49 AM, Bertrand Delacretaz > [...] I think the only sane way for docs to be in > sync with the bundles is to have those docs *inside* the bundles. And > maintain them alongside the source code. [...] I'm all for maintaining docs along the source, but I don't think I would want the docs to be available on a URL in a production system. > [...] And providing a tool, or build profile, that strips the docs from > bundles is > not hard. [...] Cool, but how about the released jars? Would they contain the docs? -- Vidar S. Ramdal - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway +47 21 531941, ext 2070
Re: Renaming SlingWebDavServlet? (was: SlingWebDavServlet serves resource not only below /dav?)
Hi, Bertrand Delacretaz schrieb: > (still catching up with my Sling mail ;-) > > Hi, > > On Tue, Mar 17, 2009 at 2:46 PM, Marc Speck wrote: >> ...You have also my vote if you want to rename >> org.apache.sling.jcr.webdav.impl.servlets.SimpleWebdavServlet. "public class >> SimpleWebDavServlet extends SimpleWebdavServlet" is not very readable and in >> SlingWebDavServlet, there are SimpleWebDavServlet and SimpleWebdavServlet >> that refer to different classes > > I agree that this can be confusing, do people agree about renaming the > Sling servlet, to SlingSimpleWebDavServlet, maybe? Lets see, there are actually two servlets in the jcr/webdav bundle: The SlingWebDavServlet (extends SimpleWebDavServlet) is the one which is registered as a Sling Servlet to handle WebDAV requests to / (root). Whenever the SlingWebDavServlet is getting ready it creates an instance of the (Sling) SimpleWebDavServlet (extends Jackrabbit SimpleWebDavServlet) to handle WebDAV requests at /dav (configurable). This SimpleWebDavServlet is different from the SlingWebDavServlet in that it allows access to all workspaces of the repository. As such the two servlets serve different purposes and cannot (easily) be merged and should also not be merged because we don't want to have a single servlet registered in two locations. So remains the issue of the Sling SimpleWebDavServlet colliding in name with the Jackrabbit SimpleWebDavServlet. I have now issue with renaming this servlet for clarity sake, but SlingWebDavServlet is already taken ;-) We could really name SlingSimpleWebDavServlet to indicate it works the same as the Jackrabbit SimpleWebDavServlet but it is located in Sling. Regards Felix > > -Bertrand >
Re: Sling Release
Hi, Vidar Ramdal schrieb: > On Wed, Apr 1, 2009 at 9:37 AM, Felix Meschberger wrote: >> Hi all, >> >> Just wanted to inform you all (at least the ones not sitting on >> felix-dev@), that the Felix project is currently voting on the 1.6.0 >> release of the Felix framework. I tested Sling with the release >> candidate and apart from a small issue in Sling [1], it works flawlessly. >> >> I assume that, given the vote passes, we should release Sling next week. >> >> WDYT ? > > Great. Is there a list of issues that should be resolved before the release? > And, more specifically, will SLING-880 [1] be on that list? :) > > [1] https://issues.apache.org/jira/browse/SLING-880 I assume it goes along the line of [1] and since you tagged SLING-880 for the next jackrabbit-server release, we should really apply this patch before releasing. BTW, my initial mail missed a link which is to SLING-905 [2] Regards Felix [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=show&requestId=12312970 [2] https://issues.apache.org/jira/browse/SLING-905
Re: Sling Release
On Wed, Apr 1, 2009 at 9:37 AM, Felix Meschberger wrote: > ...I assume that, given the vote passes, we should release Sling next week Shouldn't we rather ask which issues need to (or can easily be) solved before releasing? (and I also have a POLL coming up w.r.t scripting in general, but that might be for after the release) I went through our oustanding issues, here's the ones that I feel might go into our next release: SLING-893 Pipeline support - still in the whiteboard, right? I'm going to test it today. SLING-887 Include Dojo 1.2.3 SLING-884 [PATCH] Sling Commons Java Compiler SLING-849 Enhance SlingAuthenticator's handler selection mechanism - can probably be closed SLING-868 NPE in SlingAuthenticator.findApplicableAuthenticationHandler (ugly) SLING-845 Full build with integration test leaves sling folder in root SLING-829 Cosmetic: Clean up bundle and configuration names SLING-880 Pluggable AccessManager (suggested by Vidar) I'm not saying all of those must go into the release, but I think we should evaluate them. -Bertrand
[jira] Created: (SLING-906) Namespaces mapping mangels query string
Namespaces mapping mangels query string --- Key: SLING-906 URL: https://issues.apache.org/jira/browse/SLING-906 Project: Sling Issue Type: Bug Affects Versions: JCR Resource 2.0.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Resource 2.0.4 The namespace mangeling in the jcr resource resolver does not remove the query string before mangeling the path which results in broken urls if the query string contains a colon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [RT] docs should be in bundles
Hi, I'm not happy about including these things into the bundle. And I'm also not sure about having the docs in svn - but that's the old discussion about the better way of editing/maintaining the docs (svn vs. wiki etc.) Let's keep the stuff separate, we have a bundle jar, a source jar, a javadoc jar and maybe the docs jar. If someone needs all of these as a single archive it's easy to create one out of those artifacts. Carsten Bertrand Delacretaz wrote: > Hi, > > Considering we're aiming for individual release cycles for our bundles > (or groups of bundles), I think the only sane way for docs to be in > sync with the bundles is to have those docs *inside* the bundles. And > maintain them alongside the source code. > > Bundle jars could store docs (in simple unstyled HTML or APT format) > under /SLING-INF/docs for example, and a service would pick them up > and dynamically assemble documentation pages for the current > combination of bundles that is installed, available under > /system/sling/docs. > > Doc paths from that page should be normalized to contain the bundle > symbolic ID and version, for example > > /system/sling/docs/bundles/org.apache.sling.servlets.get/2.0.2/ > > And the same for javadocs, /system/sling/docs/javadocs/... > > This will make our bundles a bit larger (thought we don't have tons of > docs ATM ;-), to get a feel I tried putting the javadocs and the > current website pages that relate to the > org.apache.sling.servlets.post bundle in a jar, resulting compressed > size is 77kBytes, that's not too bad, though that bundle jar is > currently 62kBytes, so including docs would more than double it. But > the convenience trumps the size increase, IMO. And providing a tool, > or build profile, that strips the docs from bundles is not hard. > > We might need some javadocs customization to create links to > interfaces that are in different bundles, and I'm not sure how to > handle the "2.0.2" version number in the above path for this. Maybe > provide a "current" alias to this for such links, that redirects to > the actual version being installed. > > The reference docs part of the website can then be generated by > running Sling with the current set of bundles, and spidering the docs > starting at /system/sling/docs. > > We can discuss the details of course, but WDYT about the general idea? > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: [RT] docs should be in bundles
Btw, first I thought this is an aprils fool joke :) Carsten Bertrand Delacretaz wrote: > Hi, > > Considering we're aiming for individual release cycles for our bundles > (or groups of bundles), I think the only sane way for docs to be in > sync with the bundles is to have those docs *inside* the bundles. And > maintain them alongside the source code. > > Bundle jars could store docs (in simple unstyled HTML or APT format) > under /SLING-INF/docs for example, and a service would pick them up > and dynamically assemble documentation pages for the current > combination of bundles that is installed, available under > /system/sling/docs. > > Doc paths from that page should be normalized to contain the bundle > symbolic ID and version, for example > > /system/sling/docs/bundles/org.apache.sling.servlets.get/2.0.2/ > > And the same for javadocs, /system/sling/docs/javadocs/... > > This will make our bundles a bit larger (thought we don't have tons of > docs ATM ;-), to get a feel I tried putting the javadocs and the > current website pages that relate to the > org.apache.sling.servlets.post bundle in a jar, resulting compressed > size is 77kBytes, that's not too bad, though that bundle jar is > currently 62kBytes, so including docs would more than double it. But > the convenience trumps the size increase, IMO. And providing a tool, > or build profile, that strips the docs from bundles is not hard. > > We might need some javadocs customization to create links to > interfaces that are in different bundles, and I'm not sure how to > handle the "2.0.2" version number in the above path for this. Maybe > provide a "current" alias to this for such links, that redirects to > the actual version being installed. > > The reference docs part of the website can then be generated by > running Sling with the current set of bundles, and spidering the docs > starting at /system/sling/docs. > > We can discuss the details of course, but WDYT about the general idea? > > -Bertrand > -- Carsten Ziegeler cziege...@apache.org
Re: [RT] docs should be in bundles
Bertrand Delacretaz wrote: > On Wed, Apr 1, 2009 at 8:58 AM, Carsten Ziegeler wrote: > >> ... I'm not happy about including these things into the bundle. And I'm also >> not sure about having the docs in svn - but that's the old discussion >> about the better way of editing/maintaining the docs (svn vs. wiki etc.)... > > I think it would be very hard to keep things in sync between svn and > the wiki, once our bundles have independent release cycles. Call me > pessimistic but I don't think we'd manage. > > We can still use the wiki for general/overview docs (though that might > also be an "overview" bundle with just docs), and use the bundle-based > docs for the reference stuff. > >> ...Let's keep the stuff separate, we have a bundle jar, a source jar, a >> javadoc jar and maybe the docs jar. If someone needs all of these as a >> single archive it's easy to create one out of those artifacts > > That might work, and what do you think about generating the docs of a > particular Sling instance based on which bundles are installed? I > think that's the key point in my proposal, exactly where the docs come > from is more an implementation detail. > > With docs in a separate bundle, the docs service would need to list > bundles for which there's no corresponding "docs" bundle installed, > that shouldn't be too hard to do based on conventions on bundle > symbolic names (i.e. foo.slingdocs is the docs of the foo bundle). And > with an OBR (http://www.osgi.org/Repository/HomePage), docs bundles > could be downloaded semi-automatically. > > -Bertrand (and I'm very serious BTW, as usual ;-) Yes, I know :) Ok, I think this can be handled easily: if the docs are in a separate artifact which is in a Maven repository, we can write a simple module which downloads and extracts all available docs bundle for the installed bundles. This could be done at runtime of the system - or we could write a maven plugin which just aggregates the javadocs for all included bundles. Keeping these things separate (code from docs) seems to me the better way to handle it; it's easier to aggregate stuff later on then to separate it. Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Created: (SLING-907) Rename SimpleWebDavServlet to avoid confusion with Jackrabbit's
Rename SimpleWebDavServlet to avoid confusion with Jackrabbit's --- Key: SLING-907 URL: https://issues.apache.org/jira/browse/SLING-907 Project: Sling Issue Type: Improvement Affects Versions: JCR Webdav 2.0.2 Reporter: Bertrand Delacretaz Priority: Minor Fix For: JCR Webdav 2.0.4 Discussed in http://markmail.org/message/mzw5p6ydarklwsyb I'll rename to SlingSimpleWebDavServlet, as SlingWebDavServlet is already used -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Renaming SlingWebDavServlet? (was: SlingWebDavServlet serves resource not only below /dav?)
On Wed, Apr 1, 2009 at 9:48 AM, Felix Meschberger wrote: > ...I have no issue with renaming this servlet for clarity sake, but > SlingWebDavServlet is already taken ;-)... Ok, thanks for clarifying, hadn't noticed that. > ...We could really name SlingSimpleWebDavServlet to indicate it works the > same as the Jackrabbit SimpleWebDavServlet but it is located in Sling Ok sounds good, name's a bit long but no big deal. Created https://issues.apache.org/jira/browse/SLING-907, I'll do that today. -Bertrand
[POLL] getting rid of scripting (almost)
(feel like POLLing and RTing these days - catching up with my Sling stuff ;-) Hi, The more I talk to Carsten, the more I realize that he and others are right - scripting is evil. Untyped variables, poorly-specified languages, weird "I told you we're dynamic" bugs...this does not really fit with our Enterprise strategy for Sling. With one exception, maybe...due to its inherent type safety, and available enterprise-level tooling, JSP is probably the only scripting language that deserves to stay. As this might be a bit controversial, I'm starting with a [POLL] - the idea would be to remove (or at least deprecate, as a first step) the pluggability of script engines, and keep only the JSP engine. Or maybe just keep a handful of "officially approved" script engines, marked as such with a cryptographically-safe value (based on a secret key shared by Sling PMC members only) in their manifest file. People can then move their code to Java servlets and maybe some JSP, enjoying the reduced number of bugs along the way. Or request their favorite scripting language to be validated, but we'd then need to define a test suite to verify our enterprise-level requirements for languages besides JSP. If we disagree on this (I hope we don't), we might envision two variants of Sling: the Enterprise version with no scripting (except JSP and validated engines, as indicated), and the shoot-yourself-in-the-foot version with no restrictions. And re-evaluate in a year from now. We might want to make a decision on this *before* our next release, to avoid having to deprecate stuff right after it. But right now this is just a [POLL] to gather opinions. WDYT? -Bertrand
Re: Sling Release
I think we should just update to the latest Felix framework and then release. Everything else can be fixed later on. With bundles we can just release separate bundles frequently. The only real issue I see atm are the failing tests. Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Closed: (SLING-906) Namespaces mapping mangels query string
[ https://issues.apache.org/jira/browse/SLING-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-906. -- Resolution: Fixed The query string is now removed before the mangeling and appended afterwards (rev. 760811) > Namespaces mapping mangels query string > --- > > Key: SLING-906 > URL: https://issues.apache.org/jira/browse/SLING-906 > Project: Sling > Issue Type: Bug >Affects Versions: JCR Resource 2.0.4 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.0.4 > > > The namespace mangeling in the jcr resource resolver does not remove the > query string before mangeling the path which results in broken urls if the > query string contains a colon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [POLL] getting rid of scripting (almost)
On Wed 01 Apr 2009 16:05, Bertrand Delacretaz wrote: > The more I talk to Carsten, the more I realize that he and others are > right - scripting is evil. > > Untyped variables, poorly-specified languages, weird "I told you we're > dynamic" bugs...this does not really fit with our Enterprise strategy > for Sling. I'm mostly interested in Sling because of the options for scripting. I've very little interest in actually writing Java any more these days. I didn't realize Sling was focusing exclusively on enterprise. IMHO sling could bring in plenty of non-Java users just like most CouchDB users doesn't use (or even know) Erlang. -- J Aaron Farr jadetower.com[US] +1 724-964-4515 馮傑仁 cubiclemuses.com [HK] +852 8123-7905
Re: [POLL] getting rid of scripting (almost)
Bertrand Delacretaz wrote: > The more I talk to Carsten, the more I realize that he and others are > right - scripting is evil. Hurray - welcome on board the ihatescripting club! It's a very exclusive club though and we have a very difficult entrance test (write a blog application without scripting). But I guess you'll manage that easily. Just send me the code when you're done and you can enjoy the benefits of never scripting again in your life! That's really awesome - trust me. > Untyped variables, poorly-specified languages, weird "I told you we're > dynamic" bugs...this does not really fit with our Enterprise strategy > for Sling. > > With one exception, maybe...due to its inherent type safety, and > available enterprise-level tooling, JSP is probably the only scripting > language that deserves to stay. Hmm, what about the good old XSP from Cocoon? I think we should replace JSP with that. > If we disagree on this (I hope we don't), we might envision two > variants of Sling: the Enterprise version with no scripting (except > JSP and validated engines, as indicated), and the > shoot-yourself-in-the-foot version with no restrictions. And > re-evaluate in a year from now. Wow, that's a great idea - I can already imagine the Apache Sling SYITF distribution. Yes, big +1 Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [POLL] getting rid of scripting (almost)
Hi, +1 Good proposal! We don't want all those script kiddies ruining the good name of Sling 2.0.0 Enterprise Edition, S2EE. On Wed, Apr 1, 2009 at 10:05 AM, Bertrand Delacretaz wrote: > With one exception, maybe...due to its inherent type safety, and > available enterprise-level tooling, JSP is probably the only scripting > language that deserves to stay. I would suggest that we only allow JSP documents using the XML syntax. Those pesky % characters are evil as noted also by Vidar in a different thread. Also, I propose that we disable the element. All such code should be placed in tag libraries as proper Java classes. BR, Jukka Zitting
Re: [POLL] getting rid of scripting (almost)
+1 if we make Whitespace [1] the primary language for Sling. +0 otherwise Michael [1] http://compsoc.dur.ac.uk/whitespace/ Bertrand Delacretaz wrote: (feel like POLLing and RTing these days - catching up with my Sling stuff ;-) Hi, The more I talk to Carsten, the more I realize that he and others are right - scripting is evil. Untyped variables, poorly-specified languages, weird "I told you we're dynamic" bugs...this does not really fit with our Enterprise strategy for Sling. With one exception, maybe...due to its inherent type safety, and available enterprise-level tooling, JSP is probably the only scripting language that deserves to stay. As this might be a bit controversial, I'm starting with a [POLL] - the idea would be to remove (or at least deprecate, as a first step) the pluggability of script engines, and keep only the JSP engine. Or maybe just keep a handful of "officially approved" script engines, marked as such with a cryptographically-safe value (based on a secret key shared by Sling PMC members only) in their manifest file. People can then move their code to Java servlets and maybe some JSP, enjoying the reduced number of bugs along the way. Or request their favorite scripting language to be validated, but we'd then need to define a test suite to verify our enterprise-level requirements for languages besides JSP. If we disagree on this (I hope we don't), we might envision two variants of Sling: the Enterprise version with no scripting (except JSP and validated engines, as indicated), and the shoot-yourself-in-the-foot version with no restrictions. And re-evaluate in a year from now. We might want to make a decision on this *before* our next release, to avoid having to deprecate stuff right after it. But right now this is just a [POLL] to gather opinions. WDYT? -Bertrand
Re: [POLL] getting rid of scripting (almost)
On Wed, Apr 1, 2009 at 10:49 AM, Michael Dürig wrote: > +1 if we make Whitespace [1] the primary language for Sling. > > [1] http://compsoc.dur.ac.uk/whitespace/ +1 I took a look at Whitespace, and liked it so much that I decided to port the entire Sling codebase to it. I'm sure you will agree, so as soon as I get my svn account, I'll start replacing the ugly, old-fashioned Java classes with clean, white Whitespace files. -- Vidar S. Ramdal - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway +47 21 531941, ext 2070
Re: [POLL] getting rid of scripting (almost)
Hi, Jukka Zitting schrieb: > Hi, > > +1 Good proposal! We don't want all those script kiddies ruining the > good name of Sling 2.0.0 Enterprise Edition, S2EE. > > On Wed, Apr 1, 2009 at 10:05 AM, Bertrand Delacretaz > wrote: >> With one exception, maybe...due to its inherent type safety, and >> available enterprise-level tooling, JSP is probably the only scripting >> language that deserves to stay. > > I would suggest that we only allow JSP documents using the XML syntax. > Those pesky % characters are evil as noted also by Vidar in a > different thread. > > Also, I propose that we disable the element. All such > code should be placed in tag libraries as proper Java classes. While being at it, we should of course also forbid JSTL and EL support. Regards Felix
Re: [POLL] getting rid of scripting (almost)
On Wed 01 Apr 2009 16:05, Bertrand Delacretaz wrote: > WDYT? I think I'm going to quit replying to Bertand until April 2nd. I can't tell which of his emails are serious and which aren't. I'm still not sure about this one. :-) -- J Aaron Farr jadetower.com[US] +1 724-964-4515 馮傑仁 cubiclemuses.com [HK] +852 8123-7905
Re: [POLL] getting rid of scripting (almost)
Hi, Vidar Ramdal schrieb: > On Wed, Apr 1, 2009 at 10:49 AM, Michael Dürig wrote: > >> +1 if we make Whitespace [1] the primary language for Sling. >> >> [1] http://compsoc.dur.ac.uk/whitespace/ > > +1 > > I took a look at Whitespace, and liked it so much that I decided to > port the entire Sling codebase to it. > > I'm sure you will agree, so as soon as I get my svn account, I'll > start replacing the ugly, old-fashioned Java classes with clean, white > Whitespace files. If you like clean languages you should consider my new Null proposal [1] currently being discussed. It is based on the Null programming language. Regards Felix [1] http://wiki.apache.org/incubator/NullProposal
Re: [POLL] getting rid of scripting (almost)
On Wed, Apr 1, 2009 at 10:55 AM, J Aaron Farr wrote: > ...I think I'm going to quit replying to Bertand until April 2nd. I can't > tell which of his emails are serious and which aren't. I'm still not > sure about this one I'm sure Carsten would like it to be serious, but I'm a big fan of scripting languages ;-) -Bertrand
Re: [POLL] getting rid of scripting (almost)
Well I think sling should be changed to work with flat file systems instead of JCR. Putting data into a typed node tree puts too many constraints on what data we can put into it. 2009/4/1 Felix Meschberger > Hi, > > Vidar Ramdal schrieb: > > On Wed, Apr 1, 2009 at 10:49 AM, Michael Dürig > wrote: > > > >> +1 if we make Whitespace [1] the primary language for Sling. > >> > >> [1] http://compsoc.dur.ac.uk/whitespace/ > > > > +1 > > > > I took a look at Whitespace, and liked it so much that I decided to > > port the entire Sling codebase to it. > > > > I'm sure you will agree, so as soon as I get my svn account, I'll > > start replacing the ugly, old-fashioned Java classes with clean, white > > Whitespace files. > > If you like clean languages you should consider my new Null proposal [1] > currently being discussed. It is based on the Null programming language. > > Regards > Felix > > [1] http://wiki.apache.org/incubator/NullProposal > >
Re: [POLL] getting rid of scripting (almost)
Hi Bertrand, I see you are making progress. It looks like the fresh icelandic air is good for you. I totally agree that scripting is evil and that we need to make changes in order to make Sling more enterprise ready. But we should go all the way: 1) the JVM is interpreting bytecode, which is just scripting in disguise. Do not fall for the 'Write once run everywhere' and the alleged agility you get from a garbage collector. 2) to be ready for Enterprise use, we should use a Common Business-Oriented Language, or COBOL for that matter. I am sure the Sling community will catch up quickly with these changes and a re-implementation will take less than a decade or two. regards, Lars On Wed, Apr 1, 2009 at 10:05 AM, Bertrand Delacretaz wrote: > (feel like POLLing and RTing these days - catching up with my Sling stuff ;-) > > Hi, > > The more I talk to Carsten, the more I realize that he and others are > right - scripting is evil. > > Untyped variables, poorly-specified languages, weird "I told you we're > dynamic" bugs...this does not really fit with our Enterprise strategy > for Sling. > > With one exception, maybe...due to its inherent type safety, and > available enterprise-level tooling, JSP is probably the only scripting > language that deserves to stay. > > As this might be a bit controversial, I'm starting with a [POLL] - the > idea would be to remove (or at least deprecate, as a first step) the > pluggability of script engines, and keep only the JSP engine. Or maybe > just keep a handful of "officially approved" script engines, marked as > such with a cryptographically-safe value (based on a secret key shared > by Sling PMC members only) in their manifest file. > > People can then move their code to Java servlets and maybe some JSP, > enjoying the reduced number of bugs along the way. Or request their > favorite scripting language to be validated, but we'd then need to > define a test suite to verify our enterprise-level requirements for > languages besides JSP. > > If we disagree on this (I hope we don't), we might envision two > variants of Sling: the Enterprise version with no scripting (except > JSP and validated engines, as indicated), and the > shoot-yourself-in-the-foot version with no restrictions. And > re-evaluate in a year from now. > > We might want to make a decision on this *before* our next release, to > avoid having to deprecate stuff right after it. But right now this is > just a [POLL] to gather opinions. > > WDYT? > > -Bertrand > -- Lars Trieloff - http://lars.mp - Day Software - http://www.day.com
Re: [POLL] getting rid of scripting (almost)
Excellent proposal! Very timely! +1. Scripting is evil. regards, david On Wed, Apr 1, 2009 at 11:11 AM, Torgeir Veimo wrote: > Well I think sling should be changed to work with flat file systems instead > of JCR. Putting data into a typed node tree puts too many constraints on > what data we can put into it. > > 2009/4/1 Felix Meschberger > >> Hi, >> >> Vidar Ramdal schrieb: >> > On Wed, Apr 1, 2009 at 10:49 AM, Michael Dürig >> wrote: >> > >> >> +1 if we make Whitespace [1] the primary language for Sling. >> >> >> >> [1] http://compsoc.dur.ac.uk/whitespace/ >> > >> > +1 >> > >> > I took a look at Whitespace, and liked it so much that I decided to >> > port the entire Sling codebase to it. >> > >> > I'm sure you will agree, so as soon as I get my svn account, I'll >> > start replacing the ugly, old-fashioned Java classes with clean, white >> > Whitespace files. >> >> If you like clean languages you should consider my new Null proposal [1] >> currently being discussed. It is based on the Null programming language. >> >> Regards >> Felix >> >> [1] http://wiki.apache.org/incubator/NullProposal >> >> > -- Visit: http://dev.day.com/
Re: [POLL] getting rid of scripting (almost)
Bertrand Delacretaz wrote: > On Wed, Apr 1, 2009 at 10:55 AM, J Aaron Farr wrote: >> ...I think I'm going to quit replying to Bertand until April 2nd. I can't >> tell which of his emails are serious and which aren't. I'm still not >> sure about this one > > I'm sure Carsten would like it to be serious, but I'm a big fan of > scripting languages ;-) > Ok, I guess in this case the doors of the ihatescripting club will always be closed for you..sorry :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Sling Release
> SLING-893 Pipeline support - still in the whiteboard, right? I'm going > to test it today. As discussed in [1], pipeline support stuff has been already saved in contrib [2]. I´m going to close SLING-893 and open new issues for enhancements. BTW, we have some contrib tests failing too (SLING-869 [3]). Juanjo. [1] http://markmail.org/thread/33h5nhk5e3mswrue [2] http://svn.apache.org/repos/asf/incubator/sling/trunk/contrib/scripting/xproc [3] https://issues.apache.org/jira/browse/SLING-869
Re: [POLL] getting rid of scripting (almost)
Lars Trieloff wrote: > Hi Bertrand, > > I see you are making progress. It looks like the fresh icelandic air > is good for you. I totally agree that scripting is evil and that we > need to make changes in order to make Sling more enterprise ready. But > we should go all the way: > > 1) the JVM is interpreting bytecode, which is just scripting in > disguise. Do not fall for the 'Write once run everywhere' and the > alleged agility you get from a garbage collector. > 2) to be ready for Enterprise use, we should use a Common > Business-Oriented Language, or COBOL for that matter. > > I am sure the Sling community will catch up quickly with these changes > and a re-implementation will take less than a decade or two. > I we really want to go all the way we should rather create a DSL for Sling or provide the tooling so users can create their own DSL based on Sling. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [POLL] getting rid of scripting (almost)
> 1) the JVM is interpreting bytecode, which is just scripting in > disguise. Do not fall for the 'Write once run everywhere' and the > alleged agility you get from a garbage collector. > 2) to be ready for Enterprise use, we should use a Common > Business-Oriented Language, or COBOL for that matter. Regarding this, IMHO JVM is a strong requirement for Sling. I see a Sling distribution running on my ZX Spectrum 48K [1] (all in my dreams) :). Juanjo. [1] http://en.wikipedia.org/wiki/Sinclair_ZX_Spectrum
Re: [POLL] getting rid of scripting (almost)
2009/4/1 Juan José Vázquez Delgado > > > 1) the JVM is interpreting bytecode, which is just scripting in > > disguise. Do not fall for the 'Write once run everywhere' and the > > alleged agility you get from a garbage collector. > > 2) to be ready for Enterprise use, we should use a Common > > Business-Oriented Language, or COBOL for that matter. > > Regarding this, IMHO JVM is a strong requirement for Sling. I see a > Sling distribution running on my ZX Spectrum 48K [1] (all in my > dreams) :). Hmm, you all are too short-sighted: In my opinion, all this software stuff is way too fragile and dynamic. I want a dedicated Sling processor for my computer (let's call it CMS-DSP - Content Management System Digital Signal Processor). A benefit would be the major performance improvement, especially if we would finally hardwire the content structure (/content, /apps, /libs etc.) into dedicated flash memory. WDYT? Anyone with a degree in modern chip design on the list? Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: [POLL] getting rid of scripting (almost)
On Wed, Apr 1, 2009 at 10:56 AM, Felix Meschberger wrote: > If you like clean languages you should consider my new Null proposal [1] > currently being discussed. It is based on the Null programming language. > [1] http://wiki.apache.org/incubator/NullProposal Interesting project proposal... But I am not so sure where the mails would go if I send them to the dev-null@ mailing list. ;-) Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: [POLL] getting rid of scripting (almost)
Carsten Ziegeler wrote: Bertrand Delacretaz wrote: The more I talk to Carsten, the more I realize that he and others are right - scripting is evil. ... With one exception, maybe...due to its inherent type safety, and available enterprise-level tooling, JSP is probably the only scripting language that deserves to stay. Hmm, what about the good old XSP from Cocoon? I think we should replace JSP with that. No, no, no. Neither of those are fun (although Fan might be). I'm sure the key to making this a huge hit is to use LOLCODE as the singular scripting language for Sling! We'll probably need to make a few extensions, but that is to be expected with such a new and innovative language. http://lolcode.com/ I can see it now, whole floors of cubicles with everyone ROFLTAO. And no more stressful code reviews, just constant giggling. A, the best code metric ever, the laugh meter level! Jim
[jira] Resolved: (SLING-900) Missing method AccessControlUtil.isAllow
[ https://issues.apache.org/jira/browse/SLING-900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James P. White resolved SLING-900. -- Resolution: Duplicate > Missing method AccessControlUtil.isAllow > > > Key: SLING-900 > URL: https://issues.apache.org/jira/browse/SLING-900 > Project: Sling > Issue Type: Bug > Components: JCR > Environment: Maven version: 2.0.9 > Java version: 1.5.0_16 > OS name: "mac os x" version: "10.5.6" arch: "i386" Family: "unix" >Reporter: James P. White > Attachments: error.log, > org.apache.sling.launchpad.webapp.integrationtest.accessManager.ModifyAceTest.txt, > > org.apache.sling.launchpad.webapp.integrationtest.accessManager.RemoveAcesTest.txt, > patch-clean-base-jar.txt > > > Tests fail for me with a MissingMethod exception for > AccessControlUtil.isAllow. > Quite odd since compilation is fine, so something in classpath is off. > Tried every sort of clean build, including clearing Maven cache for > org.apache.sling and using and not using a settings.xml as in > http://incubator.apache.org/sling/site/getting-and-building-sling.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
FYI: current trunk requires Felix 1.6 to run, here's how
Hi, Due to the changes of SLING-905, current trunk won't start, or rather stays at run level 1, which is not much ;-) FYI, to get it to work I had to use this patch: Index: launchpad/base/pom.xml === --- launchpad/base/pom.xml (revision 760866) +++ launchpad/base/pom.xml (working copy) @@ -187,7 +187,7 @@ org.apache.felix org.apache.felix.framework -1.5.0-SNAPSHOT +1.6.0 provided And install the http://people.apache.org/~pauls/1.6.0/org.apache.felix.framework-1.6.0.jar manually in my local Maven repository. -Bertrand
[jira] Updated: (SLING-845) Full build with integration test leaves sling folder in root
[ https://issues.apache.org/jira/browse/SLING-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James P. White updated SLING-845: - Attachment: patch-clean-sling-dir.txt This doesn't relocate the sling dir to our target, but it does solve the related staleness problem (SLING-900) by removing it on clean. > Full build with integration test leaves sling folder in root > > > Key: SLING-845 > URL: https://issues.apache.org/jira/browse/SLING-845 > Project: Sling > Issue Type: Bug > Components: Launchpad >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Attachments: patch-clean-sling-dir.txt > > > When running a full build from trunk root including the integration tests, > the sling directory used by the integration test web app is placed in the > root folder. It would be better if this directory would be located in the > target folder of the launchpad/testing module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-907) Rename SimpleWebDavServlet to avoid confusion with Jackrabbit's
[ https://issues.apache.org/jira/browse/SLING-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz closed SLING-907. - Resolution: Fixed Done, in revision 760869 the servlet is named SlingSimpleWebDavServlet > Rename SimpleWebDavServlet to avoid confusion with Jackrabbit's > --- > > Key: SLING-907 > URL: https://issues.apache.org/jira/browse/SLING-907 > Project: Sling > Issue Type: Improvement >Affects Versions: JCR Webdav 2.0.2 >Reporter: Bertrand Delacretaz >Priority: Minor > Fix For: JCR Webdav 2.0.4 > > > Discussed in http://markmail.org/message/mzw5p6ydarklwsyb > I'll rename to SlingSimpleWebDavServlet, as SlingWebDavServlet is already used -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [POLL] getting rid of scripting (almost)
Juan José Vázquez Delgado schrieb: 1) the JVM is interpreting bytecode, which is just scripting in disguise. Do not fall for the 'Write once run everywhere' and the alleged agility you get from a garbage collector. 2) to be ready for Enterprise use, we should use a Common Business-Oriented Language, or COBOL for that matter. Regarding this, IMHO JVM is a strong requirement for Sling. I see a Sling distribution running on my ZX Spectrum 48K [1] (all in my dreams) :). I had one too – I (kind-of) learned BASIC programming on this box. I'd volunteer to implement the MagneticTapePersistenceManager for Jackrabbit if you're planning to migrate Sling to the ZX platform. -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
Configure HTTPS on sling (on top of jetty)
Hi, I have a requirement where I need to configure HTTPS on sling which is running on jetty web server. I have checked the mailing list as well as the documentation but no great help as such. If anybody done this configuration before / have any input on this would be of great help. Regards, Sujoy Bhattacharjee
[jira] Updated: (SLING-893) Pipeline support
[ https://issues.apache.org/jira/browse/SLING-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-893: -- Component/s: (was: Extensions) Xproc > Pipeline support > > > Key: SLING-893 > URL: https://issues.apache.org/jira/browse/SLING-893 > Project: Sling > Issue Type: Improvement > Components: Xproc >Affects Versions: 3 >Reporter: Juan Jose Vazquez Delgado >Assignee: Juan Jose Vazquez Delgado > Original Estimate: 0h > Remaining Estimate: 0h > > As discussed in [1] we should have some sort of pipeline support in Sling. > This stuff will be provided as a contrib or extension. > [1] http://markmail.org/thread/33h5nhk5e3mswrue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-908) Xproc response does not indicate errors
Xproc response does not indicate errors --- Key: SLING-908 URL: https://issues.apache.org/jira/browse/SLING-908 Project: Sling Issue Type: Bug Components: Xproc Reporter: Bertrand Delacretaz Priority: Minor Trying the xproc scripting engine with an invalid xpl script produces an empty response with a 200 ok status code. The cause is the PipelineImpl class, which retrieves the OutputStream from the SlingHttpServletResponse. When an error handler tries to do the same later on to report the error, it gets an "OutputStream already retrieved" exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-908) Xproc response does not indicate errors
[ https://issues.apache.org/jira/browse/SLING-908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz closed SLING-908. - Resolution: Fixed In revision 760899, pipeline errors are reported with an HTTP 500 response with more detailed exception reports > Xproc response does not indicate errors > --- > > Key: SLING-908 > URL: https://issues.apache.org/jira/browse/SLING-908 > Project: Sling > Issue Type: Bug > Components: Xproc >Reporter: Bertrand Delacretaz >Priority: Minor > > Trying the xproc scripting engine with an invalid xpl script produces an > empty response with a 200 ok status code. > The cause is the PipelineImpl class, which retrieves the OutputStream from > the SlingHttpServletResponse. When an error handler tries to do the same > later on to report the error, it gets an "OutputStream already retrieved" > exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-908) Xproc response does not indicate errors
[ https://issues.apache.org/jira/browse/SLING-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694548#action_12694548 ] Juan Jose Vazquez Delgado commented on SLING-908: - Good point. Thanks for fixing it. > Xproc response does not indicate errors > --- > > Key: SLING-908 > URL: https://issues.apache.org/jira/browse/SLING-908 > Project: Sling > Issue Type: Bug > Components: Xproc >Reporter: Bertrand Delacretaz >Priority: Minor > > Trying the xproc scripting engine with an invalid xpl script produces an > empty response with a 200 ok status code. > The cause is the PipelineImpl class, which retrieves the OutputStream from > the SlingHttpServletResponse. When an error handler tries to do the same > later on to report the error, it gets an "OutputStream already retrieved" > exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-893) Pipeline support
[ https://issues.apache.org/jira/browse/SLING-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Jose Vazquez Delgado resolved SLING-893. - Resolution: Fixed First version in [1]. Close this issue and open new ones for bugs and enhancements. [1] http://svn.apache.org/repos/asf/incubator/sling/trunk/contrib/scripting/xproc > Pipeline support > > > Key: SLING-893 > URL: https://issues.apache.org/jira/browse/SLING-893 > Project: Sling > Issue Type: Improvement > Components: Xproc >Affects Versions: 3 >Reporter: Juan Jose Vazquez Delgado >Assignee: Juan Jose Vazquez Delgado > Original Estimate: 0h > Remaining Estimate: 0h > > As discussed in [1] we should have some sort of pipeline support in Sling. > This stuff will be provided as a contrib or extension. > [1] http://markmail.org/thread/33h5nhk5e3mswrue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Cocoon pipelines in Sling, using XPL - thanks Juanjo! (was: Sling Release)
Hi, 2009/4/1 Juan José Vázquez Delgado : > Bertrand said: >> SLING-893 Pipeline support - still in the whiteboard, right? I'm going >> to test it today. > > As discussed in [1], pipeline support stuff has been already saved in > contrib [2]. I´m going to close SLING-893 and open new issues for > enhancements Great, thanks! I made minor improvements to error reporting (SLING-908), below are some notes about how to use this - we'll need to turn this (or better examples) into some docs later on. For now, just saving this here. Cool stuff! -Bertrand Example using the xproc script engine - rough notes: 1) Install the org.apache.sling.scripting.xproc bundle (found in contrib/scripting/xproc) 2) Create some content: $ curl -F sling:resourceType=xproc -F title="some title" -F text="And some text" http://admin:ad...@localhost:/foo 3) Create a pipeline script at /apps/xproc/xproc.xpl: http://www.w3.org/ns/xproc";> 4) Store the XSLT transforms in the repository: /apps/xproc/one.xsl: http://www.w3.org/1999/XSL/Transform"; > /apps/xproc/two.xsl: http://www.w3.org/1999/XSL/Transform"; > 5) Request foo.html to execute the pipeline: $ curl http://admin:ad...@localhost:/foo.html
[jira] Commented: (SLING-869) Three tests fail in contrib integration tests
[ https://issues.apache.org/jira/browse/SLING-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694587#action_12694587 ] Bertrand Delacretaz commented on SLING-869: --- I had a quick look and SimpleAptRenderingTest is failing because the apt parser and servlet bundles are not installed. Gotta run now, but that will be easy to fix. > Three tests fail in contrib integration tests > - > > Key: SLING-869 > URL: https://issues.apache.org/jira/browse/SLING-869 > Project: Sling > Issue Type: Bug > Components: Testing > Environment: macosx, JDK 1.6.0_07 >Reporter: Bertrand Delacretaz > > mvn clean install in contrib fails for me: > [INFO] Building Apache Sling Launchpad Contrib Testing > ... > [ > Failed tests: > > testAptDocument(org.apache.sling.launchpad.webapp.integrationtest.apt.SimpleAptRenderingTest) > > testGetStarWithScript(org.apache.sling.launchpad.webapp.integrationtest.GetStarTest) > > testDefaultResourceType(org.apache.sling.launchpad.webapp.integrationtest.PathBasedResourceTypeTest) > Haven't investigated yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-884) [PATCH] Sling Commons Java Compiler
[ https://issues.apache.org/jira/browse/SLING-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-884. -- Resolution: Fixed Assignee: Carsten Ziegeler Hi Stefan, thanks for the patch; I've appled it in revision 760958. > [PATCH] Sling Commons Java Compiler > --- > > Key: SLING-884 > URL: https://issues.apache.org/jira/browse/SLING-884 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Stefan Guggisberg >Assignee: Carsten Ziegeler >Priority: Minor > Attachments: org.apache.sling.commons.compiler.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Cocoon pipelines in Sling, using XPL - thanks Juanjo! (was: Sling Release)
>>> SLING-893 Pipeline support - still in the whiteboard, right? I'm going >>> to test it today. >> >> As discussed in [1], pipeline support stuff has been already saved in >> contrib [2]. I´m going to close SLING-893 and open new issues for >> enhancements > > Great, thanks! > > I made minor improvements to error reporting (SLING-908), below are > some notes about how to use this - we'll need to turn this (or better > examples) into some docs later on. For now, just saving this here. > Cool stuff! wow, thnks!. > Example using the xproc script engine - rough notes: >. Cool sample. I hope to have samples and more improvements soon. Regards, Juanjo.
JSR-283 Proposed Final Draft posted, waiting for download fix.
Dear Jackrabbit-Devs & Sling-Devs, as you may have seen JSR-283 has been posted for proposed final draft. http://jcp.org/aboutJava/communityprocess/pfd/jsr283/index.html Unfortunately, there seems to be an error in the posting since the download link on the page results in a "Not Found Error". I alerted the PMO of the JCP at Sun this morning CET. The PMO (Project Management Office) is administrating all JSRs and is responsible for posting the proposed final draft. I will keep you posted on the progress. regards, david
Re: JSR-283 Proposed Final Draft posted, waiting for download fix.
Good news ;) I am happy announce on behalf of the JSR-283 Expert Group that JSR-283 is out for Proposed Final Draft review. http://jcp.org/aboutJava/communityprocess/pfd/jsr283/index.html There are a lot new and exciting features in the specification and changed the structure of the specification to make a big section Java Language since a lot of you ported JCR outside of the Java Language. For a little more information, visit: http://dev.day.com/microsling/content/blogs/main/jsr283proposedfinaldraft.html Feedback is very welcome jsr-283-comme...@jcp.org regards, david On Wed, Apr 1, 2009 at 8:44 PM, David Nuescheler wrote: > Dear Jackrabbit-Devs & Sling-Devs, > > as you may have seen JSR-283 has been posted for proposed final draft. > http://jcp.org/aboutJava/communityprocess/pfd/jsr283/index.html > > Unfortunately, there seems to be an error in the posting since the > download link on the page results in a "Not Found Error". > I alerted the PMO of the JCP at Sun this morning CET. > The PMO (Project Management Office) is administrating all JSRs and is > responsible for posting the proposed final draft. > > I will keep you posted on the progress. > > regards, > david > -- Visit: http://dev.day.com/
