dev@glassfish.java.net

Re: Contents of maven repository

From: Jerome Dochez <Jerome.Dochez_at_Sun.COM>
Date: Thu, 31 Jan 2008 19:51:07 -0800

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.

>
>
> 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 ?
> Grizzly (once we finish final reviews and commits on the CORBA on
> Grizzly work)
1.7.0 ok ?
> 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.

>
> I see that the ManifestConstants class defines some of what I need
> to know,
> but is there a good example somewhere, and a bit of overall
> discussion on how this works?
> Do I need to implement the ModuleStartup interface?
no, this is the replacement for the main() method in the modules world,
>
> If so, when is it invoked, and why?
> How does this relate to the LifecyclePolicy interface?
no relation.
>
>
> 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.

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

> Thanks,
>
> Ken.
>
>