Geronimo structure

[Glyn Normington <gl...@yahoo.co.uk>]

I am trying to understand the structure of geronimo. I found a useful 
picture of the class loader hierarchy in Aaron's draft book.

Any pointers as to how the set of subdirectories of geronimo/modules is 
reflected, if at all, in runtime structure? For example, are all those 
classes loaded by the org/apache/geronimo/Server class loader?

"maven site" generated a "dependencies" page describing geronimo as a 
stand-alone application with no dependencies on any other project. Is 
this accurate?

Sorry for such basic questions - I only started looking at the 
implementation yesterday. :-)

Glyn

Re: Geronimo structure

[Dain Sundstrom <ds...@gluecode.com>]

On Nov 2, 2004, at 8:47 AM, Jeremy Boynes wrote:

> Glyn Normington wrote:
>
>> "maven site" generated a "dependencies" page describing geronimo as a 
>> stand-alone application with no dependencies on any other project. Is 
>> this accurate?
>
> No. There are many dependencies.

The problem is maven does not aggregate the dependencies from each 
module into a single top level page.  You have to click on each module 
to see the dependencies of that module.  For example, this is a link to 
the dependencies of the kernel module:

http://geronimo.apache.org/modules/kernel/dependencies.html

-dain

Re: Geronimo structure

[Jeremy Boynes <jb...@gluecode.com>]

Glyn Normington wrote:
> I am trying to understand the structure of geronimo. I found a useful 
> picture of the class loader hierarchy in Aaron's draft book.
> 
> Any pointers as to how the set of subdirectories of geronimo/modules is 
> reflected, if at all, in runtime structure? For example, are all those 
> classes loaded by the org/apache/geronimo/Server class loader?
> 

It isn't really. The modules are independent units of development that 
deal with a specific function.

> "maven site" generated a "dependencies" page describing geronimo as a 
> stand-alone application with no dependencies on any other project. Is 
> this accurate?
> 

No. There are many dependencies.

> Sorry for such basic questions - I only started looking at the 
> implementation yesterday. :-)
> 

NP. If you are looking to see what is actually used in the final 
distribution, the best place to start would be the assembly module that 
pulls it all together. In the project.xml the dependencies have 
properties that determine where they end up (lib ot repo).

To determine how these are used look at the deployment plans in that 
module under src/plan. The <dependency> elements show which jars are 
pulled in by each classloader. Each plan defines a Configuation and each 
Configuration is a classloader.

--
Jeremy