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 ?
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
>