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
>