Sahoo wrote:
> 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?
so far we cannot. the issues is not limited to common-ee-util. for
instance, look at management-api in the Java EE APis. it imports ejb-api
which imports jaxrpc-apis. Of course we would want management-api in a
web distribution. The Java EE APIs have not gone through a rigourous
effort to allow for on demand pick and choose.
>
> 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.
sure, we can review the nomenclature once the SPIS/APIs stabilizes.
>
> 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.
we will have to assert the runtime cost of doing this, I don't want to
see a module proliferation and we certainly must ensure that the APIs
jar we deliver can work as a standard Java SE jar file.
>
> 4. Is glassfish-ee-api going to contain the management interfaces as
> well?
it's unclear at this point but in theory yes it should.
>
> 5. Why is there a single module called glassfish-ee-api?
I don't understand that question, can u elaborate.
thanks, Jerome
>
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>