Eclipse Summit on Runtime Technologies and Platforms Minutes

Attendees

• Ricco Deutscher, SOPERA - Company leading the Eclipse Swordfish project
• Jeff McAffer, IBM - Leading the Eclipse Equinox project
• Jochen Krause, Innoopract - Leading the Eclipse RAP project
• Mike Milinkovich, Eclipse Foundation
• Chris Aniszczyk, IBM - involved in PDE, interested in impact on tooling
• Ian Skerrett, Eclipse Foundation - Director of marketing
• Doug Clarke, Oracle Corporation - Leading the EclipseLink project
• Eric Newcommer, IONA + Chair of OSGi Enterprise Group
• Ed Merks, IBM - Leading the Eclipse EMF project
• Adam Lieber, webtide - Company produces Jetty, interested in embedding Equinox, provide services (e.g. http, servlet) for Equinox
• Oliver Wolf, SOPERA - Leading the Eclipse Swordfish project
• Scott Stark, Red Hat - Involved in the development of the JBoss app server, interested in impact on tooling, interoperability with JBoss 5 kernel
• Brett Wooldridge, AlterPoint Inc./ZipTie.org - developed an osgi based app server
• Oleg G., eBay - Open Source architect, interested in impact on tooling
• Jason van Zyl, Sonatype - Apache Maven, integration with Equinox
• Konstantin Komissarchik, BEA - Committer Rep at Eclipse, involved in WTP, interested in leveraging Eclipse runtime technology
• Michael Cote', RedMonk
• Scott Lewis, BEA - working on a BEA Eventserver which is built on top of Equinox, want to provide feedback / input, interested in collaboration
• Bjorn Freeman-Benson, Eclipse Foundation
• Philippe Ombredanne, nexB, Committer of ATF, Visual Editor, helps to manage Google of Code, interested in provisioning, go beyond Java in the runtime

Agenda and Results

The agenda and associated materials are captured in a slide deck. The slides were updated during the summit to reflect the discussion and afterwards we created a report.

Presentation of existing runtime technologies with selected short talks (5 minutes)

• Equinox
• EclipseLink
• Swordfish
• EMF
• RAP
• ECF
  • http://wiki.eclipse.org/index.php/ECF_API_Docs#Datashare_API - Datasharing
  • http://wiki.eclipse.org/index.php/ECF_API_Docs#File_Transfer_API used by p2
  • http://wiki.eclipse.org/index.php/ECF_API_Docs#Remote_Services_API
  • http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/weblogic/event_server/ Adoption of Equinox by BEA

Adopter feedback (what is missing, what proved to be difficult)

• is Eclipse is competition with .net?
  • .net is more like a JVM, and it is very comprehensive
  • competing with .net is not a good goal
  • componentization framework is missing in .Net
• decomposable features of the runtime -
  • intersecting services: persistence, security, transactions, remoting, clustering - jee6 is working on those topics too
    • osgi services could provide an answer - we might need to drive the standardization of services at OSGi
    • how about multiple versions - mostly solved by osgi
    • what are the provided services - leverage existing (standards based) technology instead of competing with it
  • pick and choose bundles that provide the functionality you need (JAXB, JPA, ...)
  • but what about missing pieces, are they difficult in integrate (EJB)
• what is the OSGi runtime at Eclipse, couldn't find it
• coexistence with existing technology should be a major goal
  • not rip and replace model
  • Dependency management (maven)
  • how do we integrate with existing technology, especially how does EE integrate
• if we are serious about runtime, we need a top level project
  • info is difficult to find
  • "create community of interests" for particular domains
• are the additional layers producing too much overhead - provide relevant benchmarks

Where are we heading with runtime technologies (which pieces will / should be coming)

• runtimes and tooling are symbiotic
• tools should be applicable to all standard based projects, not juet for specific eclipse runtimes. But they may have extensions that enable particular Eclipse runtime
• today there is runtime technology in existence which is integrated in tools, examples are Meta-data processing in DTP, compile in JDT (Jasper), annotation engine
• get projects into a mindset that some of the today tooling capabilities are applicable to runtime usage
  • like to use JDT in a runtime (possible with ECJ Eclipse compiler for Java)
  • line between tools and runtime may blur
  • runtime functionality can stay in tools projects, there is no need to move technology
• runtimes may not have a dependency on tools, that may require refactoring of existing projects
• there is a redundancy between WTP Server deployment and p2, there is discussion going on in an early stage
• application middleware services based on Equinox
  • it is not intended to be everything, it is very much community driven
  • is osgi a sufficent kernel for dependency management and deployment?
  • Example of "Integration of Eclipse runtime technologies": Usage of RAP with EclipseLink persistence should be possible "out of the box"
  • is there value in staying OSGi implementation neutral - be as standard compliant as possible will be a goal for many projects, but it might not be possible for all projects
• feed Equinox extensions of OSGi back into the OSGi standardization
  • should we label projects on how far they can be run other OSGi implementations?
• make sure that the tooling remains agnostic to runtimes (based on standards) - Dali should still be usable for Hibernate based JPA, not only for EclipseLink
  • some Eclipse tooling projects may need to define their relationship to Eclipse runtime technologies
  • potential conflict by adoption of runtime technologies by tools (e.g. usage of EclipseLink as a persistence mechanism within a tool)
• is there a clear committment of what the runtime efforts will offer -> no, it is community driven and opportunistic in nature
• can we "scope it down" do avoid that an app server is built at Eclipse? -> no, but we offer the Eclipse governance, namely building extensible platforms, enabling commercial differentiation on top, predictability and controlled processes
• the runtime project will enable adopters to build solutions from off the shelf components (lego blocks). Components should be replacable by commercial counterparts.
• There has been discussion about how to spec the integration points that ended in an update of the slides

Relationship to other communities (e.g., Spring, Apache, ...)

• [OSGi Enterprise working group|http://www.osgi.org/about/charter_eeg.asp?section=1] - current working areas
  • Spring will likely play a bigger role in Declarative Services
  • standardization of distributed OSGi runtimes (Service discovery)
  • NOT define a new distributed technology, but how to "embed existing technology", define an abstraction that enables different distributed computing technologies
  • Security
  • classloading improvements
  • management (deployment) / remote management
  • relational database service
  • JEE modularity
  • Intentions to provide reference implementations for distributed OSGi based on Tuscany, ServiceMix and Spring
• leverage existing technology instead of competing with it (e.g. Swordfish reuses ServiceMix)

What is the community? What do they want? How to grow the community?

• Showcases / Tutorials
• Success stories, supporters
• hire someone to provide information - organize it
• better search
• a landing page that explains "the mindset"

A new top level project - who may / will participate?

• a top level project is the way we should be going
• Interested projects: Equinox, ECF, RAP, Swordfish, EclipseLink, maybe eRCP

Discussion on draft charter for a runtime top level project

Draft charter has been revised and agreed upon by the group

Delivery strategy

• should definetly have a joint release
• probably have a separate release train
• foster communities that have license incompatible technology by enabling integration testing

Naming

• Equinox already has mindshare
• Story: started out as Incubator, brought OSGi to the Eclipse Platform, now expanding to a broader scope
• Equinox is an awfully nice name
• There is a concern however that broadening the meaning will cause confusion and dilute the meaning