Tim,
I agree with you.
AMX does separate itself into two modules--'amx-api' (very small) and
amx-impl. Other areas require vigilance as we develop things. But I
think we'll have to organize and reorganize as this project evolves,
so hopefully we can avoid any problems by fixing them as they crop up.
Lloyd
On Feb 14, 2008, at 3:35 PM, Tim Quinn wrote:
> I would also ask that people be very cautious about putting classes
> into modules called "common" or "core" unless it is extremely clear
> that just about every piece of GlassFish will need it.
>
> I am waging an ongoing effort - and trying to enlist everyone's
> help - to keep the size of the ACC as low as possible. As more and
> more items appear in core or common modules it is more and more
> likely that the ACC will have to bring along what is unneeded (for
> it) baggage to get things it does need.
>
> We should be similarly vigilant to keep the size minimal for
> deployment clients.
>
> I don't know how big AMX is or will be, but it's a good example of
> something that's clearly needed on the server side and not needed
> at all in the ACC.
> Of course I'm talking about actual modules that lead to JAR files,
> not necessarily the directory structure that organizes things into
> a hierarchy of submodules (such as core/kernel).
> - Tim
>
> Lloyd Chambers wrote:
>> Yes, I agree it's hard.
>>
>> I don't know why (for example), amx is in 'common', except that
>> the AMX interfaces need to be in some base-level module so that
>> everything else can get at them. But AMX implementation location
>> is less clear.
>>
>> Lloyd
>>
>> On Feb 14, 2008, at 2:36 PM, Jerome Dochez wrote:
>>
>>> I would love to put rules in place but I am not sure how this can
>>> be specified, there is a fair amount of reshuffling that has to
>>> go on until we find the right mix and I really don't know how to
>>> pre-specify the exact set. I will come up with the list of
>>> modules and how I feel the dependencies should be in place so we
>>> don't end up with a huge spaghetti sauce but the process of
>>> finding out where things go in pretty much one of the hardest V3
>>> task for all engineers.
>>>
>>> jerome
>>>
>>> On Feb 14, 2008, at 12:38 PM, Lloyd Chambers wrote:
>>>
>>>> We need some rules in place about dependencies.
>>>>
>>>> For example, we can have org.glassfish.admin depend on
>>>> org.glassfish.common (including submodules). Or we can have the
>>>> reverse. But we can't have both, which is why I'm blocked today.
>>>>
>>>> This problem is going to be a major headache going forward
>>>> unless we agree what goes where. I'm not at all clear on which
>>>> code should go where.
>>>>
>>>> Lloyd
>>>>
>>>> On Feb 14, 2008, at 10:44 AM, Lloyd L Chambers wrote:
>>>>
>>>>> Seems like I should have a module for the "AMX framework",
>>>>> including the annotations like @AMXInfo, the AMXRegistrar,
>>>>> etc. I need to be careful--the general support should not
>>>>> depend on any GlassFish config anything, since AMX has to
>>>>> support config, runtime, etc.
>>>>>
>>>>> Lloyd
>>>>>
>>>>> On Feb 14, 2008, at 10:37 AM, Jerome Dochez wrote:
>>>>>
>>>>>> yep we probably need to split this into two modules, let me
>>>>>> look at it after the engineering meeting.
>>>>>>
>>>>>> jerome
>>>>>>
>>>>>> On Feb 14, 2008, at 10:24 AM, Lloyd L Chambers wrote:
>>>>>>
>>>>>>> I think we need to refactor:
>>>>>>>
>>>>>>> - config-api mixes two distinct things: generic Glassfish V3
>>>>>>> *framework* support for config eg GlassFishConfigBean
>>>>>>> - specific interfaces for config eg the 'serverbeans'
>>>>>>> interfaces for elements in domain.xml
>>>>>>>
>>>>>>> That structure is a mistake. It has forced me (see below) to
>>>>>>> make config-api depend on amx-impl (so that that the server
>>>>>>> beans code can use @AMXInfo). But that's not right at all
>>>>>>> for the framework code, upon which amx-impl depends or will
>>>>>>> depend. And the AMXInfo is general, not restricted to config.
>>>>>>>
>>>>>>> I'm not sure how to refactor this, but I am STUCK until we
>>>>>>> refactor something.
>>>>>>>
>>>>>>> Lloyd
>>>>>>>
>>>>>>>
>>>>>>> On Feb 14, 2008, at 9:47 AM, Lloyd L Chambers wrote:
>>>>>>>
>>>>>>>> Jerome,
>>>>>>>>
>>>>>>>> I updated this morning, and I'm seeing this cyclic dependency:
>>>>>>>>
>>>>>>>> [INFO] The projects in the reactor contain a cyclic
>>>>>>>> reference: Edge between 'Vertex
>>>>>>>> {label='org.glassfish.admin:config-api'}' and 'Vertex
>>>>>>>> {label='org.glassfish.common:amx-impl'}' introduces to cycle
>>>>>>>> in the graph org.glassfish.common:amx-impl -->
>>>>>>>> org.glassfish.common:common-util -->
>>>>>>>> org.glassfish.common:glassfish-api -->
>>>>>>>> org.glassfish.admin:config-api --> org.glassfish.common:amx-
>>>>>>>> impl
>>>>>>>>
>>>>>>>> I'm not sure what is changed, but I had put a dependency
>>>>>>>> from config-api on amx-impl because the
>>>>>>>> com.sun.enterprise.config.serverbeans interfaces (like
>>>>>>>> Domain.java and HttpListener.java) must be annoted with
>>>>>>>> @AMXInfo.
>>>>>>>>
>>>>>>>> The problem seems to be that glassfish-api depends on config-
>>>>>>>> api, which is completely wrong IMO, at least when the
>>>>>>>> serverbeans stuff is included there.
>>>>>>>>
>>>>>>>>
>>>>>>>> ---
>>>>>>>> Lloyd L Chambers
>>>>>>>> lloyd.chambers_at_sun.com
>>>>>>>> Sun Microsystems, Inc
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> ------
>>>>>>>> To unsubscribe, e-mail: admin-
>>>>>>>> unsubscribe_at_glassfish.dev.java.net
>>>>>>>> For additional commands, e-mail: admin-
>>>>>>>> help_at_glassfish.dev.java.net
>>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> Lloyd L Chambers
>>>>>>> lloyd.chambers_at_sun.com
>>>>>>> Sun Microsystems, Inc
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---
>>>>> Lloyd L Chambers
>>>>> lloyd.chambers_at_sun.com
>>>>> Sun Microsystems, Inc
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc