Re: svn commit: r1487591 - in /sling/trunk/bundles/extensions/discovery/impl: pom.xml src/main/java/org/apache/sling/discovery/impl/common/heartbeat/HeartbeatHandler.java src/test/java/org/apache/slin
Hi Felix, On 5/29/13 9:52 PM, Felix Meschberger fmesc...@adobe.com wrote: Hi Am 29.05.2013 um 20:54 schrieb stefane...@apache.org stefane...@apache.org: +/** SLING-2892: remember the value of the heartbeat this instance has written the last time **/ +private Calendar lastHeartbeatWritten = null; Is there a reason you use Calendar here ? I have the impression that a long being System.currentTimeMillis would be sufficient. I've chosen to use Calendar for the 'lastHeartbeat' (instead of a long) to have a human readable value. That's basically why then this new field also got the type Calendar, as I simply cache the last 'lastHeartbeat' value. It could of course just cache the long value of the Calendar, agreed. Cheers, Stefan
cwiki.apache.org/SLING not updating
Hi, I noticed that the page from https://cwiki.apache.org/SLING/index.html lags behind https://cwiki.apache.org/confluence/display/SLING/Index . We're missing changes from 5 days ago. Is this something we handle or something for infra to look into? Robert
Re: Apache Cassandra backend for Sling Accepted for GSoC 2013 !
On Wed, May 29, 2013 at 3:06 AM, Ian Boston i...@tfd.co.uk wrote: Hi Dishara, Congratulations you deserve it. Over the next few weeks you should get fully up to speed with Sling and the Sling community, in preparation for starting work in earnest on 17 June. Although I volunteered to mentor you and this project, all Apache projects have community at their core. Sling is no exception. We do everything here through discussion, thinking positive learning from the guidance of each other and looking forwards not backwards. Those of us who have been here a long time know and trust our fellow community members. We also know we learn by making mistakes. Thats what makes Apache so strong. Google has added this two week buffer explicitly to allow students to get to know the community they have become a part of. I know you have already looked into the code base, but I would thoroughly recommend that you do some of the exercises on the website[1], and build a simple application, perhaps a photo sharing app (Slingstagram?), so that you get a real understanding of how Sling works. +1. I think that is good and which i have not tried out yet. I will try this out and will post if need help We do everything on the dev list only very, very rarely resorting to private emails or IM discussions. I am starting to break the primary rule of large lists, keeping each message short and to the point so others have the time to read it. Welcome to Sling, we are all here to help you. Thank you very much. I will discuss everything on dev/user lists and keep posted on everything I am doing regarding GSoC. I will start a separate thread to post GSoC updates. Best Regards Ian 1 http://sling.apache.org/documentation/tutorials-how-tos/46-line-blog.html On 29 May 2013 02:54, Dishara Wijewardana ddwijeward...@gmail.com wrote: Hi, I am ecstatic that Apache Cassandra backend for Sling Accepted for GSoC 2013. Thank you for all the support given as a community for this proposal. I will do my best to finish this project in a high and do a good contribution to Apache Sling. -- Thanks /Dishara -- Thanks /Dishara
[jira] [Assigned] (SLING-2863) unable to use taglib version 1.3 out of the box
[ https://issues.apache.org/jira/browse/SLING-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco reassigned SLING-2863: --- Assignee: Dan Klco unable to use taglib version 1.3 out of the box --- Key: SLING-2863 URL: https://issues.apache.org/jira/browse/SLING-2863 Project: Sling Issue Type: Bug Components: Scripting Reporter: Ondrej Florian Assignee: Dan Klco Priority: Minor Attachments: list.xml.patch, taglib13.tld.patch while trying to use taglib 1.3 : %@taglib prefix=sling uri=http://sling.apache.org/taglibs/sling/1.3; % I am getting error: The absolute uri: http://sling.apache.org/taglibs/sling/1.3 cannot be resolved in either web.xml or the jar files deployed with this application (500) --- the problem seems to be in the header of the taglib13.tld definition (please see the attached patch) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Using Apache Geranimo JSTL
All, While working on getting integration tests set up for the new TagLib functionality, I found that the Apache Geranimo project released a JSTL bundle for their servlet container. http://search.maven.org/#artifactdetails%7Corg.apache.geronimo.bundles%7Cjstl%7C1.2_1%7Cbundle https://issues.apache.org/jira/browse/GERONIMO-2536 Would anyone be opposed to including this bundle in the Launchpad Builder? Unless we need to modify the JSTL code, we could probably shutter the existing Sling JSTL project as well. Right now the JSP I am using for integration tests makes extensive use of JSTL and it would probably be beneficial for developers overall to have access to JSTL in Sling 7. Thoughts? Thanks, Dan
Re: Using Apache Geranimo JSTL
+1 for using this and killing the existing Sling JSTL project. I don't think we ever made a release as I got distracted before writing integration tests. Justin On Thu, May 30, 2013 at 5:22 PM, Dan Klco dan.k...@sixdimensions.comwrote: All, While working on getting integration tests set up for the new TagLib functionality, I found that the Apache Geranimo project released a JSTL bundle for their servlet container. http://search.maven.org/#artifactdetails%7Corg.apache.geronimo.bundles%7Cjstl%7C1.2_1%7Cbundle https://issues.apache.org/jira/browse/GERONIMO-2536 Would anyone be opposed to including this bundle in the Launchpad Builder? Unless we need to modify the JSTL code, we could probably shutter the existing Sling JSTL project as well. Right now the JSP I am using for integration tests makes extensive use of JSTL and it would probably be beneficial for developers overall to have access to JSTL in Sling 7. Thoughts? Thanks, Dan
Re: [tooling] Moving forward with IDE tooling
Hi, I would strongly suggest that this effort be based on VLT. As mentioned on the wiki page, we're in the process of moving that to ASF and I think once the code is available, it will be clear that it provides a good low-level interface for this type of UI. While it is true that VLT currently only works with DavEX servers, I suspect it would not be hard to isolate the Ex bits and have a WebDAV only driver which could be used on non-JCR applications for basic file operations. My concern is that we end up building one more abstraction which is going to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK, etc.). I know VLT has some baggage, but I'd just ask that people keep an open mind. Separately, I'm going to start a child page of this wiki page to gather use cases. There are some functional areas listed on the main page, but I think we should try to capture individual use cases. Regards, Justin On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu romb...@apache.orgwrote: Hi, Following Antonio's kick-start of the Sling developer tooling [1] I've gathered some thoughts about the initial goals and implementation of our Sling IDE tooling. The document is at [2] so please have a look and let me know what your thoughts are. I intend to take a pass at the code next week and align it to the proposed structure, as a foundation for feature work. Robert [1]: https://cwiki.apache.org/SLING/slingclipse.html [2]: https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling
Re: [tooling] Moving forward with IDE tooling
Hi, +1 to that. After working on sling for many years doing a mixture of bundle and UI work, mainly using the FileSystemResolver bundle, I realise now if VLT had been available with sync mode (ie auto syncing the repo and the file system), we (the team I was working with at the time) would have made much more rapid progress. UI dev work needs file-save-refresh. The in browser editing UIs deliver this, as does VLT in sync mode, but unfortunately native eclipse based tooling is just too slow (on my machine, might be my machine). Using VLT since I joined Adobe, has been a joy, and I am very glad to know its being donated to the ASF. Had we had VLT then, we would have developed in a very different way, and might not have had half the problems we had with tooling and team structure. Ian On 31 May 2013 10:16, Justin Edelson jus...@justinedelson.com wrote: Hi, I would strongly suggest that this effort be based on VLT. As mentioned on the wiki page, we're in the process of moving that to ASF and I think once the code is available, it will be clear that it provides a good low-level interface for this type of UI. While it is true that VLT currently only works with DavEX servers, I suspect it would not be hard to isolate the Ex bits and have a WebDAV only driver which could be used on non-JCR applications for basic file operations. My concern is that we end up building one more abstraction which is going to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK, etc.). I know VLT has some baggage, but I'd just ask that people keep an open mind. Separately, I'm going to start a child page of this wiki page to gather use cases. There are some functional areas listed on the main page, but I think we should try to capture individual use cases. Regards, Justin On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu romb...@apache.org wrote: Hi, Following Antonio's kick-start of the Sling developer tooling [1] I've gathered some thoughts about the initial goals and implementation of our Sling IDE tooling. The document is at [2] so please have a look and let me know what your thoughts are. I intend to take a pass at the code next week and align it to the proposed structure, as a foundation for feature work. Robert [1]: https://cwiki.apache.org/SLING/slingclipse.html [2]: https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling
Re: [tooling] Moving forward with IDE tooling
Ian - please do add the autosync use case to the wiki page I created. On Thu, May 30, 2013 at 9:47 PM, Ian Boston i...@tfd.co.uk wrote: Hi, +1 to that. After working on sling for many years doing a mixture of bundle and UI work, mainly using the FileSystemResolver bundle, I realise now if VLT had been available with sync mode (ie auto syncing the repo and the file system), we (the team I was working with at the time) would have made much more rapid progress. UI dev work needs file-save-refresh. The in browser editing UIs deliver this, as does VLT in sync mode, but unfortunately native eclipse based tooling is just too slow (on my machine, might be my machine). Using VLT since I joined Adobe, has been a joy, and I am very glad to know its being donated to the ASF. Had we had VLT then, we would have developed in a very different way, and might not have had half the problems we had with tooling and team structure. Ian On 31 May 2013 10:16, Justin Edelson jus...@justinedelson.com wrote: Hi, I would strongly suggest that this effort be based on VLT. As mentioned on the wiki page, we're in the process of moving that to ASF and I think once the code is available, it will be clear that it provides a good low-level interface for this type of UI. While it is true that VLT currently only works with DavEX servers, I suspect it would not be hard to isolate the Ex bits and have a WebDAV only driver which could be used on non-JCR applications for basic file operations. My concern is that we end up building one more abstraction which is going to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK, etc.). I know VLT has some baggage, but I'd just ask that people keep an open mind. Separately, I'm going to start a child page of this wiki page to gather use cases. There are some functional areas listed on the main page, but I think we should try to capture individual use cases. Regards, Justin On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu romb...@apache.org wrote: Hi, Following Antonio's kick-start of the Sling developer tooling [1] I've gathered some thoughts about the initial goals and implementation of our Sling IDE tooling. The document is at [2] so please have a look and let me know what your thoughts are. I intend to take a pass at the code next week and align it to the proposed structure, as a foundation for feature work. Robert [1]: https://cwiki.apache.org/SLING/slingclipse.html [2]: https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling
Re: [tooling] Moving forward with IDE tooling
is the vlt sync now actually updating .content.xml files? I thought it can only sync regular files. Ruben On 5/30/2013 7:24 PM, Justin Edelson wrote: Ian - please do add the autosync use case to the wiki page I created. On Thu, May 30, 2013 at 9:47 PM, Ian Boston i...@tfd.co.uk wrote: Hi, +1 to that. After working on sling for many years doing a mixture of bundle and UI work, mainly using the FileSystemResolver bundle, I realise now if VLT had been available with sync mode (ie auto syncing the repo and the file system), we (the team I was working with at the time) would have made much more rapid progress. UI dev work needs file-save-refresh. The in browser editing UIs deliver this, as does VLT in sync mode, but unfortunately native eclipse based tooling is just too slow (on my machine, might be my machine). Using VLT since I joined Adobe, has been a joy, and I am very glad to know its being donated to the ASF. Had we had VLT then, we would have developed in a very different way, and might not have had half the problems we had with tooling and team structure. Ian On 31 May 2013 10:16, Justin Edelson jus...@justinedelson.com wrote: Hi, I would strongly suggest that this effort be based on VLT. As mentioned on the wiki page, we're in the process of moving that to ASF and I think once the code is available, it will be clear that it provides a good low-level interface for this type of UI. While it is true that VLT currently only works with DavEX servers, I suspect it would not be hard to isolate the Ex bits and have a WebDAV only driver which could be used on non-JCR applications for basic file operations. My concern is that we end up building one more abstraction which is going to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK, etc.). I know VLT has some baggage, but I'd just ask that people keep an open mind. Separately, I'm going to start a child page of this wiki page to gather use cases. There are some functional areas listed on the main page, but I think we should try to capture individual use cases. Regards, Justin On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu romb...@apache.org wrote: Hi, Following Antonio's kick-start of the Sling developer tooling [1] I've gathered some thoughts about the initial goals and implementation of our Sling IDE tooling. The document is at [2] so please have a look and let me know what your thoughts are. I intend to take a pass at the code next week and align it to the proposed structure, as a foundation for feature work. Robert [1]: https://cwiki.apache.org/SLING/slingclipse.html [2]: https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling
[jira] [Created] (SLING-2894) ResourceUtil.getOrCreateResource doesn't commit changes if an intermediate exception occurs
Carsten Ziegeler created SLING-2894: --- Summary: ResourceUtil.getOrCreateResource doesn't commit changes if an intermediate exception occurs Key: SLING-2894 URL: https://issues.apache.org/jira/browse/SLING-2894 Project: Sling Issue Type: Bug Components: API Affects Versions: API 2.4.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.4.4 If an exception occurs during resource creation, creation is retried but never committed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-2894) ResourceUtil.getOrCreateResource doesn't commit changes if an intermediate exception occurs
[ https://issues.apache.org/jira/browse/SLING-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-2894. - Resolution: Fixed ResourceUtil.getOrCreateResource doesn't commit changes if an intermediate exception occurs --- Key: SLING-2894 URL: https://issues.apache.org/jira/browse/SLING-2894 Project: Sling Issue Type: Bug Components: API Affects Versions: API 2.4.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.4.4 If an exception occurs during resource creation, creation is retried but never committed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [tooling] Moving forward with IDE tooling
@Justin, will do. @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its internals). On 31 May 2013 13:48, Ruben Reusser r...@headwire.com wrote: is the vlt sync now actually updating .content.xml files? I thought it can only sync regular files. Ruben On 5/30/2013 7:24 PM, Justin Edelson wrote: Ian - please do add the autosync use case to the wiki page I created. On Thu, May 30, 2013 at 9:47 PM, Ian Boston i...@tfd.co.uk wrote: Hi, +1 to that. After working on sling for many years doing a mixture of bundle and UI work, mainly using the FileSystemResolver bundle, I realise now if VLT had been available with sync mode (ie auto syncing the repo and the file system), we (the team I was working with at the time) would have made much more rapid progress. UI dev work needs file-save-refresh. The in browser editing UIs deliver this, as does VLT in sync mode, but unfortunately native eclipse based tooling is just too slow (on my machine, might be my machine). Using VLT since I joined Adobe, has been a joy, and I am very glad to know its being donated to the ASF. Had we had VLT then, we would have developed in a very different way, and might not have had half the problems we had with tooling and team structure. Ian On 31 May 2013 10:16, Justin Edelson jus...@justinedelson.com wrote: Hi, I would strongly suggest that this effort be based on VLT. As mentioned on the wiki page, we're in the process of moving that to ASF and I think once the code is available, it will be clear that it provides a good low-level interface for this type of UI. While it is true that VLT currently only works with DavEX servers, I suspect it would not be hard to isolate the Ex bits and have a WebDAV only driver which could be used on non-JCR applications for basic file operations. My concern is that we end up building one more abstraction which is going to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK, etc.). I know VLT has some baggage, but I'd just ask that people keep an open mind. Separately, I'm going to start a child page of this wiki page to gather use cases. There are some functional areas listed on the main page, but I think we should try to capture individual use cases. Regards, Justin On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu romb...@apache.org wrote: Hi, Following Antonio's kick-start of the Sling developer tooling [1] I've gathered some thoughts about the initial goals and implementation of our Sling IDE tooling. The document is at [2] so please have a look and let me know what your thoughts are. I intend to take a pass at the code next week and align it to the proposed structure, as a foundation for feature work. Robert [1]: https://cwiki.apache.org/**SLING/slingclipse.htmlhttps://cwiki.apache.org/SLING/slingclipse.html [2]: https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDE+toolinghttps://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling
RE: [tooling] Moving forward with IDE tooling
I am open to the idea of using VLT as a base, but we will have to do some pretty extensive work to clean up the error handling and messaging. I haven't taken a look at the newest version, but 2.4.18 is still a black box when it doesn't work, which seems to happen unpredictably. I am assuming we would be skipping the CLI stuff and invoking whatever APIs VLT uses internally to handle imports/exports, correct? Another idea I've been thinking about would be some sort of .content.xml file editor. Nothing too fancy, more of a helper than a full featured node editor. I haven't come up with a UI yet, but is this something that might be worth looking into as well? -Dan -Original Message- From: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of Ian Boston Sent: Friday, May 31, 2013 12:07 AM To: dev@sling.apache.org Subject: Re: [tooling] Moving forward with IDE tooling @Justin, will do. @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its internals). On 31 May 2013 13:48, Ruben Reusser r...@headwire.com wrote: is the vlt sync now actually updating .content.xml files? I thought it can only sync regular files. Ruben On 5/30/2013 7:24 PM, Justin Edelson wrote: Ian - please do add the autosync use case to the wiki page I created. On Thu, May 30, 2013 at 9:47 PM, Ian Boston i...@tfd.co.uk wrote: Hi, +1 to that. After working on sling for many years doing a mixture of bundle and UI work, mainly using the FileSystemResolver bundle, I realise now if VLT had been available with sync mode (ie auto syncing the repo and the file system), we (the team I was working with at the time) would have made much more rapid progress. UI dev work needs file-save-refresh. The in browser editing UIs deliver this, as does VLT in sync mode, but unfortunately native eclipse based tooling is just too slow (on my machine, might be my machine). Using VLT since I joined Adobe, has been a joy, and I am very glad to know its being donated to the ASF. Had we had VLT then, we would have developed in a very different way, and might not have had half the problems we had with tooling and team structure. Ian On 31 May 2013 10:16, Justin Edelson jus...@justinedelson.com wrote: Hi, I would strongly suggest that this effort be based on VLT. As mentioned on the wiki page, we're in the process of moving that to ASF and I think once the code is available, it will be clear that it provides a good low-level interface for this type of UI. While it is true that VLT currently only works with DavEX servers, I suspect it would not be hard to isolate the Ex bits and have a WebDAV only driver which could be used on non-JCR applications for basic file operations. My concern is that we end up building one more abstraction which is going to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK, etc.). I know VLT has some baggage, but I'd just ask that people keep an open mind. Separately, I'm going to start a child page of this wiki page to gather use cases. There are some functional areas listed on the main page, but I think we should try to capture individual use cases. Regards, Justin On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu romb...@apache.org wrote: Hi, Following Antonio's kick-start of the Sling developer tooling [1] I've gathered some thoughts about the initial goals and implementation of our Sling IDE tooling. The document is at [2] so please have a look and let me know what your thoughts are. I intend to take a pass at the code next week and align it to the proposed structure, as a foundation for feature work. Robert [1]: https://cwiki.apache.org/**SLING/slingclipse.htmlhttps://cwiki.ap ache.org/SLING/slingclipse.html [2]: https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDE+too linghttps://cwiki.apache.org/confluence/display/SLING/Sling+IDE+to oling - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3343 / Virus Database: 3184/6366 - Release Date: 05/29/13
Re: [tooling] Moving forward with IDE tooling
I've two major comments - first of all, I think the tooling should be based on Sling resource API to be able to handle all potential resource providers. In addition the file name .content.xml is really bad as it is hidden nearly in all OS, IDEs etc. Something like [content].xml is way nicer - it's an illegal JCR name btw as well. Carsten 2013/5/31 Dan Klco dan.k...@sixdimensions.com I am open to the idea of using VLT as a base, but we will have to do some pretty extensive work to clean up the error handling and messaging. I haven't taken a look at the newest version, but 2.4.18 is still a black box when it doesn't work, which seems to happen unpredictably. I am assuming we would be skipping the CLI stuff and invoking whatever APIs VLT uses internally to handle imports/exports, correct? Another idea I've been thinking about would be some sort of .content.xml file editor. Nothing too fancy, more of a helper than a full featured node editor. I haven't come up with a UI yet, but is this something that might be worth looking into as well? -Dan -Original Message- From: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of Ian Boston Sent: Friday, May 31, 2013 12:07 AM To: dev@sling.apache.org Subject: Re: [tooling] Moving forward with IDE tooling @Justin, will do. @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its internals). On 31 May 2013 13:48, Ruben Reusser r...@headwire.com wrote: is the vlt sync now actually updating .content.xml files? I thought it can only sync regular files. Ruben On 5/30/2013 7:24 PM, Justin Edelson wrote: Ian - please do add the autosync use case to the wiki page I created. On Thu, May 30, 2013 at 9:47 PM, Ian Boston i...@tfd.co.uk wrote: Hi, +1 to that. After working on sling for many years doing a mixture of bundle and UI work, mainly using the FileSystemResolver bundle, I realise now if VLT had been available with sync mode (ie auto syncing the repo and the file system), we (the team I was working with at the time) would have made much more rapid progress. UI dev work needs file-save-refresh. The in browser editing UIs deliver this, as does VLT in sync mode, but unfortunately native eclipse based tooling is just too slow (on my machine, might be my machine). Using VLT since I joined Adobe, has been a joy, and I am very glad to know its being donated to the ASF. Had we had VLT then, we would have developed in a very different way, and might not have had half the problems we had with tooling and team structure. Ian On 31 May 2013 10:16, Justin Edelson jus...@justinedelson.com wrote: Hi, I would strongly suggest that this effort be based on VLT. As mentioned on the wiki page, we're in the process of moving that to ASF and I think once the code is available, it will be clear that it provides a good low-level interface for this type of UI. While it is true that VLT currently only works with DavEX servers, I suspect it would not be hard to isolate the Ex bits and have a WebDAV only driver which could be used on non-JCR applications for basic file operations. My concern is that we end up building one more abstraction which is going to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK, etc.). I know VLT has some baggage, but I'd just ask that people keep an open mind. Separately, I'm going to start a child page of this wiki page to gather use cases. There are some functional areas listed on the main page, but I think we should try to capture individual use cases. Regards, Justin On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu romb...@apache.org wrote: Hi, Following Antonio's kick-start of the Sling developer tooling [1] I've gathered some thoughts about the initial goals and implementation of our Sling IDE tooling. The document is at [2] so please have a look and let me know what your thoughts are. I intend to take a pass at the code next week and align it to the proposed structure, as a foundation for feature work. Robert [1]: https://cwiki.apache.org/**SLING/slingclipse.htmlhttps://cwiki.ap ache.org/SLING/slingclipse.html [2]: https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDE+too linghttps://cwiki.apache.org/confluence/display/SLING/Sling+IDE+to oling - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3343 / Virus Database: 3184/6366 - Release Date: 05/29/13 -- Carsten Ziegeler cziege...@apache.org
