Re: [tooling] Moving forward with IDE tooling
Hi *, just my cents. First of all I am really happy to see this moving forward (thanks Robert for bring this up). About the usage of VLT I am not against it but I do not see any problem on having a further level of abstraction between the tooling and the transport layer (e.g. VLT) Regards Antonio On May 31, 2013, at 2:16 AM, Justin Edelson 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.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: Using Apache Geranimo JSTL
On Thu, May 30, 2013 at 11:22 PM, Dan Klco dan.k...@sixdimensions.com wrote: ...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 +1 to that -Bertrand
Re: cwiki.apache.org/SLING not updating
Hi, On Thu, May 30, 2013 at 4:35 PM, Robert Munteanu romb...@apache.org wrote: ... I noticed that the page from https://cwiki.apache.org/SLING/index.html lags behind https://cwiki.apache.org/confluence/display/SLING/Index . I'd say file an INFRA issue...and excuse my ignorance but why do we need both? -Bertrand
Build failed in Jenkins: sling-trunk-1.7 #50
See https://builds.apache.org/job/sling-trunk-1.7/50/changes Changes: [cziegeler] SLING-2894 : ResourceUtil.getOrCreateResource doesn't commit changes if an intermediate exception occurs [dklco] Updating to a newer, released version of the POST Servlet -- Started by an SCM change Started by an SCM change Building remotely on ubuntu6 in workspace https://builds.apache.org/job/sling-trunk-1.7/ws/ Updating http://svn.apache.org/repos/asf/sling/trunk U bundles/api/src/main/java/org/apache/sling/api/resource/ResourceUtil.java U launchpad/integration-tests/pom.xml At revision 1488124 [locks-and-latches] Checking to see if we really have the locks [locks-and-latches] Have all the locks, build can start Parsing POMs Modules changed, recalculating dependency graph [locks-and-latches] Releasing all the locks [locks-and-latches] All the locks released ERROR: Processing failed due to a bug in the code. Please report this to jenkinsci-us...@googlegroups.com hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown: java.util.concurrent.TimeoutException: Ping started on 1369989500328 hasn't completed at 1369989740329 at hudson.remoting.Request.call(Request.java:174) at hudson.remoting.Channel.call(Channel.java:672) at hudson.EnvVars.getRemote(EnvVars.java:212) at hudson.model.Computer.getEnvironment(Computer.java:882) at jenkins.model.CoreEnvironmentContributor.buildEnvironmentFor(CoreEnvironmentContributor.java:28) at hudson.model.Run.getEnvironment(Run.java:2021) at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:936) at hudson.maven.AbstractMavenBuild.getEnvironment(AbstractMavenBuild.java:59) at hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:154) at hudson.scm.SubversionSCM.getModuleRoot(SubversionSCM.java:1393) at hudson.model.AbstractBuild.getModuleRoot(AbstractBuild.java:370) at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:647) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:592) at hudson.model.Run.execute(Run.java:1568) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown: java.util.concurrent.TimeoutException: Ping started on 1369989500328 hasn't completed at 1369989740329 at hudson.remoting.Request.abort(Request.java:299) at hudson.remoting.Channel.terminate(Channel.java:732) at hudson.remoting.Channel$CloseCommand.execute(Channel.java:850) at hudson.remoting.Channel$2.handle(Channel.java:435) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60) Caused by: hudson.remoting.Channel$OrderlyShutdown: java.util.concurrent.TimeoutException: Ping started on 1369989500328 hasn't completed at 1369989740329 ... 3 more Caused by: Command close created at at hudson.remoting.Command.init(Command.java:56) at hudson.remoting.Channel$CloseCommand.init(Channel.java:844) at hudson.remoting.Channel$CloseCommand.init(Channel.java:842) at hudson.remoting.Channel.close(Channel.java:909) at hudson.slaves.ChannelPinger$1.onDead(ChannelPinger.java:110) at hudson.remoting.PingThread.ping(PingThread.java:120) at hudson.remoting.PingThread.run(PingThread.java:81) Caused by: java.util.concurrent.TimeoutException: Ping started on 1369989500328 hasn't completed at 1369989740329 ... 2 more project=hudson.maven.MavenModuleSet@ab91fbb[sling-trunk-1.7] project.getModules()=[hudson.maven.MavenModule@756899ca[sling-trunk-1.7/org.apache.sling:adapter-annotations][sling-trunk-1.7/org.apache.sling:adapter-annotations][relativePath:maven/adapter-annotations], hudson.maven.MavenModule@2648d8fe[sling-trunk-1.7/org.apache.sling:apache-sling-jar-resource-bundle][sling-trunk-1.7/org.apache.sling:apache-sling-jar-resource-bundle][relativePath:maven/apache-sling-jar-resource-bundle], hudson.maven.MavenModule@789e1f54[sling-trunk-1.7/org.apache.sling:maven-jcrocm-plugin][sling-trunk-1.7/org.apache.sling:maven-jcrocm-plugin][relativePath:maven/maven-jcrocm-plugin], hudson.maven.MavenModule@551b01a9[sling-trunk-1.7/org.apache.sling:maven-jspc-plugin][sling-trunk-1.7/org.apache.sling:maven-jspc-plugin][relativePath:maven/maven-jspc-plugin], hudson.maven.MavenModule@600a29e5[sling-trunk-1.7/org.apache.sling:maven-launchpad-plugin][sling-trunk-1.7/org.apache.sling:maven-launchpad-plugin][relativePath:maven/maven-launchpad-plugin],
[jira] [Created] (SLING-2895) NPE in VotingHelper.getWinningVoting
Dominique Pfister created SLING-2895:
Summary: NPE in VotingHelper.getWinningVoting
Key: SLING-2895
URL: https://issues.apache.org/jira/browse/SLING-2895
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Discovery Impl 1.0.0
Reporter: Dominique Pfister
Priority: Minor
On shutdown of a Felix container, I get the following stack trace:
{code}
31.05.2013 13:27:29.632 *ERROR* [pool-6-thread-4]
org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job
execution of
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler@4366e290 :
null java.lang.NullPointerException
at
org.apache.sling.discovery.impl.cluster.voting.VotingHelper.getWinningVoting(VotingHelper.java:145)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.doCheckView(HeartbeatHandler.java:307)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.checkView(HeartbeatHandler.java:277)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.run(HeartbeatHandler.java:153)
at
org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:56)
at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)
{code}
--
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] [Updated] (SLING-2895) NPE in VotingHelper.getWinningVoting
[ https://issues.apache.org/jira/browse/SLING-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister updated SLING-2895: - Description: On shutdown of a Felix container, I get the following stack trace: 31.05.2013 13:27:29.632 *ERROR* [pool-6-thread-4] org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job execution of org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler@4366e290 : null java.lang.NullPointerException at org.apache.sling.discovery.impl.cluster.voting.VotingHelper.getWinningVoting(VotingHelper.java:145) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.doCheckView(HeartbeatHandler.java:307) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.checkView(HeartbeatHandler.java:277) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.run(HeartbeatHandler.java:153) at org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:56) at org.quartz.core.JobRunShell.run(JobRunShell.java:213) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:680) was: On shutdown of a Felix container, I get the following stack trace: _test_ 31.05.2013 13:27:29.632 *ERROR* [pool-6-thread-4] org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job execution of org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler@4366e290 : null java.lang.NullPointerException at org.apache.sling.discovery.impl.cluster.voting.VotingHelper.getWinningVoting(VotingHelper.java:145) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.doCheckView(HeartbeatHandler.java:307) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.checkView(HeartbeatHandler.java:277) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.run(HeartbeatHandler.java:153) at org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:56) at org.quartz.core.JobRunShell.run(JobRunShell.java:213) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:680) code NPE in VotingHelper.getWinningVoting Key: SLING-2895 URL: https://issues.apache.org/jira/browse/SLING-2895 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.0.0 Reporter: Dominique Pfister Priority: Minor On shutdown of a Felix container, I get the following stack trace: 31.05.2013 13:27:29.632 *ERROR* [pool-6-thread-4] org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job execution of org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler@4366e290 : null java.lang.NullPointerException at org.apache.sling.discovery.impl.cluster.voting.VotingHelper.getWinningVoting(VotingHelper.java:145) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.doCheckView(HeartbeatHandler.java:307) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.checkView(HeartbeatHandler.java:277) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.run(HeartbeatHandler.java:153) at org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:56) at org.quartz.core.JobRunShell.run(JobRunShell.java:213) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:680) -- 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] [Updated] (SLING-2895) NPE in VotingHelper.getWinningVoting
[
https://issues.apache.org/jira/browse/SLING-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Pfister updated SLING-2895:
-
Description:
On shutdown of a Felix container, I get the following stack trace:
_test_
31.05.2013 13:27:29.632 *ERROR* [pool-6-thread-4]
org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job
execution of
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler@4366e290 :
null java.lang.NullPointerException
at
org.apache.sling.discovery.impl.cluster.voting.VotingHelper.getWinningVoting(VotingHelper.java:145)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.doCheckView(HeartbeatHandler.java:307)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.checkView(HeartbeatHandler.java:277)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.run(HeartbeatHandler.java:153)
at
org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:56)
at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)
code
was:
On shutdown of a Felix container, I get the following stack trace:
{code}
31.05.2013 13:27:29.632 *ERROR* [pool-6-thread-4]
org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job
execution of
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler@4366e290 :
null java.lang.NullPointerException
at
org.apache.sling.discovery.impl.cluster.voting.VotingHelper.getWinningVoting(VotingHelper.java:145)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.doCheckView(HeartbeatHandler.java:307)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.checkView(HeartbeatHandler.java:277)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.run(HeartbeatHandler.java:153)
at
org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:56)
at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)
{code}
NPE in VotingHelper.getWinningVoting
Key: SLING-2895
URL: https://issues.apache.org/jira/browse/SLING-2895
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Discovery Impl 1.0.0
Reporter: Dominique Pfister
Priority: Minor
On shutdown of a Felix container, I get the following stack trace:
_test_
31.05.2013 13:27:29.632 *ERROR* [pool-6-thread-4]
org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job
execution of
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler@4366e290 :
null java.lang.NullPointerException
at
org.apache.sling.discovery.impl.cluster.voting.VotingHelper.getWinningVoting(VotingHelper.java:145)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.doCheckView(HeartbeatHandler.java:307)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.checkView(HeartbeatHandler.java:277)
at
org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.run(HeartbeatHandler.java:153)
at
org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:56)
at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)
code
--
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: cwiki.apache.org/SLING not updating
On Fri, 2013-05-31 at 10:59 +0200, Bertrand Delacretaz wrote: Hi, On Thu, May 30, 2013 at 4:35 PM, Robert Munteanu romb...@apache.org wrote: ... I noticed that the page from https://cwiki.apache.org/SLING/index.html lags behind https://cwiki.apache.org/confluence/display/SLING/Index . I'd say file an INFRA issue...and excuse my ignorance but why do we need both? Filed INFRA-6329: SLING wiki - confluence autoexport no longer happens https://issues.apache.org/jira/browse/INFRA-6329 The first URL is a static HTML export of the actual confluence wiki, done for performance reasons. See also the note at [1] Robert [1]: https://cwiki.apache.org/INFRA/cwiki.html
Re: [tooling] Moving forward with IDE tooling
Hi Justin, (and this will address Ian's comments as well ) On Thu, 2013-05-30 at 20:16 -0400, Justin Edelson 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. I have not yet reviewed how embeddable VLT is, but it's hard to believe that it will be a perfect match for both the IntelliJ and Eclipse plugin APIs. As I noted, you should not directly read from/write to the filesystem in Eclipse ( and I expect IntelliJ to have similar requirements ) for both user experience ( stale workspace resources ) and performance ( forced refresh of resources from disk ) reasons. As such, we will need a wrapper over VLT anyway to make this API IDE-friendly. So there's no large effort to have transport API layer. Also, echoing Antonio's and Carsten's comments, I think that while VLT is a powerful and mature tool, it does not work on top of the resource API that we have in sling. We already have a MongoDB resource provider in contrib [1] and a GSoC project accepted which will create an Apache Cassandra resource provider [2]. A resource-based transport implementation will help us make those implementations first-class citizens. (snip...) 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. +1 Robert [1]: http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/mongodb/ [2]: http://sling.markmail.org/thread/ugghepk5hod55fy5
Re: [tooling] Moving forward with IDE tooling
On Thu, 2013-05-30 at 20:48 -0700, Ruben Reusser wrote: is the vlt sync now actually updating .content.xml files? I thought it can only sync regular files. I'm frankly more of an IDE guy than a VLT guy from a development experience point of view. However, I think that the IDE is the right place for the change detection/sync capabilities, while VLT will be a mechanism from transporting changes from/to the repository. Robert
Re: [tooling] Moving forward with IDE tooling
Here my 2 cents about Sling Tooling vault, IMHO vault is pure JCR Tooling. And even if some people do not like the fact, but the resourcetree is different from the jcr tree. So in consequence this additional abstraction of the Resource API is there (even without additional resource resolvers, since Sling Servlets are not present in the JCR Tree as well). Due to that I think vault AS IS is not the right choice since this would hide everything happening on the resourcetree layer. Having a complete view on the Resourcetree at least in the /apps and /libs section would be something I really would appreciate. Best regards Dominik On Fri, May 31, 2013 at 2:04 PM, Robert Munteanu romb...@apache.org wrote: Hi Justin, (and this will address Ian's comments as well ) On Thu, 2013-05-30 at 20:16 -0400, Justin Edelson 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. I have not yet reviewed how embeddable VLT is, but it's hard to believe that it will be a perfect match for both the IntelliJ and Eclipse plugin APIs. As I noted, you should not directly read from/write to the filesystem in Eclipse ( and I expect IntelliJ to have similar requirements ) for both user experience ( stale workspace resources ) and performance ( forced refresh of resources from disk ) reasons. As such, we will need a wrapper over VLT anyway to make this API IDE-friendly. So there's no large effort to have transport API layer. Also, echoing Antonio's and Carsten's comments, I think that while VLT is a powerful and mature tool, it does not work on top of the resource API that we have in sling. We already have a MongoDB resource provider in contrib [1] and a GSoC project accepted which will create an Apache Cassandra resource provider [2]. A resource-based transport implementation will help us make those implementations first-class citizens. (snip...) 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. +1 Robert [1]: http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/mongodb/ [2]: http://sling.markmail.org/thread/ugghepk5hod55fy5
Re: [tooling] Moving forward with IDE tooling
On Fri, 2013-05-31 at 05:10 +, Dan Klco wrote: 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? Yes, I plan to use the VLT APIs, not the CLI. 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? Yes, definitely. We should have a friendly content editor. Eclipse, for instance, has a 'Design' tab for XML files which has a basic view [1] which can be customised later. Robert [1]: http://docs.oracle.com/cd/E15919_01/wlp.1032/e14244/img/servlet.gif -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
On Fri, 2013-05-31 at 14:20 +0900, Carsten Ziegeler wrote: 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. +1 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. +1 . Although we do need to think about compatibility with command-line VLT checkouts as well. Robert 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
Re: [tooling] Moving forward with IDE tooling
Some time ago I thought about this and had the following idea: - we define a packaging for resources - this can be used to represent the resources in the file system or in a zip file - if a resource is a file, it is represented as a file with the same name - if a resource is not a file, it is represented as a directory - properties if a non-file resource, and all additional metadata of a file is stored in a [content].xml (or json) This would allow browsing through the file system to the resource you want to edit and just edit the properties of this resource in a file. It makes syncing very easy and fast. Maybe we can distinguish between a resource which might have child nodes and one that doesn't and make the mapping differently. In any case the whole mechanism needs some research, a disadvantage might be if you map a huge resource tree which has no files at all to the file system, this will result in a huge directory tree instead of one large content.xml - however as we're talking about developer tooling, we can neglect this. Just a rough idea Carsten 2013/5/31 Robert Munteanu romb...@apache.org On Thu, 2013-05-30 at 20:48 -0700, Ruben Reusser wrote: is the vlt sync now actually updating .content.xml files? I thought it can only sync regular files. I'm frankly more of an IDE guy than a VLT guy from a development experience point of view. However, I think that the IDE is the right place for the change detection/sync capabilities, while VLT will be a mechanism from transporting changes from/to the repository. Robert -- Carsten Ziegeler cziege...@apache.org
Re: [tooling] Moving forward with IDE tooling
2013/5/31 Robert Munteanu romb...@apache.org 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. +1 . Although we do need to think about compatibility with command-line VLT checkouts as well. I don't see this as a hard requirement - however, I'm not against this - but I would do this as a second step. So let us do the right think first without thinking about this compatibility and once we have the perfect solution we can add something on top which provides this. If we start with compatibility to vlt in mind, this will definitely restrain us Carsten Robert 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.html https://cwiki.ap ache.org/SLING/slingclipse.html
Re: [tooling] Moving forward with IDE tooling
One comment about content.xml - in our CQ solutions we do use the Sling-Initialcontent (with the much nicer json files placed parallel to the folders with the same name instead of .content.xml underneath) instead of packing it directly in the vault based packages. This leads to a clean and much better searchable filestructure. The code at least for the jcr installation is yet there so this json based syntax would be an option that allready works. The syntax is exactly what you get from the default GET Servlet dumping the structure as json. The only drawback to vault is that synchronisation is just in direction of the repository, no export (but dumping via the default get servlet). Cheers Dominik On Fri, May 31, 2013 at 2:14 PM, Carsten Ziegeler cziege...@apache.orgwrote: Some time ago I thought about this and had the following idea: - we define a packaging for resources - this can be used to represent the resources in the file system or in a zip file - if a resource is a file, it is represented as a file with the same name - if a resource is not a file, it is represented as a directory - properties if a non-file resource, and all additional metadata of a file is stored in a [content].xml (or json) This would allow browsing through the file system to the resource you want to edit and just edit the properties of this resource in a file. It makes syncing very easy and fast. Maybe we can distinguish between a resource which might have child nodes and one that doesn't and make the mapping differently. In any case the whole mechanism needs some research, a disadvantage might be if you map a huge resource tree which has no files at all to the file system, this will result in a huge directory tree instead of one large content.xml - however as we're talking about developer tooling, we can neglect this. Just a rough idea Carsten 2013/5/31 Robert Munteanu romb...@apache.org On Thu, 2013-05-30 at 20:48 -0700, Ruben Reusser wrote: is the vlt sync now actually updating .content.xml files? I thought it can only sync regular files. I'm frankly more of an IDE guy than a VLT guy from a development experience point of view. However, I think that the IDE is the right place for the change detection/sync capabilities, while VLT will be a mechanism from transporting changes from/to the repository. Robert -- Carsten Ziegeler cziege...@apache.org
[jira] [Assigned] (SLING-2895) NPE in VotingHelper.getWinningVoting
[ https://issues.apache.org/jira/browse/SLING-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli reassigned SLING-2895: -- Assignee: Stefan Egli NPE in VotingHelper.getWinningVoting Key: SLING-2895 URL: https://issues.apache.org/jira/browse/SLING-2895 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Discovery Impl 1.0.0 Reporter: Dominique Pfister Assignee: Stefan Egli Priority: Minor On shutdown of a Felix container, I get the following stack trace: 31.05.2013 13:27:29.632 *ERROR* [pool-6-thread-4] org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job execution of org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler@4366e290 : null java.lang.NullPointerException at org.apache.sling.discovery.impl.cluster.voting.VotingHelper.getWinningVoting(VotingHelper.java:145) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.doCheckView(HeartbeatHandler.java:307) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.checkView(HeartbeatHandler.java:277) at org.apache.sling.discovery.impl.common.heartbeat.HeartbeatHandler.run(HeartbeatHandler.java:153) at org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:56) at org.quartz.core.JobRunShell.run(JobRunShell.java:213) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:680) -- 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
On Fri, 2013-05-31 at 21:14 +0900, Carsten Ziegeler wrote: Some time ago I thought about this and had the following idea: - we define a packaging for resources - this can be used to represent the resources in the file system or in a zip file - if a resource is a file, it is represented as a file with the same name - if a resource is not a file, it is represented as a directory - properties if a non-file resource, and all additional metadata of a file is stored in a [content].xml (or json) Good point, added https://cwiki.apache.org/confluence/display/SLING/Sling+IDE +tooling#SlingIDEtooling-Resourceserializationformat to capture the proposal / points to discuss. Robert This would allow browsing through the file system to the resource you want to edit and just edit the properties of this resource in a file. It makes syncing very easy and fast. Maybe we can distinguish between a resource which might have child nodes and one that doesn't and make the mapping differently. In any case the whole mechanism needs some research, a disadvantage might be if you map a huge resource tree which has no files at all to the file system, this will result in a huge directory tree instead of one large content.xml - however as we're talking about developer tooling, we can neglect this. Just a rough idea Carsten 2013/5/31 Robert Munteanu romb...@apache.org On Thu, 2013-05-30 at 20:48 -0700, Ruben Reusser wrote: is the vlt sync now actually updating .content.xml files? I thought it can only sync regular files. I'm frankly more of an IDE guy than a VLT guy from a development experience point of view. However, I think that the IDE is the right place for the change detection/sync capabilities, while VLT will be a mechanism from transporting changes from/to the repository. Robert
Re: [tooling] Moving forward with IDE tooling
I think the use case of doing maven/jenkins builds and continuous integrations should also be considered here. Most CQ projects at this time seem to be using maven builds that create packages that can be deployed to CQ. Since VLT is open sourced and since the packaging part is also in VLT I'd expect that to be open sourced as well. vlt sync would actually work if it did manage the .content.xml files as well (didn't it do that in the beginning - seems that feature was removed?) allowing developers to change their code either in the ide or crxde|lite and having the code sync'd to the file system for checkin and separate builds for CI. Breaking this experience may be a big problem. Ruben On 5/31/2013 7:27 AM, Dominik Süß wrote: One problematic part about serialisation is structuredepth. In development you might not want to handle complex structures by shifting folders around, so it would be nice to have a format that allows to define a substructure, so in the Sling Initialcontent you might even define one big JSON that defines the complete structure. The consequence of that if you also need to be able to export changes to the filesystem it isn't clear when things should be handled within a file, and when to break up in folderstructures. In vault this is implicitly solved for specific nodetypes. E.g. in cq a dialog always gets exportet to a specific xml file covering this explicit substrutcture in one aggregated file. But still even in vault you can have situations where you define substructures in the .content.xml which leads to an instant asynchronity with the repository since vault tries to synch that as folder/file structure. I currently have no idea for good solution, but in any case these problems should be solved. Dominik On Fri, May 31, 2013 at 3:19 PM, Robert Munteanu romb...@apache.org wrote: On Fri, 2013-05-31 at 21:14 +0900, Carsten Ziegeler wrote: Some time ago I thought about this and had the following idea: - we define a packaging for resources - this can be used to represent the resources in the file system or in a zip file - if a resource is a file, it is represented as a file with the same name - if a resource is not a file, it is represented as a directory - properties if a non-file resource, and all additional metadata of a file is stored in a [content].xml (or json) Good point, added https://cwiki.apache.org/confluence/display/SLING/Sling+IDE +tooling#SlingIDEtooling-Resourceserializationformat to capture the proposal / points to discuss. Robert This would allow browsing through the file system to the resource you want to edit and just edit the properties of this resource in a file. It makes syncing very easy and fast. Maybe we can distinguish between a resource which might have child nodes and one that doesn't and make the mapping differently. In any case the whole mechanism needs some research, a disadvantage might be if you map a huge resource tree which has no files at all to the file system, this will result in a huge directory tree instead of one large content.xml - however as we're talking about developer tooling, we can neglect this. Just a rough idea Carsten 2013/5/31 Robert Munteanu romb...@apache.org On Thu, 2013-05-30 at 20:48 -0700, Ruben Reusser wrote: is the vlt sync now actually updating .content.xml files? I thought it can only sync regular files. I'm frankly more of an IDE guy than a VLT guy from a development experience point of view. However, I think that the IDE is the right place for the change detection/sync capabilities, while VLT will be a mechanism from transporting changes from/to the repository. Robert
Re: [tooling] Moving forward with IDE tooling
One problematic part about serialisation is structuredepth. In development you might not want to handle complex structures by shifting folders around, so it would be nice to have a format that allows to define a substructure, so in the Sling Initialcontent you might even define one big JSON that defines the complete structure. The consequence of that if you also need to be able to export changes to the filesystem it isn't clear when things should be handled within a file, and when to break up in folderstructures. In vault this is implicitly solved for specific nodetypes. E.g. in cq a dialog always gets exportet to a specific xml file covering this explicit substrutcture in one aggregated file. But still even in vault you can have situations where you define substructures in the .content.xml which leads to an instant asynchronity with the repository since vault tries to synch that as folder/file structure. I currently have no idea for good solution, but in any case these problems should be solved. Dominik On Fri, May 31, 2013 at 3:19 PM, Robert Munteanu romb...@apache.org wrote: On Fri, 2013-05-31 at 21:14 +0900, Carsten Ziegeler wrote: Some time ago I thought about this and had the following idea: - we define a packaging for resources - this can be used to represent the resources in the file system or in a zip file - if a resource is a file, it is represented as a file with the same name - if a resource is not a file, it is represented as a directory - properties if a non-file resource, and all additional metadata of a file is stored in a [content].xml (or json) Good point, added https://cwiki.apache.org/confluence/display/SLING/Sling+IDE +tooling#SlingIDEtooling-Resourceserializationformat to capture the proposal / points to discuss. Robert This would allow browsing through the file system to the resource you want to edit and just edit the properties of this resource in a file. It makes syncing very easy and fast. Maybe we can distinguish between a resource which might have child nodes and one that doesn't and make the mapping differently. In any case the whole mechanism needs some research, a disadvantage might be if you map a huge resource tree which has no files at all to the file system, this will result in a huge directory tree instead of one large content.xml - however as we're talking about developer tooling, we can neglect this. Just a rough idea Carsten 2013/5/31 Robert Munteanu romb...@apache.org On Thu, 2013-05-30 at 20:48 -0700, Ruben Reusser wrote: is the vlt sync now actually updating .content.xml files? I thought it can only sync regular files. I'm frankly more of an IDE guy than a VLT guy from a development experience point of view. However, I think that the IDE is the right place for the change detection/sync capabilities, while VLT will be a mechanism from transporting changes from/to the repository. Robert
Re: [tooling] Moving forward with IDE tooling
That's why I think a resource packaging format is the way to go: a) it makes syncing easy during development b) it can directly be packaged together to create a package, so maven/ci builds simply work c) installation of those packages is easy as well I think it's important to note that this is not about a better/new vlt; it's a imho a different approach which directly addresses existing requirements. Carsten 2013/5/31 Ruben Reusser r...@headwire.com I think the use case of doing maven/jenkins builds and continuous integrations should also be considered here. Most CQ projects at this time seem to be using maven builds that create packages that can be deployed to CQ. Since VLT is open sourced and since the packaging part is also in VLT I'd expect that to be open sourced as well. vlt sync would actually work if it did manage the .content.xml files as well (didn't it do that in the beginning - seems that feature was removed?) allowing developers to change their code either in the ide or crxde|lite and having the code sync'd to the file system for checkin and separate builds for CI. Breaking this experience may be a big problem. Ruben On 5/31/2013 7:27 AM, Dominik Süß wrote: One problematic part about serialisation is structuredepth. In development you might not want to handle complex structures by shifting folders around, so it would be nice to have a format that allows to define a substructure, so in the Sling Initialcontent you might even define one big JSON that defines the complete structure. The consequence of that if you also need to be able to export changes to the filesystem it isn't clear when things should be handled within a file, and when to break up in folderstructures. In vault this is implicitly solved for specific nodetypes. E.g. in cq a dialog always gets exportet to a specific xml file covering this explicit substrutcture in one aggregated file. But still even in vault you can have situations where you define substructures in the .content.xml which leads to an instant asynchronity with the repository since vault tries to synch that as folder/file structure. I currently have no idea for good solution, but in any case these problems should be solved. Dominik On Fri, May 31, 2013 at 3:19 PM, Robert Munteanu romb...@apache.org wrote: On Fri, 2013-05-31 at 21:14 +0900, Carsten Ziegeler wrote: Some time ago I thought about this and had the following idea: - we define a packaging for resources - this can be used to represent the resources in the file system or in a zip file - if a resource is a file, it is represented as a file with the same name - if a resource is not a file, it is represented as a directory - properties if a non-file resource, and all additional metadata of a file is stored in a [content].xml (or json) Good point, added https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDEhttps://cwiki.apache.org/confluence/display/SLING/Sling+IDE +tooling#SlingIDEtooling-**Resourceserializationformat to capture the proposal / points to discuss. Robert This would allow browsing through the file system to the resource you want to edit and just edit the properties of this resource in a file. It makes syncing very easy and fast. Maybe we can distinguish between a resource which might have child nodes and one that doesn't and make the mapping differently. In any case the whole mechanism needs some research, a disadvantage might be if you map a huge resource tree which has no files at all to the file system, this will result in a huge directory tree instead of one large content.xml - however as we're talking about developer tooling, we can neglect this. Just a rough idea Carsten 2013/5/31 Robert Munteanu romb...@apache.org On Thu, 2013-05-30 at 20:48 -0700, Ruben Reusser wrote: is the vlt sync now actually updating .content.xml files? I thought it can only sync regular files. I'm frankly more of an IDE guy than a VLT guy from a development experience point of view. However, I think that the IDE is the right place for the change detection/sync capabilities, while VLT will be a mechanism from transporting changes from/to the repository. Robert -- Carsten Ziegeler cziege...@apache.org
Re: [tooling] Moving forward with IDE tooling
Hi, These are all excellent points. I am a bit confused about mentions of the Sling Resource API. This is a server-side API while we are discussing client code. AFAIK we don't have a client implementation of the Resource API nor do we have a standard transport mechanism. We do have the default GET and POST servlets, but as Robert pointed out in the wiki, those can't be depended upon consistently. The points Carsten and Dominik point to something broader - not using vlt (and the content packing process in general) necessitates defining packaging and deployment mechanisms. After all, it wouldn't be acceptable to have a way to develop and application without being able to deploy it. With vlt, these mechanisms are defined already (whether these mechanisms are ideal or not is a separate problem). One option is to use Sling-InitialContent and POST to the webconsole (as Dominik suggested); another is to build something new (as Carsten suggested). At the end of the day, what I'm asking is that we wait until vlt has been moved to ASF before judging it. My belief, based on some experience embedding vlt, is that the issues raised in this thread are relatively easy to resolve. Certainly easier than creating a new thing. Justin On Fri, May 31, 2013 at 8:21 AM, Dominik Süß dominik.su...@gmail.comwrote: One comment about content.xml - in our CQ solutions we do use the Sling-Initialcontent (with the much nicer json files placed parallel to the folders with the same name instead of .content.xml underneath) instead of packing it directly in the vault based packages. This leads to a clean and much better searchable filestructure. The code at least for the jcr installation is yet there so this json based syntax would be an option that allready works. The syntax is exactly what you get from the default GET Servlet dumping the structure as json. The only drawback to vault is that synchronisation is just in direction of the repository, no export (but dumping via the default get servlet). Cheers Dominik On Fri, May 31, 2013 at 2:14 PM, Carsten Ziegeler cziege...@apache.org wrote: Some time ago I thought about this and had the following idea: - we define a packaging for resources - this can be used to represent the resources in the file system or in a zip file - if a resource is a file, it is represented as a file with the same name - if a resource is not a file, it is represented as a directory - properties if a non-file resource, and all additional metadata of a file is stored in a [content].xml (or json) This would allow browsing through the file system to the resource you want to edit and just edit the properties of this resource in a file. It makes syncing very easy and fast. Maybe we can distinguish between a resource which might have child nodes and one that doesn't and make the mapping differently. In any case the whole mechanism needs some research, a disadvantage might be if you map a huge resource tree which has no files at all to the file system, this will result in a huge directory tree instead of one large content.xml - however as we're talking about developer tooling, we can neglect this. Just a rough idea Carsten 2013/5/31 Robert Munteanu romb...@apache.org On Thu, 2013-05-30 at 20:48 -0700, Ruben Reusser wrote: is the vlt sync now actually updating .content.xml files? I thought it can only sync regular files. I'm frankly more of an IDE guy than a VLT guy from a development experience point of view. However, I think that the IDE is the right place for the change detection/sync capabilities, while VLT will be a mechanism from transporting changes from/to the repository. Robert -- Carsten Ziegeler cziege...@apache.org
Re: [tooling] Moving forward with IDE tooling
I personally think creating a new thing from scratch is easier, sure there might a little bit of work - but on the other hand it comes with a lot of benefits. However, whoever does the work can decide - and why not having more than one prototype and then see whats the better way? Or in other words, I think it makes sense at least to think about this issue green field without already having existing solutions prediction the final solution. Carsten 2013/5/31 Justin Edelson jus...@justinedelson.com Hi, These are all excellent points. I am a bit confused about mentions of the Sling Resource API. This is a server-side API while we are discussing client code. AFAIK we don't have a client implementation of the Resource API nor do we have a standard transport mechanism. We do have the default GET and POST servlets, but as Robert pointed out in the wiki, those can't be depended upon consistently. The points Carsten and Dominik point to something broader - not using vlt (and the content packing process in general) necessitates defining packaging and deployment mechanisms. After all, it wouldn't be acceptable to have a way to develop and application without being able to deploy it. With vlt, these mechanisms are defined already (whether these mechanisms are ideal or not is a separate problem). One option is to use Sling-InitialContent and POST to the webconsole (as Dominik suggested); another is to build something new (as Carsten suggested). At the end of the day, what I'm asking is that we wait until vlt has been moved to ASF before judging it. My belief, based on some experience embedding vlt, is that the issues raised in this thread are relatively easy to resolve. Certainly easier than creating a new thing. Justin On Fri, May 31, 2013 at 8:21 AM, Dominik Süß dominik.su...@gmail.com wrote: One comment about content.xml - in our CQ solutions we do use the Sling-Initialcontent (with the much nicer json files placed parallel to the folders with the same name instead of .content.xml underneath) instead of packing it directly in the vault based packages. This leads to a clean and much better searchable filestructure. The code at least for the jcr installation is yet there so this json based syntax would be an option that allready works. The syntax is exactly what you get from the default GET Servlet dumping the structure as json. The only drawback to vault is that synchronisation is just in direction of the repository, no export (but dumping via the default get servlet). Cheers Dominik On Fri, May 31, 2013 at 2:14 PM, Carsten Ziegeler cziege...@apache.org wrote: Some time ago I thought about this and had the following idea: - we define a packaging for resources - this can be used to represent the resources in the file system or in a zip file - if a resource is a file, it is represented as a file with the same name - if a resource is not a file, it is represented as a directory - properties if a non-file resource, and all additional metadata of a file is stored in a [content].xml (or json) This would allow browsing through the file system to the resource you want to edit and just edit the properties of this resource in a file. It makes syncing very easy and fast. Maybe we can distinguish between a resource which might have child nodes and one that doesn't and make the mapping differently. In any case the whole mechanism needs some research, a disadvantage might be if you map a huge resource tree which has no files at all to the file system, this will result in a huge directory tree instead of one large content.xml - however as we're talking about developer tooling, we can neglect this. Just a rough idea Carsten 2013/5/31 Robert Munteanu romb...@apache.org On Thu, 2013-05-30 at 20:48 -0700, Ruben Reusser wrote: is the vlt sync now actually updating .content.xml files? I thought it can only sync regular files. I'm frankly more of an IDE guy than a VLT guy from a development experience point of view. However, I think that the IDE is the right place for the change detection/sync capabilities, while VLT will be a mechanism from transporting changes from/to the repository. Robert -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
Re: [tooling] Moving forward with IDE tooling
Before you read this, please a) excuse my ignorance of Sling build tools, I'm just getting started with pure Sling and b) feel free to inform my of said ignorance :D I use Maven and Jenkins to do automated builds of our CQ project at work. For development we use a combination of maven and vault with the vaultclipse plugin. With vaultclipse it is as simple as a couple clicks and a second or two to update the running local CQ instance with your code / css / images (anything) you have just changed. If you need to do a full build you just use Maven. When I recently started working with pure Sling I was surprised to see there was no equivalent way of working. (or maybe there is?) So my workflow with Sling is that I use maven to deploy my project on my ec2 server (with Jenkins) and when working locally, but I also have a quick and dirty file editor based on the Editarea JS library that I use to edit jsps etc in the browser and save changes using the Sling Post Servlet. I built this because I was tired of waiting 20+ seconds to deploy my whole project for a simple css change... It would be nice to have vault working with Sling, it has a lot of functionality including copying content between two separate servers (vault rcp) and an already complete eclipse plugin 'vaultclipse', maybe it could be extended to handle things on a more Sling Resource level than a JCR level, but right now that's where we're at so why not use this tool to it's best abilities. Another downside I've noticed using maven with Sling bundle resources the impore doesn't set the JCR node types, so no sling:Folder etc settings, this is making a tree browser harder for me to write... With 'packages' and the vault maven plugin I believe all content loaded this way would get proper sling node types correct? Ok, this noob just couldn't resist to chime in please continue on the discussion :) Thanks, Adam On Fri, May 31, 2013 at 10:36 AM, Ruben Reusser r...@headwire.com wrote: I think the use case of doing maven/jenkins builds and continuous integrations should also be considered here. Most CQ projects at this time seem to be using maven builds that create packages that can be deployed to CQ. Since VLT is open sourced and since the packaging part is also in VLT I'd expect that to be open sourced as well. vlt sync would actually work if it did manage the .content.xml files as well (didn't it do that in the beginning - seems that feature was removed?) allowing developers to change their code either in the ide or crxde|lite and having the code sync'd to the file system for checkin and separate builds for CI. Breaking this experience may be a big problem. Ruben On 5/31/2013 7:27 AM, Dominik Süß wrote: One problematic part about serialisation is structuredepth. In development you might not want to handle complex structures by shifting folders around, so it would be nice to have a format that allows to define a substructure, so in the Sling Initialcontent you might even define one big JSON that defines the complete structure. The consequence of that if you also need to be able to export changes to the filesystem it isn't clear when things should be handled within a file, and when to break up in folderstructures. In vault this is implicitly solved for specific nodetypes. E.g. in cq a dialog always gets exportet to a specific xml file covering this explicit substrutcture in one aggregated file. But still even in vault you can have situations where you define substructures in the .content.xml which leads to an instant asynchronity with the repository since vault tries to synch that as folder/file structure. I currently have no idea for good solution, but in any case these problems should be solved. Dominik On Fri, May 31, 2013 at 3:19 PM, Robert Munteanu romb...@apache.org wrote: On Fri, 2013-05-31 at 21:14 +0900, Carsten Ziegeler wrote: Some time ago I thought about this and had the following idea: - we define a packaging for resources - this can be used to represent the resources in the file system or in a zip file - if a resource is a file, it is represented as a file with the same name - if a resource is not a file, it is represented as a directory - properties if a non-file resource, and all additional metadata of a file is stored in a [content].xml (or json) Good point, added https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDEhttps://cwiki.apache.org/confluence/display/SLING/Sling+IDE +tooling#SlingIDEtooling-**Resourceserializationformat to capture the proposal / points to discuss. Robert This would allow browsing through the file system to the resource you want to edit and just edit the properties of this resource in a file. It makes syncing very easy and fast. Maybe we can distinguish between a resource which might have child nodes and one that doesn't and make the mapping differently. In any case the whole mechanism needs some research, a
[jira] [Resolved] (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 resolved SLING-2863. - Resolution: Fixed Fix Version/s: Scripting JSP-Taglib 2.1.10 I used Geranimo's JSTL implementation instead of the Sling one, since that has already been released. Otherwise, the list is updated and should be good to go now. Once the next TagLib release is complete, I will update the release with the new TagLib version. 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 Fix For: Scripting JSP-Taglib 2.1.10 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
[jira] [Resolved] (SLING-2809) broken link
[ https://issues.apache.org/jira/browse/SLING-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco resolved SLING-2809. - Resolution: Fixed [~calinb] I believe this issue is resolved, I was also able to fix a number of other broken links on the new site. Please check and let me know if you are still having the issue. broken link --- Key: SLING-2809 URL: https://issues.apache.org/jira/browse/SLING-2809 Project: Sling Issue Type: Bug Components: Site Reporter: Blaga Calin Assignee: Dan Klco Priority: Minor There is a broken link, it's anchor(named Development) can be found here: http://sling.apache.org/ at the section Contents. -- 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] [Commented] (SLING-2893) Add documentation and integration tests to verify XML parsing functionality
[ https://issues.apache.org/jira/browse/SLING-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671574#comment-13671574 ] Robert Munteanu commented on SLING-2893: Added an XPath test in http://svn.apache.org/viewvc?view=revisionrevision=1488272 Add documentation and integration tests to verify XML parsing functionality --- Key: SLING-2893 URL: https://issues.apache.org/jira/browse/SLING-2893 Project: Sling Issue Type: Test Components: Documentation, Testing Reporter: Robert Munteanu Priority: Minor We have recently been asked about XML parsing functionality on the user's list : [0] . We should have integration tests to validate the functionality and documentation to describe how it works. [0]: http://sling.markmail.org/thread/qoti6pbjx566vl5i -- 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
On Fri, 2013-05-31 at 10:40 -0400, Justin Edelson wrote: Hi, These are all excellent points. I am a bit confused about mentions of the Sling Resource API. This is a server-side API while we are discussing client code. AFAIK we don't have a client implementation of the Resource API nor do we have a standard transport mechanism. We do have the default GET and POST servlets, but as Robert pointed out in the wiki, those can't be depended upon consistently. The current integration uses HTTP calls, and I don't expect to develop an actual API. But I think we can enhance the server-side API to be able to get all the data using GET requests. The points Carsten and Dominik point to something broader - not using vlt (and the content packing process in general) necessitates defining packaging and deployment mechanisms. After all, it wouldn't be acceptable to have a way to develop and application without being able to deploy it. With vlt, these mechanisms are defined already (whether these mechanisms are ideal or not is a separate problem). One option is to use Sling-InitialContent and POST to the webconsole (as Dominik suggested); another is to build something new (as Carsten suggested). Agreed. At the end of the day, what I'm asking is that we wait until vlt has been moved to ASF before judging it. My belief, based on some experience embedding vlt, is that the issues raised in this thread are relatively easy to resolve. Certainly easier than creating a new thing. Agreed again. We'll definitely use vlt, and the implementation will definitely be vlt-heavy, at least to get a 1.0 version running. Or 0.9, to set expectations about backwards compatibility. Robert Justin On Fri, May 31, 2013 at 8:21 AM, Dominik Süß dominik.su...@gmail.comwrote: One comment about content.xml - in our CQ solutions we do use the Sling-Initialcontent (with the much nicer json files placed parallel to the folders with the same name instead of .content.xml underneath) instead of packing it directly in the vault based packages. This leads to a clean and much better searchable filestructure. The code at least for the jcr installation is yet there so this json based syntax would be an option that allready works. The syntax is exactly what you get from the default GET Servlet dumping the structure as json. The only drawback to vault is that synchronisation is just in direction of the repository, no export (but dumping via the default get servlet). Cheers Dominik On Fri, May 31, 2013 at 2:14 PM, Carsten Ziegeler cziege...@apache.org wrote: Some time ago I thought about this and had the following idea: - we define a packaging for resources - this can be used to represent the resources in the file system or in a zip file - if a resource is a file, it is represented as a file with the same name - if a resource is not a file, it is represented as a directory - properties if a non-file resource, and all additional metadata of a file is stored in a [content].xml (or json) This would allow browsing through the file system to the resource you want to edit and just edit the properties of this resource in a file. It makes syncing very easy and fast. Maybe we can distinguish between a resource which might have child nodes and one that doesn't and make the mapping differently. In any case the whole mechanism needs some research, a disadvantage might be if you map a huge resource tree which has no files at all to the file system, this will result in a huge directory tree instead of one large content.xml - however as we're talking about developer tooling, we can neglect this. Just a rough idea Carsten 2013/5/31 Robert Munteanu romb...@apache.org On Thu, 2013-05-30 at 20:48 -0700, Ruben Reusser wrote: is the vlt sync now actually updating .content.xml files? I thought it can only sync regular files. I'm frankly more of an IDE guy than a VLT guy from a development experience point of view. However, I think that the IDE is the right place for the change detection/sync capabilities, while VLT will be a mechanism from transporting changes from/to the repository. Robert -- Carsten Ziegeler cziege...@apache.org
Re: [tooling] Moving forward with IDE tooling
Hi Adam, On Fri, 2013-05-31 at 10:58 -0400, Adam Yocum wrote: It would be nice to have vault working with Sling, it has a lot of functionality including copying content between two separate servers (vault rcp) and an already complete eclipse plugin 'vaultclipse' Once open-sourced, you will be able to work with vlt on pure Sling applications, not only with CQ applications. Robert On Fri, May 31, 2013 at 10:36 AM, Ruben Reusser r...@headwire.com wrote: I think the use case of doing maven/jenkins builds and continuous integrations should also be considered here. Most CQ projects at this time seem to be using maven builds that create packages that can be deployed to CQ. Since VLT is open sourced and since the packaging part is also in VLT I'd expect that to be open sourced as well. vlt sync would actually work if it did manage the .content.xml files as well (didn't it do that in the beginning - seems that feature was removed?) allowing developers to change their code either in the ide or crxde|lite and having the code sync'd to the file system for checkin and separate builds for CI. Breaking this experience may be a big problem. Ruben On 5/31/2013 7:27 AM, Dominik Süß wrote: One problematic part about serialisation is structuredepth. In development you might not want to handle complex structures by shifting folders around, so it would be nice to have a format that allows to define a substructure, so in the Sling Initialcontent you might even define one big JSON that defines the complete structure. The consequence of that if you also need to be able to export changes to the filesystem it isn't clear when things should be handled within a file, and when to break up in folderstructures. In vault this is implicitly solved for specific nodetypes. E.g. in cq a dialog always gets exportet to a specific xml file covering this explicit substrutcture in one aggregated file. But still even in vault you can have situations where you define substructures in the .content.xml which leads to an instant asynchronity with the repository since vault tries to synch that as folder/file structure. I currently have no idea for good solution, but in any case these problems should be solved. Dominik On Fri, May 31, 2013 at 3:19 PM, Robert Munteanu romb...@apache.org wrote: On Fri, 2013-05-31 at 21:14 +0900, Carsten Ziegeler wrote: Some time ago I thought about this and had the following idea: - we define a packaging for resources - this can be used to represent the resources in the file system or in a zip file - if a resource is a file, it is represented as a file with the same name - if a resource is not a file, it is represented as a directory - properties if a non-file resource, and all additional metadata of a file is stored in a [content].xml (or json) Good point, added https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDEhttps://cwiki.apache.org/confluence/display/SLING/Sling+IDE +tooling#SlingIDEtooling-**Resourceserializationformat to capture the proposal / points to discuss. Robert This would allow browsing through the file system to the resource you want to edit and just edit the properties of this resource in a file. It makes syncing very easy and fast. Maybe we can distinguish between a resource which might have child nodes and one that doesn't and make the mapping differently. In any case the whole mechanism needs some research, a disadvantage might be if you map a huge resource tree which has no files at all to the file system, this will result in a huge directory tree instead of one large content.xml - however as we're talking about developer tooling, we can neglect this. Just a rough idea Carsten 2013/5/31 Robert Munteanu romb...@apache.org On Thu, 2013-05-30 at 20:48 -0700, Ruben Reusser wrote: is the vlt sync now actually updating .content.xml files? I thought it can only sync regular files. I'm frankly more of an IDE guy than a VLT guy from a development experience point of view. However, I think that the IDE is the right place for the change detection/sync capabilities, while VLT will be a mechanism from transporting changes from/to the repository. Robert
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #1677
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/1677/
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #1677
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing-war/1677/
Jenkins build became unstable: sling-trunk-1.6 #1677
See https://builds.apache.org/job/sling-trunk-1.6/1677/changes
Disabling flaky tests
Hi, It seems that the ErrorHandlingTest fails sporadically when run inside a full maven build. I've tried locating the root cause for a couple of hours but failed. For this test, and for future flaky/failing tests, I suggest that we 1. Create an issue for the failing test 2. Disable the test and mark it with the issue key 3. Re-enable the test when it is stable/passing ( which may be considerably later than step 2) 4. Close the issue after the test is re-enabled This has the advantage of keeping the build green and making it easier to find regressions since a failing or unstable build will actually mean something. What do you think? Robert
Re: [tooling] Moving forward with IDE tooling
Hi, I've added the requirements for autosync to [1]. Although VLT does a good job of this once setup I don't use CLI for editing and manipulating. I use the IDE 100% with all its other tooling and just File Save. Setup with VLT is 2 commands and a 1 line config file edit, which could easily be converted into a IDE plugin. Having thought about it, I think the reason vlt sync works well is that Sling is on the same box, monitoring the file system for changes, (I think thats right, there is no local process with vlt sync) and monitoring JCR for changes, which avoids lots of processing and http traffic. When I have used other forms of integration on large repositories, the volume http traffic and speed of response has nearly always made them unusable. What ever is used or reimplemented it must not rely on scanning a repository to know what has changed. It must relay on notification of some form so that Edit-Save-Refresh is never more than a few seconds, and doesn't impact the Sling server resource usage. Ideally notification should not rely on the IDE, since changes can be made without the IDE running, and routing it via the IDE is going to get really confusing with 3 or more potential sources of updates. (assuming code under version control) HTH Ian 1. https://cwiki.apache.org/confluence/display/SLING/Use+Cases On 31 May 2013 14:07, Ian Boston i...@tfd.co.uk wrote: @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
