On Jan 31, 2008, at 7:51 PM, Jerome Dochez wrote:
>
> On Jan 31, 2008, at 6:31 PM, Ken Cavanaugh wrote:
>
>> Jerome,
>>
>> I'm looking into some issues around how to re-organize the CORBA
>> build to
>> fit the GFv3 model. Most of this is not too hard, because most of
>> the correct structure is
>> already in place. Harsha and I just need to do some work to
>> integrate with
>> the maven repository.
>>
>> I have a couple of questions:
>>
>> Should we use the Maven repository to handle build time
>> dependencies as well as runtime ones?
>> CORBA has the following dependencies:
>
> only runtime dependencies need be resolve through the maven
> repository. You compile with any tool you wish to and there is no
> need to use maven or maven repository for compile time dependencies.
I was just wondering if we might wish to put commonly used tools in
the repository so that we could easily use
the same versions, and remove the binaries from mercurial repositories.
>
>>
>>
>> Build-time only:
>> ant (which must be installed locally to get started)
>> emma runtime and ant task
>> findbugs
>> Jscheme
>> maven ant tasks for accessing the repository (that will probably
>> need to be local as well)
>> Testing only:
>> Japex
>> Junit
>> TestNG
>> ejb-2_1-api.jar
>> Runtime:
>> ASM (from ObjectWeb; the ORB currently uses version 2.0, other
>> versions may be in use elsewhere in GlassFish).
> we already have these versions in the distribution (final glassfish
> package) :
> -rw-r--r-- 1 dochez staff 34832 Jan 31 16:55 asm-2.2.3.jar
> -rw-r--r-- 1 dochez staff 17639 Jan 31 16:55 asm-
> analysis-3.0.jar
> -rw-r--r-- 1 dochez staff 25542 Jan 31 16:55 asm-commons-3.0.jar
> -rw-r--r-- 1 dochez staff 21512 Jan 31 16:55 asm-tree-3.0.jar
> -rw-r--r-- 1 dochez staff 32051 Jan 31 16:55 asm-util-3.0.jar
>
> are they good enough ?
Probably. I'll test with that version at some point and make sure
(I'm using 2.0 right now).
>> Grizzly (once we finish final reviews and commits on the CORBA on
>> Grizzly work)
> 1.7.0 ok ?
Probably, but everyone on the CORBA team is also on the Grizzly team, so
this is very closely tracked.
>
>> Of the above packages, only Grizzly is currently available in the
>> maven repository, assuming that http://download.java.net/maven/2/
>> is the correct URL for the repository.
>>
>> The glassfish-corba project will also produce two modules:
>> ORB library (including codegen, which is used for local EJB code
>> generation even when no ORB is needed)
>> ORB runtime (required for JTA and remote EJB support)
>> How do I generate an appropriate jar manifest for an HK2 module
>> without using maven?
>> Is this documented somewhere?
>
> well we are in the process of changing some of those manifest
> entries so it's a bit in disarray right now.
> Sahoo, could you help Ken with how to create the manifest entries
> with ant.
OK, that would be helpful.
>>
>> In general, a lot of the hk2 discussion assumes that a module is
>> built using Maven 2.
>> This may not be true of all modules. CORBA in particular has a
>> complex build with multiple
>> code generators that generate java code. While it is probably
>> possible to re-cast the
>> CORBA build into the Maven form, it would be a significant effort,
>> and I'm not sure it's
>> worthwhile. I also MUST be able to build the ORB from the same
>> source for OpenJDK,
>> which supports ant, but not maven.
>>
> right, I don't think you should try to use maven to build, so all
> you need is to publish the jar files with the right manifest
> entries in a maven repository, How those jar are build is immaterial.
>
> Another way of solving this is to define an ORB module in glassfish
> that would import your jar files as pure libraries and make them
> look like a single module to the HK2 world. We do that for Grizzly
> for instance.
Yes, I am considering that, especially since the exact means of
configuring and initializing the ORB for GlassFish
is GlassFish specific. There is a lot of interceptor code that is
registered with the ORB through the ORBManager,
and this code stays in GlassFish.
Delivering the ORB as pure libraries probably makes the most sense.
>
>> I don't think these questions are answered by the https://
>> hk2.dev.java.net/modules.html document.
>> Is there another more comprehensive document I should consult?
>> Or perhaps it's time to read the hk2 source code?
>>
> hopefully not, you should either ask me or ask Sahoo who is taking
> care of the Hk2 module management.
>
>>
OK, thanks.
Ken.