This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Sling IDE tooling 1.0

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

  1. Mature application and library
  2. Already used to import, export and sync content

Cons

  1. 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

  1. Works at resource level

Cons

  1. 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
  • No labels