[CONF] Apache Sling > Sling IDE tooling

[confluence]

Sling IDE tooling Page edited by Robert Munteanu Changes (2) h1. Sling IDE tooling 1.0 {toc} The 1.0 release will be a release with minimal release which will allow users to sync content between their IDE and the repository. ... # Does not work reliably if the DefaultGetServlet is not active for a certain resource h2. Eclipse implementation h3. High-level pieces * WST Server - we will use the Eclipse web tools platform to provide UI elements ( server definition, start/stop actions, module deployments ) * Content module - we will define a content module which uses the transport API to sync content from the workspace into the repository. The mechanism is controlled by the WST server definitions * Transport API bridge - links between the core transport APIs and the Eclipse build/resource APIs We will inherit some code from the current implementation, and need to work out a way to export content from the repository into the workspace with the proposed UI flow. h2. Intellij Implementation h3. High-level pieces * Application server - uses the IntelliJ application server framework * Transport API bridge - links between the core transport APIs and the IntelliJ build/resource APIs Full Content Sling IDE tooling 1.0 Sling IDE tooling 1.0 Naming Platform support High-level architecture Core services Server control Transport API Transport implementations VLT transport Lightweight HTTP-based transport Eclipse implementation High-level pieces Intellij Implementation High-level pieces The 1.0 release will be a release with minimal release which will allow users to sync content between their IDE and the repository. Naming Our IDE tooling should not focus on a single IDE and the naming should reflect that. Possible names Sling Developer Tools Sling IDE Platform support We will aim to support Eclipse and IntelliJ with a first 1.0 release. High-level architecture Core services The core services will be IDE-agnostic and aim to support all platforms. As such, they will be constrained to not use specific APIs. Eclipse mandates that all I/O operations be done using its resource layer. Server control The server control service will handle communication with a Sling Launchpad instance, including connecting ( validating credentials ) starting and stopping ( only possible for JAR-based launchpad ) Transport API Contains the APIs needed to connect to Sling launchpad and import/export content. Transport implementations VLT transport File vault is in process of being donated to to ASF and is a good candidate for a transport implementation. Pros Mature application and library Already used to import, export and sync content Cons Works at JCR, not at resource level Lightweight HTTP-based transport The current implementation is based on the Sling DefaultGetServlet and DefaultPostServlet and is another candidate for a transport implementation. Pros Works at resource level Cons Does not work reliably if the DefaultGetServlet is not active for a certain resource Eclipse implementation High-level pieces WST Server - we will use the Eclipse web tools platform to provide UI elements ( server definition, start/stop actions, module deployments ) Content module - we will define a content module which uses the transport API to sync content from the workspace into the repository. The mechanism is controlled by the WST server definitions Transport API bridge - links between the core transport APIs and the Eclipse build/resource APIs We will inherit some code from the current implementation, and need to work out a way to export content from the repository into the workspace with the proposed UI flow. Intellij Implementation High-level pieces Application server - uses the IntelliJ application server framework Transport API bridge - links between the core transport APIs and the IntelliJ build/resource APIs Change Notification Preferences View Online | View Changes | Add Comment