geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: m2 build - validating
Date Wed, 16 Aug 2006 23:51:06 GMT

On Aug 16, 2006, at 4:33 PM, Bill Dudney wrote:

> Hi All,
>
> i've been using the m2 build for several days now and I've noticed  
> that while it works well there are several details that are still  
> not nailed down. Particularly I've been hitting lots of dependency  
> issues around deployment. So what I've started doing is slogging  
> through each of them one at a time, posting a jira and a patch.
>
> It struck me that there are probably similar issues throughout the  
> server WRT the m2 build.
>
> I'm open to other methods (and would love to hear of a silver  
> bullet:) but seems to me that we need to basically hit everything  
> in the console and tools and such and make sure it works so we can  
> be sure the dependencies are correct. While I don't think I'll be  
> able to hit 'everything' I'll try to poke on most of the console  
> and the CLI tools and make sure that it 'works'.
>
> My plan of attack:
>
> 1 - provide patches for the stuff i know about now (tranql/tranql- 
> connector is missing for example from the repository)
> 2 - finish getting deployment working from the console (data  
> sources, ejb-jar's, wars etc)
> 3 - poke on the rest of the console
> 4 - deploy daytrader
> 5 - anything else anyone comes up with
>
> I will be posting bunches of jira's and fixes over the next few  
> days as I work through this stuff (unless someone has a better idea  
> about how to tackle it).

This is great that you are taking a look at this.  Here are some tips  
that may help fix dependency problems:

1. The modules use resources2/META-INF/geronimo-dependency.xml files  
to specify transitive dependencies.  We could use a lot more of  
these.  You may find the best solution to a classpath problem is  
adding one of these.

2. There are often several ways to get a jar into a classloader, such as
  a) depending on a car, from a car
  b) depending on a jar from a jar (using geornimo-dependency.xml)
  c) depending directly on the jar from a car
I'd say this is the order of preference

3) It is really important that the builder cars don't start any  
runtime cars: if you violate this rule the packaging plugin is likely  
to stop working.  You can have 2.a and enforce this rule by using the  
<scope> element in the dependency and setting it to <scope>classes</ 
scope>.  This means the dependency's classloader will be constructed  
and available for use but that no services from the car will be started.

This is in my experience somewhat nerve wracking and gruesome work,  
so I really appreciate your taking it on, and I'll do whatever I can  
to help you with it.

thanks
david jencks

>
> TTFN,
>
> -bd-
>
>


Mime
View raw message