Kedar Mhaswade wrote:
> Sahoo,
>
> Sahoo wrote:
>> Jerome Dochez wrote:
>>>
>>>> From a size/embeddability considerations, if any of the above
>>>> interfaces is
>>>> deemed "unnecessary", then probably a "distribution" emerges at
>>>> that point
>>>> which excludes the artifacts of that particular interface. For
>>>> example, we
>>>> might want to build a webtier-light distribution that does not
>>>> contain the
>>>> GUI/AMX interfaces.
>>> right so would not that call for separating those at the module level ?
>> I don't understand how separating the admin functionality of webtier
>> to a single module like webtier-admin solves the aforementioned
>> distribution problem. We would still distribute the same number of
>> bytes, because the module contains both required and optional webtier
>> admin functionality. Or, are we talking about the required part of
>> webtier-admin to be part of webtier.jar where as the optional part
>> being made available as one or more separate modules?
>
> As of now, at least for webtier, I feel all admin artifacts should be
> made a part of webtier.jar alone. In general, I am not sure if different
> admin interfaces/classes are general enough to be made into separate
> HK2 modules (this is based on Module definition outlined by
> http://wiki.glassfish.java.net/Wiki.jsp?page=V3EngineersGuide
>
> So, in short, core admin facilities is one HK2 module and webtier
> admin facilities are part of webtier module itself.
>
> Am I creating more confusion?
>
But you only mentioned about the possibility of a webtier-light
distribution and not shipping some of the webtier admin artifacts as
part of that distribution, didn't you? Can we support such a
distribution with this kind of packaging? I hope we are *not* proposing
to have different number of classes in the same module (same as in name
and version being same) in different distributions. Different
distributions for same version of GlassFish should differ only by number
of modules, the same module in different distributions should have same
content, otherwise it will be difficult to add new features to an
installed system.
Having said this, if we conclude that the admin functionality for a
container can *not* be separated into required and optional modules,
then your proposal of packaging admin classes as part of webtier.jar is
almost as good as separating them into another module like
webtier-admin.jar. I said almost because a separate module would
theoritically allow us to upgrade only that module in an installed
system, but I don't know how practical that is from a release
engineering point of view. In that case, I prefer having just one module.
Thanks,
Sahoo