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