Integration of GlassFish Servers and NetBeans 6.5
Background NetBeans currently supports Java EE 5 development against GF V2. That support will be maintained. There are no enhancements planned for the v2 plugin. GF V3 will support Java EE 6. The changes to app development between Java EE 5 and Java EE 6 will be as big or even bigger than the changes between J2EE 1.4 and Java EE 5, for developers (and development tool makers). According to the current plan, many of the changes necessary to fully support Java EE 6 development will not be implemented in the NetBeans 6.5 time frame. Users will expect feature parity between the V2 integration and the V3 integration. That parity is reasonable to expect when v3 has entered beta (see the schedule). There is a large amount of code that may need to be refactored to support feature parity between the V2 plugin feature set and the v3 plugin feature set. Some of that refactoring will need to take place in the 6.5 time frame. This refactoring effort will need to be supported by extensive testing. Large portions of the test suite necessary to support the refactoring will need to be automated as unit and/or qa-functional tests, to prevent large numbers of undetected regressions from making it into the v2 plugin. Some enhancements and features may become part of the v2 plugin, as a side effect of the improvements to the user experience of a feature between the V2/6.1 HCI and the V3/6.5 HCI. V3 and Java EE 6 will be far from finished by the time NetBeans 6.5 is ready to ship, so the "plan" for this team should be to find and focus on developer productivity wins that do not require huge amounts of changes in the IDE. We will need to be active in reviewing the plans of the larger Java EE team regarding how they intend to evolve the current Java EE 5 support into Java EE 6 support. The current TP2 release of the V3 support has some significant architectural changes compared to the V2 plugin. Many of these changes are significant improvements. We need to evaluate changes in the integration plugin and the server to make sure that we do not sacrifice these improvements for the sake of completing the prototype of a feature. Stakeholders
- Java EE Modules
- Friends of the V2 plugin
- Dynamic Language Modules
Users
- Java EE 5 developers
Want to see quality improvement in the server integration. If an IDE feature needs support from the plugin, that will have to happen. It may need to be staffed by folks outside the integration plugin team.
- Java EE 6 early adopters
Want to be able to experiment with Java EE 6 in the IDE. May not expect "support". Will not accept "blockers".
- Dynamic Language developers that are experimenting with GF V3
need list of languages that will be supported by v3 AND 6.5.
Risks
- refactoring causing a v2 plugin regression.
- urgent interrupts on development team's time.
- poorly designed features integrated because they were easy or flashy.
- poorly communicated expectations from other teams in the NB org.
- dependence on v3 features that end up not getting implemented in the 6.5 time frame.
Assumptions
- V2 plugin must maintain a fairly high quality level.
- V3 plugin does not need to have feature parity with V2 plugin in the 6.5 time frame.
Development efforts should concentrate on the features that an early adopter of V3 would benefit from the most.
- V3 plugin is not expected to be FCS quality.
It should not be riddled with bugs though.
Vision In the 6.5 time frame we want to create an environment that allows users to leverage the features of V3 that will be "ready". The Java EE 6 features are supposed to be ready. The ability to support dynamic languages is going to be "ready". The support for the module system in v3 will be more baked... We will need to extend the dev modules to support Java EE 6 development. We also need to make sure that users targeting Java EE 5 and V2 have a stable environment to use for their continuing production development effort. We need to fix high priority issue in the v2 plugin where possible. The V2 plugin will not get enhanced for the sake of enhancing the v2 plugin. Features Defining Features NB 6.5 must include these features
- Leverage v3 container features
- support for ejb module project deployment (if supported by v3)
- support for app client project deployment (if supported by v3)
- support for ear project deployment (if supported by v3)
- v3 dd support – xml only – if there is any difference between v2 and v3 dtds
- JDBC driver deployment
- resource registration
- http monitor support
Supporting Features These are features that need to be in NB 6.5, that belongs outside the V2 and V3 plugin code...
- extend j2eeserver's plugins api to allow for richer server descriptions...
- finer grained than J2EE_14 constants and the like
- extend j2eeserver devmodules api to allow dev modules to describe the features they require to deploy/run successfully.
- a project may need a component/API from the Java EE spec... not dependence on the spec.
Target Features NB 6.5 would be a better product if these features were available.
- EJB wizard in Web project
- Call EJB support for web packaged EJBs inside the web project...
- extend web app with an action that can create an ejb jar file for the embedded ejbs
- Wizard/action to create a v3 module from a regular java project
Non features These features will not be considered for implementation in the NB 6.5 time frame.
- new Java EE 6 dd support (unless absolutely necessary)
- multiple registration types for v3 domains.
the user can register the local default domain.
|
