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