Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Equinox Summit 2007 Results"
(→Second breakout meeting) |
(→API Tooling) |
||
Line 71: | Line 71: | ||
== Second breakout meeting == | == Second breakout meeting == | ||
=== API Tooling === | === API Tooling === | ||
+ | |||
+ | * Clarify definition of API (what is API, what is API compatibility) | ||
+ | ** Public API (as defined by Jeem's API white paper) | ||
+ | ** Internal code | ||
+ | ** Provisional API | ||
+ | ** SPI - Service provider interfaces | ||
+ | ** Eclipse-specific API such as extension point ids, other data in extension/extension-point markup | ||
+ | * Tool to annotate code with API rules (javadoc tags that specify if a class may be implemented, instantiated, etc) | ||
+ | * Build API rule file from javadoc tags | ||
+ | * Want both IDE integration, and headless build usage | ||
+ | * Scalability | ||
+ | ** Be able to run API tools on smaller components/bundles/pieces rather than the whole world | ||
+ | ** Store results in various forms: XML files, or perhaps database for large scale use | ||
+ | ** API data may be stored locally or remotely | ||
+ | * Discussion on whether API rule files could replace JDT access restrictions. It's really a super-set of access rules, can express things that acess rules cannot | ||
+ | * API usage reports: could have simple HTML pages, or Eclipse integration into views/editors, like the Emma Eclipse plugin does for coverage data | ||
+ | * Support for API tooling in other languages and .so/DLL files | ||
+ | * Use of reflection is problematic because it's hard to detect programmaticaly | ||
+ | |||
=== Server Side Remote Management === | === Server Side Remote Management === | ||
=== P2 Security === | === P2 Security === |
Revision as of 17:16, 25 September 2007
The Equinox Summit 2007 was arranged as a set of lightning talks and a series of breakout sessions. Each session had a number of parallel discussions with self-assigned and self-organizing participants. The groups then reported to a plenary session, summarizing their results and possibly adding more topics to be discussed in further breakouts.
Contents
Day One Results
First breakout meeting
Component Programming Models
- Service helper: ideal for one-time use.
- Spring
- Injection model - no code to acquire the service
- Client is handed a proxy to the service object
- Framework manages binding of a real service to the proxy dynamically
- Distinguish between mandatory and optional service requirements
- Mandatory: your bundle isn't started until all the mandatory services are available
- This only guarantees availability at a moment in time: at the moment of startup all mandatory services are available, but they could disappear after that moment.
- If a mandatory service goes away, the services exported by the bundle needing the service is unregistered.
- For stateful services, there is a listener model - bind an unbind events occur as service implementations arrive and depart
- It would be interesting to be able to declare a default service implementation that would be used whenever no real service is available
- Spring and DS require eager activation, but only for service producers. Many bundles are just service consumers, and so they can be lazily started
- Requirements for Spring service support: Spring core, Spring AOP, a few other essential Spring core pieces
- Service Application Toolkit: IBM toolkit for making it easier to work with OSGi services
- How do we reconcile and combine the various component toolkits available: Spring, DS, SAT, extension registry
- Spring initializes the app context asynchronously. Typical Eclipse programming model assumes that all initialization has completed by the time any classes are loaded in that bundle.
- To be scalable, we need a model where service wiring is persisted across sessions, so we don't have the massive event storm of services being started and bound as the system comes up.
- Most bundles are POJO - how do they specify that they need Spring or some other component system to be available at runtime? Ideally 95% of bundles don't know or care about the active component system - but they need some component system to be around at runtime to inject the services they need.
- Can we come up with a common syntax where a bundle can specify its service and extension registry imports/exports, and be agnostic about the runtime that will parse it and provide the runtime capabilities.
- Scoping: extension registry / services are global - how can I publish extensions/services that are only available in a particular scope* only particular set of bundles have access to it. In J2EE world, sometimes only want to register/bind services within a particular web app. Scoped registries - local versus global extension registry.
p2 Design Deep Dive
Interesting topics:
- Profiles/ hierarchy of profiles
- Headless agent; managed installs
- Everything is possible
- Version range lineups,
- Security? JAAS
- Resolver - where does it go? when?
- Plugable download manager
- Plugable communications - within ECF. replacing ECF?
Tooling (builds)
- Enhancements to current export
- pack/unpack/sign support
- export to multiple targets (exporting platform dependent fragments)
- Current Export
- leave behind generated files for debugging purposes
- Project Builder (can we get this into the pde.incubator)
- a new builder project (like existing update site project)
- Provides a mechanism to bootstrap from export to headless build
- generates artifacts (features/build.properties/customTargets.xml/allElements.xml) that are input into pde.build
- provides forms/editors (or wizards) to expose pde.build options
- Consider different inputs : .product file, launch configuration
- enable gradual discovery of customizability: customTargets.xml, plugin level build callbacks.
- Synchronization between workspace and plugin level build properties.
- PDE/Build proper: selected refactorings to make project builder easier
- remove need for allElements.xml
Server Side Web apps++
Second breakout meeting
API Tooling
- Clarify definition of API (what is API, what is API compatibility)
- Public API (as defined by Jeem's API white paper)
- Internal code
- Provisional API
- SPI - Service provider interfaces
- Eclipse-specific API such as extension point ids, other data in extension/extension-point markup
- Tool to annotate code with API rules (javadoc tags that specify if a class may be implemented, instantiated, etc)
- Build API rule file from javadoc tags
- Want both IDE integration, and headless build usage
- Scalability
- Be able to run API tools on smaller components/bundles/pieces rather than the whole world
- Store results in various forms: XML files, or perhaps database for large scale use
- API data may be stored locally or remotely
- Discussion on whether API rule files could replace JDT access restrictions. It's really a super-set of access rules, can express things that acess rules cannot
- API usage reports: could have simple HTML pages, or Eclipse integration into views/editors, like the Emma Eclipse plugin does for coverage data
- Support for API tooling in other languages and .so/DLL files
- Use of reflection is problematic because it's hard to detect programmaticaly