ok so after this shuffling happened, we now have too many corba
related modules in web distribution :
I can see these two new ones :
-rw-r--r-- 1 dochez staff 345264 Oct 21 13:22 glassfish-corba-
asm.jar
-rw-r--r-- 1 dochez staff 332683 Oct 21 13:22 glassfish-corba-
codegen.jar
why do we need this in the web distribution, Ken is it really
necessary to have omgapi in web distribution ?
-rw-r--r-- 1 dochez staff 306621 Oct 21 13:22 glassfish-corba-
omgapi.jar
thanks, jerome
On Oct 21, 2009, at 12:33 PM, Snjezana Sevo-Zenzerovic wrote:
> There is also packager aspect of this. I just moved glassfish-
> codegen packager module from full into web distribution as quick and
> dirty fix to satisfy this new dependency but we may need to
> reconsider the way we currently package glassfish-corba-* modules,
> especially if we try to reduce number of modules.
>
> This is the way we currently package glassfish-corba-* content,
> based on Ken's original recommendations:
>
> glassfish-corba-omgapi package contains glassfish-corba-omgapi -
> this used to be the only package requried by web distribution.
>
> glassfish-codegen contains glassfish-corba-codegen, glassfish-corba-
> asm and glassfish-corba-orbgeneric.
>
> glassfish-corba contains glassfish-corba-newtimer, glassfish-corba-
> orb and glassfish-corba-csiv2-idl
>
> Ken, since you say that glassfish-corba-orbgeneric does not have any
> dependencies other than gmbal, would it make sense to move it into
> glassfish-corba-omgapi package module and keep that the only package
> required in web distribution? One thing that we generally tried to
> do is to keep clean distribution boundaries, so web distribution
> should not contain anything that is not really required.
>
> Thanks,
>
> Snjezana
>
> Ken Cavanaugh wrote:
>> Jerome Dochez wrote:
>>> Mahesh Kannan wrote:
>>>> Sahoo wrote:
>>>>> Mahesh, dependencyManagement
>>>>>
>>>>> Please use dependencyManagement in v3/pom.xml to specify the
>>>>> versions of various corba artifacts and remove any such external
>>>>> version from orb/*/pom.xml and send it for review.
>>>> I have already checked in the changes since I got the approval
>>>> from Jerome.
>>>> However, I will make the suggested changes and send it for review
>>>> tomorrow.
>>>>
>>>>>
>>>>> I am not sure about orb-connector exporting threadpool manager
>>>>> and IIOPUtils. That is not what a connector module is supposed
>>>>> to be used for.
>>>>
>>>> Ken / Jerome: Should we create a new module for these two classes?
>>> I just checked the modules directory, we already have 7 glassfish-
>>> orb-xxx bundles and we have another 3 orb-xxx bundles so I would
>>> rather avoid creating yet another one. What are the dependencies
>>> of glassfish-corba-orbgeneric module ?
>> glassfish-corba-orbgeneric depends only on gmbal (and eventually
>> management-api), because the
>> threadpool needs to expose some monitoring information. orbgeneric
>> does not depend on any
>> glassfish-corba-* or orb-* bundles.
>>
>> We could probably reduce the number of glassfish-corba-* bundles if
>> desired, roughly as follows
>> (I'm omitting the glassfish-corba to save typing):
>>
>> * asm could be replaced by the copy of ASM 3.x that is used
>> elsewhere in GFv3
>> * csiv2 and and omgapi could be combined, but note that the
>> transactions code needs omgapi but not csiv2 even in the web
>> container (csiv2 is only about 115K)
>> * newtimer (51K), codegen (333K), and orbgeneric (145K) could be
>> combined, but note that codegen is needed by the EJB container
>> even when the ORB is not used, and orbgeneric (because of the
>> threadpool) is needed in the webcontainer.
>> * We could reduce to a orbutil bundle (around 530K), an api bundle
>> (around 420K), and the orb bundle (1925K) at the cost of
>> somewhat increasing the footprint of the EJB without ORB and web
>> only scenarious.
>>
>> I'm not sure if we could reduce the orb-* bundles. Perhaps this
>> could be moved from 3 to 2, but I don't think we could
>> get to 1 bundle there.
>>
>> Ken.
>>
>> --------------------------------------------------------------------- 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
>