GlassFish - World's first Java EE 7 Application Server


Integration of GlassFish Servers and NetBeans 7.0

Background

NetBeans currently supports Java EE 5 development against GF V2 and V3 Prelude. 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).

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 are a couple types of parity:

  • feature parity
    the user is able to achieve the same effect on the server or application.
  • UI parity
    the user is able to follow the same 'recipe' to achieve the same effect on the server or application.

There are many places where the v3 plugin in 6.5 provides partial feature parity with the v2 plugin 6.5. There are a number of places where that feature parity needs to be extended to fill in gaps in functionality. UI parity between the v3 plugin(s) and the v2 plugin is not a goal. This is a good time to examine the feature set and UI of the plugin to address issues that have been difficult to address in the v2 plugin code.

There is more code that may need to be refactored to support feature parity between the v2 plugin feature set and the v3 plugin feature set. 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 or the v3 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 should be finished by the time NetBeans 7.0 is ready to ship. 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.

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 should have feature parity with V2 plugin in the 7.0 time frame.
    Development efforts should concentrate on the features that an early adopter of V3 would benefit from the most.
  • The IDE is the developer level UI for the servers
    a developer should not need to open the Admin console for the server to accomplish common development tasks.
  • The IDE is not the admin level UI of the servers
    Duplicating features from the Admin console is not a high priority, unless those features are part of a high priority area.

Vision

In the 7.0 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...

The dev modules will need to support Java EE 6.

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 7.0 must include these features

  • Leverage v3 container features
  • support for ejb module project deployment (if supported by v3)
    • directory based
  • support for app client project deployment (if supported by v3)
    • archive based?
  • support for ear project deployment (if supported by v3)
    • directory based
  • v3 dd support – xml only – if there is any difference between v2 and v3 dtds
  • JDBC driver deployment
  • resource registration
    • completion
  • http monitor support

Supporting Features

These are features that need to be in NB 7.0, 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 7.0 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

Signposts

this is a section of random notes at the moment. In this section we need to call out 'lessons learned' that may affect the coding decisions for the plugins for 7.0.

  1. come up with a strategy for avoiding version confusion in the ui.
    the current strategy has weaknesses. the strategy used by the tomcat plugin appears to be better, but we need to allocate time to investigate this and find a solution that will scale. We may want to think about extending the Add Server dialog to allow the user to see info about the plugin, that would help eliminate the confusion.
  2. find a better strategy for the target of the download now button...
    currently the file that is downloaded comes from a file nb.org. The actual file that will be downloaded is never exposed to the user... so the whole process is kind of a black art.. and fairly brittle.
  3. Need to improved deploy-on-save feature to mesh with server-side improvements better. This is especially true for v3.

Task List