Sling IDE Tooling @ adaptTo 2013
•
4 likes•2,089 views
This talk contains an overview of the Sling IDE tooling which has been under development under the Apache Sling project for the last year. It will focus on how a developer can connect his/her IDE to an Apache Sling installation and develop against it without the need to use other tools. We will also provide an intro to the technical foundations of the IDE tooling, for those interested in contributing.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (7)
Similar to Sling IDE Tooling @ adaptTo 2013
Similar to Sling IDE Tooling @ adaptTo 2013 (20)
More from Robert Munteanu
More from Robert Munteanu (20)
Recently uploaded
Recently uploaded (20)
Sling IDE Tooling @ adaptTo 2013
- 1. APACHE SLING & FRIENDS TECH MEETUP BERLIN, 23-25 SEPTEMBER 2013 Sling IDE Tooling Robert Munteanu – rombert@apache.org
- 2. A little bit about myself 2 ● Apache Sling committer ● Long-time Open Source developer ( MantisBT , Eclipse Mylyn Connectors ) ● Working on Adobe CQ adaptTo() 2013
- 3. Agenda adaptTo() 2013 3 ● Why did we start working on IDE tooling? ● What have we done so far? ● What do we want to do next? ● How is the IDE tooling developed?
- 4. Why did we start work on IDE tooling? 4 [INFO] --- maven-sling-plugin:2.1.0:install (default-cli) @ ui --- [INFO] Installing Bundle ui(.../ui/target/ui-0.1-SNAPSHOT.jar) to http://localhost:8080/system/console via POST [INFO] Bundle installed [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] Sling Content Explorer - UI ....................... SUCCESS [5.85s] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 5.850s adaptTo() 2013
- 5. Why did we start work on IDE tooling? 5adaptTo() 2013 JCR Repository nt:file nt:folder nt:unstructured Dav Client
- 6. Why did we start work on IDE tooling? 6adaptTo() 2013 Sling Repository JCR Resource Provider FileSystem Resource Provider Local workspace
- 7. Why did we start work on IDE tooling? 7 $ vlt --version Jackrabbit FileVault [version 3.0.0-SNAPSHOT] Copyright 2013 by Apache Software Foundation. See LICENSE.txt for more information. $ vlt up Connecting via JCR remoting to http://localhost:8080/server U var/sling/bundle- content/org.apache.sling.launchpad.content/.content.xml U var/sling/bundle-content/ui/.content.xml U var/discovery/impl/clusterInstances/2fd93037-3e2c-48a3-a295- 26fb5d3a999f/.content.xm U apps/jcrtest/install/some.config.pid.xml U libs/sling/servlet/default/authenticate.jsp U libs/sling/servlet/default/edit-body.jsp U libs/sling/servlet/default/properties-custom.jsp adaptTo() 2013
- 8. Intermission – FileVault primer 8 <workspaceFilter vesion="1.0"> <filter root="/apps/slingDemo"> <exclude pattern="^.*/form.*$" /> </filter> <filter root="/content/slingDemo"/> </workspaceFilter> adaptTo() 2013
- 9. Intermission – FileVault primer 9adaptTo() 2013
- 10. Intermission – FileVault primer 10 <jcr:root jcr:primaryType="sling:Folder" jcr:mixinTypes="[vlt:FullCoverage]" jcr:title=“My Sling Folder“> <my-child-node jcr:primaryType="nt:unstructured" jcr:title="My child node..." tags="[to-review,to-dispatch]" visible="{Boolean}false" publishTime="{Date}2013-09-04T10:00:00.000+03:00"/> </jcr:root> adaptTo() 2013
- 11. What have we done so far? adaptTo() 2013 11 ● Oct 2012 – Slingclipse first announced by Antonio Sanso ● May 2013 – Plans set out for initial release for Sling IDE Tooling ● Aug 2013 – FileVault donated to ASF ● Sep 2013 – FileVault included in Sling IDE Tooling Preview
- 12. What have we done so far? adaptTo() 2013 12 Demo time ● Server definition ● Content synchronization ● Bundle redeploy
- 13. What do we want to do next? adaptTo() 2013 13 Sling IDE Tooling Roadmap ● Community involvement – users and contributors ● Stabilize and deliver Eclipse tooling 1.0 ● Investigate tooling for other IDEs ● $YOUR_FEATURE_HERE
- 14. How is the IDE tooling developed? adaptTo() 2013 14 Eclipse Core UI m2e-UI Content Sync FileVault Resource APIs and Core Utilities Transport Filter Serialize
- 15. Resources adaptTo() 2013 15 ● Sling IDE Tools preview update site – http://people.apache.org/~rombert/slin g/ide/preview/ http://s.apache.org/sling-ide-preview ● Sling IDE Tools codebase - http://svn.apache.org/repos/asf/sling/b ranches/tooling-ide-vlt/tooling/ide/ (soon to move to trunk)
- 17. Thank you adaptTo() 2013 17
Editor's Notes
- A couple of words about myself ; I'm primarily a Java developer, with occasional breakouts in web development. I have a long history of contributing to Open Source projects and am currently working at Adobe on CQ. And here's a less-than-140-characters quote on how I feel about Sling and the surrounding ecosystem (… ). Of course, 'hacking late at night' and 'need to finish presentation for and code for adaptTo' are two completely unrelated events, don't let anyone tell you otherwise.
- Here's what I want to go over in the next 60-odd minutes. We'll have a general Q&A session at the end. In the meantime, if you have very specific questions about the topic I'm discussing, please interrupt me. I watch out of InterruptedExceptions and resume gracefuly with no memory corruption ;-)
- There are a number of ways of getting content into your Sling instance at development time. I'm only going to focus on development time, and only on Open-Source, Sling-applicable solutions. Probably the most obvious solution is to use the maven tooling. There's absolutely nothing wrong with it, and it's a solid approach. You can deploy Java code and you can deploy content using the Sling-Initial-Content approach. By show of hands, how many of you practice this approach at development time? The only critique to this approach is that it's not IDE-driven. It's not incremental. You have to Alt-TAB ( or Cmd-Tab, if you will ) out of your IDE to do that. And it's not instant. Typically UX/HCI rules of the thumb are – 0.1 seconds means instant, 1 second is noticeable, but does not interrupt flow, 10 seconds means loss of focus. Now this example might be about a large content deployment, but nevertheless ; I don't want to switch programs. Otherwise I'd be happy with vim, the git cli and curl. And trust me, even though I'm a Linux die-hard and very comfortable using the CLI, I prefer Eclipse.
- Another way of doing development is webdav. The JCR repository wrapped by Sling 'speaks' WebDavish. If you have a client which speaks the same tongue, you're all set. You can modify files, directories … and that about does it. Again, by show of hands, does anyone use webdav at development time? Notice that I mentioned three node types, webdav handles nt:file, nt:folder and their derivatives nicely, but does not ( and probably can not ) handle other kinds of nodes, or metadata attached to file-like and folder-like nodes. And another roadblock is that it doesn't work directly with my IDE. Even if it would, a remote FS is very unpredictable when it comes to performance, and I for one am very sensitive about performance, and I supposed you are as well.
- Another approach – and one which I find quite elegant is the FS Resource Provider. Instead of trying to pull the content from the repository, it uses the Sling ResourceProvider extension point to mount the local filesystem in the repository. This approach has been demo'ed in the Rookie session, for those that were there. Now, surprise, surprise, by show of hands, who uses this at development time? Again, this approach works fine if you want to work with files and folders only. It doesn't support arbitrary node types though, and has the disadvantage of your content not really being in the repository. That is not a problem for green-field projects, but in long-running projects which are coded against the JCR API this doesn't fly. And, of course, there are many valid reasons to code against the JCR API.
- A fairly recent addition to my list of development-time approaches is using the FileVault CLI interface. FileVault was donated to the ASF as part of the Jackrabbit project in August. Those of you working with CQ are probably familiar with it, but anyway... FileVault is a project ( java library, OSGi bundle, CLI tool ) which provides a JCR repository to filesystem mapping. VLT is the CLI tool, and it provides operations similar to the svn CLI tool: import/export, checkin/checkout, diff etc. It's incremental, and defines a representation format for arbitrary content structures. It also has a format for defining arbitrary filters which map repositories to workspaces.
- This is how FileVault defines its filters. The root element is a (surprise) workspace filter, and it can contain one to N filter entries. Each filter defines a root – and that's all it can hold. For instance the second filter matches everything under /content/slingDemo. But it can also user patterns to include/exclude content. One use case is to exclude user-generated content. And that's what the first filter aims to do, checkout everything except for nodes whose name starts with 'form' .
- I've mentioned that FileVault can serialize arbitrary content to disk. To be brief, content which is not covered by regular file or folder attributes in the filesystem is converted into a .content.xml file, which holds all those extra attributes.
- Some node types will be compacted into a full xml file. This node type can be of arbitrary depth, and fully covers the node structure beneath it. For brevity, I've shown how a node ( jcr:root ) and a child node ( my-child-node ) are represented. Note that we properly represent multi-valued properties ( tags ), non-String properties ( visible, publishTime ). And if you're wondering – why on Earth are we taking a crash course in FileVault instead of seeing the Sling IDE tools … stay put :-) we'll be there in a couple of slides.
- These are the major events ( at least IMO ) in the current Sling IDE tooling timeline (read, comment). AS kicked off Slingclipse, out of nowhere. He just came to the mailing list and said – hey, I have this cool Eclipse plugin which does this and that. And made me get off my butt and contribute. So hat tip to Antonio for getting this rolling. In the mean time, we've added two more contributors from the Sling community, and yesterday we've had our first contributor patch. So things are looking up :-) And yes, the reason for going through the FileVault stuff is that it's the primary transport/serialization/filter mechanism for the Sling IDE Tooling.
- And now, Demo time! I've tried to give a not-so-subtle hint that the work we've done so far is Eclipse-only. The reasons are very simple – it's what we use, it's what we know how to develop. But, as you'll see a bit later, we've tried hard to keep some of the parts IDE-independent, so they can be reused in other IDE plug-ins or in any other Java-based environment for that matter.
- As for the roadmap, for me personally the biggest item is to get people on board. And that means both users and contributors. If you know what I mean, nudge, nudge, wink, wink. And I see that as a prerequisite for stabilizing and delivering a first release – whether it's branded as 1.0 or not. And going beyond that, investigating tooling for other IDEs, which is actually a subset of the $YOUR_FEATURE_HERE part, but I wanted it to stand out to make it clear that we're not doing only Eclipse tooling. But, it's up to you to help us decide.
- Going a bit into the 'how stuff happens' part, this is the project structure for the current IDE tooling. First one is the API/Core part. This defines to contracts for how a content sync implementation { transports, filters for inclusion/exclusion, and serializes to/from disk} contents. There are currently two implementations. The main one is FileVault-based, and you've seen how that works. The second one is Resource-based. It's a little greyed out since it's a proof-of-concept rather than production-ready. It was the initial implementation and was used in driving the APIs from the left part of the screen. Now, some people have asked, and with good reason, why two implementations? There are a couple of reasons 1. Testing ; these APIs will allows us to mock Content Sync implementations and create integration tests for the plugins. 2. API cleanliness; FileVault is a mature and capable library, and has its own quirks and peculiarities. Fortunately, so does Eclipse. So we need to find mediate between then and make sure that our impementation is polluted by neither 3. JCR vs Resources; TBH, I wasn't aware of how important this is until I saw this year's Keynote. The point is that FileVault works (beautifully) at the JCR level. Plug in a different resource provider and it stops working. Sooner or later we're going to need supporting it at the resource level. Later on there's the Eclipse-specific stuff. The base implementation works with plain projects, but there's some stuff – namely the project creation wizards, which requires Maven. And since we're at this point, we build everything with Maven.
- If you want to take the plug-in for a spin, the first link is where you can find a p2 update site. The second link is the current source location. You'lll notice it's in a branch, but that's only because we're developing against a SNAPSHOT version of FileVault. Once we get a FileVault release, we'll move back to trunk. And in case you have troubles getting the code or the plug-in, I have the key :-) That is, the p2 update site offline and the code exported from svn.
- Whew, that about covers it. Time for some Q&A.
- So, this guy says it better than I can – thank you! See you at the hackathon.