* A short issue description outlining what the issue is and why it is being done.
The GlassFish Common module provides GlassFish V3 Server registration and management services to platform/runtime
specific server integration modules to facilitate sharing of code and server instances between disparate runtimes.
GlassFish V3 Server support is being added to the NetBeans 6.5 distribution, hence this module is being migrated from
contrib to main and needs to be added to the build in a proper location.
* Target milestone
* Dependencies on other issues and issues that depend on this one
* An explanation of the change in architecture or API.
The GlassFish V3 server plugin provides server integration support for Web Projects and Ruby on Rails Projects. It is
split into 3 modules:
1. glassfish.jruby in Ruby cluster, to support Rails
2. glassfish.javaee in Web/JavaEE cluster to support Web (and Ejb/Ear when ready on server)
3. glassfish.common which handles server registration, UI, and provides management services for (1) and (2).
(3) exposes a friend api/spi implemented and used by (1) and (2). It is intended that this api/spi is only to be used
by platform/runtime specific V3 server integration modules such as these.
As such, glassfish.common module must reside in a cluster accessible to both the NetBeans Ruby distribution and the
NetBeans JavaEE distribution. IDE cluster is the current best candidate satisfying these goals. This solution was also
recommended by Jesse Glick (See http://www.nabble.com/module---cluster-question...-td17763383.html ).
* A list of the interfaces impacted by the change that the module offers (imports) and depends on (exports).
Javadoc for glassfish.common's friend API/SPI is not hosted externally (but can be built from the module sources in
main). I will fix this soon(after Jun 18, as I'm on vacation until then). Note this javadoc is not 100% complete at
* The specification (e.g. javadoc) and stability category (aka commitment level) for each interface.
The API/SPI exposed by glassfish.common is "friend" and is also still "under development".
* If there is an existing document with answers for Architecture Questions and the issue makes only a partial change
to the architecture the architecture document needs to be updated to cover the proposed change in order to qualify for
the fast-track review.
I have not answered the architecture document questions yet. If necessary, I will write that up also after June 18 and
amend this request accordingly.
I agree this approach makes sense. The glassfish.common module normally adds some UI to the Services tab when it is
enabled, but since it will be disabled in the Java SE distribution (as it's autoload and no other module will need it),
no undesirable UI will appear.
I checked in the change to put glassfish.common into the IDE cluster as part of 6.5 M1.
Reopen this issue if it really must be rolled-back.