Hi Ken,
On Jan 31, 2008, at 9:01 PM, Ken Cavanaugh wrote:
>
> 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.
Yes, with maven you can specify compile time dependencies and avoid
loading them into the repositories.
And with this approach, it's easy to temporarily test with upgraded/
patches dependencies.
Craig
>
>>
>>>
>>>
>>> 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.
Craig Russell
Architect, Sun Java Enterprise System
http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell_at_sun.com
P.S. A good JDO? O, Gasp!
- application/pkcs7-signature attachment: smime.p7s