Jerome Dochez wrote:
> Kedar Mhaswade wrote:
>>
>>
>> Jerome Dochez wrote:
>>> Sreenivas Munnangi wrote:
>>>> Bill Shannon wrote:
>>>>> Sreenivas Munnangi wrote:
>>>>>> Hi,
>>>>>>
>>>>>> The issue of workspace, specifically organizing admin source code
>>>>>> corresponding to v3 modularization has been discussed among admin
>>>>>> team members and arrived at the final structure. Following link
>>>>>> provides details.
>>>>>>
>>>>>> http://wiki.glassfish.java.net/Wiki.jsp?page=V3AdminWorkspaceStructure
>>>>>>
>>>>>>
>>>>>> Pl. let us know if you have any suggestions.
>>>>>
>>>>> Is each module in your list a separate HK2 module?
>>>>> Or do the submodules correspond to HK2 modules?
>>>> In the following, admin is a HK2 module with pacakages
>>>> org.glassfish.web.admin.cli, org.glassfish.web.admin.amx,
>>>> org.glassfish.web.admin.amx.impl, etc.
>>> I think you meant admin-web is an HK2 module... we need to have
>>> different names for admin module per container...
>>
>> Sorry for the confusion, but I am still not sure if admin code in
>> every container needs to be an HK2 module on its own. I don't think it
>> satisfies
>> the criteria for Module definition:
>> http://wiki.glassfish.java.net/Wiki.jsp?page=V3EngineersGuide#section-V3EngineersGuide-1.1WhatIsAModule
>>
>>
>> Given that, is it logical to make admin part of every container (or other
>> module) an HK2 module?
>>
>> For example, I don't think the admin classes/interfaces for the
>> web-tier would
>> go in its separate jar file like webtier-admin.jar. A more logical
>> place for
>> them is webtier.jar itself. That's why I was leaning more towards not
>> making the
>> admin code for a container/module a separate module.
>>
> good point...
>
> Some these interfaces might actually rely on features not present in a
> particular distributions, like AMX or most likely the GUI so as you
> mention, mandatory admin interfaces of a module like the CLI and monitor
> could be in the webtier.jar to follow your example. The other ones might
> be in an admin-optional module. I don't think we need to necessary
> resolve this today as we are not sure what is mandatory/optional yet.
>
> my suggestion about using a different module was to stick more with
> areas of responsibilities with different development teams working on a
> single module like webtier. This might be easier organizationally.
>
> what do you think ?
I was under the impression that a particular module's admin part would
contain any number of admin interfaces out of: CLI, AMX, GUI, Monitor.
A (sort of) mandatory admin part of every module is "Config" or the config
beans that all are familiar with. An example of such a bean is
VirtualServer.java that defines the configuration of a virtual server. Thus,
webtier.jar will always contain
com.sun.enterprise.config.serverbeans.VirtualServer and the like.
For the GF webtier, I also assumed that we will be bundling all these interfaces
with the module itself. Thus, webtier.jar will contain all the necessary webtier
runtime functionality + its config, commands, GUI, AMX interfaces, monitoring
interfaces.
An independently developed module that leverages V3 and HK2 may or
may not have all the above admin interfaces provided with its jar. It may
choose to provide only commands, for instance. But for
webtier (and all the other modules like ejb-container, jdbc-ra, jms-ra,
jpa implementation ... that form V3 product) we would define, implement and
bundle all the above admin interfaces as mandatory ones.
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.
With these assumptions, I think making admin interfaces of webtier a part
of webtier module is probably the way to go.
>
> Jerome
>>>>
>>>> /v3
>>>> /v3/web
>>>> /v3/web/<core modules>
>>>> /v3/web/admin
>>>> /v3/web/admin/src/main/java/org/glassfish/web/admin/cli
>>>> /v3/web/admin/src/main/java/org/glassfish/web/admin/amx
>>>> /v3/web/admin/src/main/java/org/glassfish/web/admin/amx/impl
>>>> /v3/web/admin/src/main/java/org/glassfish/web/admin/monitor
>>>> /v3/web/admin/src/main/java/org/glassfish/web/admin/plugin/impl
>>>> /v3/web/admin/src/main/java/org/glassfish/web/admin/common
>>>>>
>>>>> How do the modules relate to Maven projects? Which
>>>>> modules are sub-projects and what is the parent project?
>>>> For distribution/packaging purposes, web is the parent project with
>>>> admin being the sub-project. So whenever web is built, admin is also
>>>> built as part of it.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>