A few comments:
1. Since common-ee-util depends on Java EE APIs, how can we have a
distribution of just the web container or the ejb container without
distributing ejb-apis or servlet-apis respectively?
2. There appears to be no distinction between SPIs and APIs. Some
interfaces of glassfish-api are more fit to be called as SPIs. The same
may hold good for internal-api as well.
3. Having a single module called javaee.jar for all the Java EE APIs is
fine, but we also need smaller modules for each container.
4. Is glassfish-ee-api going to contain the management interfaces as well?
5. Why is there a single module called glassfish-ee-api?
Thanks,
Sahoo
Jerome Dochez wrote:
> Hi All
>
> Some have raised questions on how to package shared or public APIs in
> GlassFish V3. although there are no miracle recipe, there are a few
> modules that can be considered when packaging shared or public
> (including semi-public) classes.
> + common-util
>
> You should use this module when you need to package classes that do
> not depend on anything but JDK classes and that can be useful to other
> modules. Things like logging, common io routines and utility classes
> are a good fit for this module
>
> + common-ee-util
>
> This is a package for utility classes that are meant to be shared by
> Java EE containers, this module imports the Java EE APIs and can
> container common services like injection utilities, common security
> code etc.
>
> + internal-api
>
> these are semi public APIs of glassfish, meaning interfaces and
> contracts we used to implement GlassFish but are not meant to be the
> official extension point for external tools and plugins or extra
> containers. It's a free world so people can use it at their own risk
> but you don't have to provide backward compatibility to classes
> packaged in this module. Those internal APIs are meant to be
> integration points between the different part of the application, yet
> not part of the public extensibility APIs.
>
> + internal-ee-api
>
> same as internal-api but using depending on the Java EE APis. this
> module is empty for now, I will start moving some classes there soon.
>
> + glassfish-api
>
> These are the official blessed extensibility APIs internal/external
> folks can use to extend GlassFish, it contains contracts definition
> like Startup, AdminCommand and other hooks for container providers.
> None of these APIs are Java EE dependent as these APIs ship in nucleus
> which is the smallest glassfish distribution with no Java EE
> dependencies.
>
> + glassfish-ee-api
>
> Same as above but dependent on the JavaEE API, gives access to things
> like the InjectionManager, NamingManager for Java EE derived container
> access to GlassFish services.
>
> Let me know if you have any questions/issues.
>
> Thanks, Jerome
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>