AMX follows this model: amx-api and amx-impl. It works very well IMO
\, and is easily understood, with clear ownership.
On May 16, 2008, at 7:18 AM, Sahoo wrote:
> Having a module internal-ee-api which hosts all kinds of APIs from
> different containers is a bad idea, as there is no clear owner of
> that module. Hence, I suggested hosting connector apis in connector
> module. If you don't want the implementation module to be loaded
> eagerly, then you can have two modules under connector: connector-
> api and connector-impl.
>
> Thanks,
> Sahoo
>
> Jagadish Prasath Ramu wrote:
>> I am trying to move these api classes to internal-ee-api as these are
>> meant to be used by other containers/modules like transaction, ejb,
>> naming, jpa etc. These apis need to be in a separate module (other
>> than
>> connector-runtime implementation) so as to :
>> 1) avoid loading the implementation module during appserver startup /
>> startup of a module that depends on the api.
>> 2) avoid any cyclic dependency issue.
>>
>> Thanks,
>> -jagadish
>>
>>
>> On Thu, 2008-05-15 at 11:10 -0700, Jerome Dochez wrote:
>>
>>> On May 15, 2008, at 11:06 AM, Sahoo wrote:
>>>
>>>
>>>> Why are APIs that are exposed by connector-runtime not part of
>>>> connector module?
>>>>
>>> right we should only move these APIs to an API module if we
>>> expect different implementations (so we avoid repackaging them
>>> each time) or plugability (feature may or may not be present, we
>>> still need the interfaces even if the feature is absent).
>>>
>>> Jerome
>>>
>>>
>>>> BTW, why is this discussion not happening on dev alias?
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>> Marina Vatkina wrote:
>>>>
>>>>> CC-ing Sahoo.
>>>>>
>>>>> -marina
>>>>>
>>>>> Jagadish Prasath Ramu wrote:
>>>>>
>>>>>> Hi,
>>>>>> Based on the conventions for api's in GlassFIsh (attached mail
>>>>>> from
>>>>>> Jerome to dev_at_GF), I am planning to move the connector-runtime
>>>>>> module
>>>>>> exposed api from glassfish-ee-api to internal-ee-api.
>>>>>>
>>>>>> As of today, if a module is referring to glassfish-ee-api, it
>>>>>> is only
>>>>>> due to connector-runtime dependency. So, changing the
>>>>>> dependency from
>>>>>> glassfish-ee-api to internal-ee-api should be fine.
>>>>>>
>>>>>> I am planning to move these files early next week, I shall
>>>>>> take care of
>>>>>> updating all the necessary modules' dependencies.
>>>>>>
>>>>>> Please let me know if you have any queries by this week.
>>>>>>
>>>>>> I will be making necessary changes for the following modules.
>>>>>>
>>>>>> jpa-connector
>>>>>> amx-impl
>>>>>> container-common
>>>>>> javaee-core
>>>>>> jta
>>>>>> ejb-container
>>>>>> realm
>>>>>>
>>>>>> Thanks,
>>>>>> -Jagadish
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> Subject:
>>>>>> Shared modules
>>>>>> From:
>>>>>> Jerome Dochez <Jerome.Dochez_at_Sun.COM>
>>>>>> Date:
>>>>>> Fri, 07 Mar 2008 16:59:41 -0800
>>>>>> To:
>>>>>> dev_at_glassfish.dev.java.net
>>>>>>
>>>>>>
>>>>>> 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
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc