geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: G trunk and maven dependencies question
Date Tue, 14 Apr 2009 22:43:52 GMT

On Apr 14, 2009, at 1:08 PM, Peter Petersson wrote:
> Okey there are still problems building the derby plugin and I do get  
> the same result while building the monitoring plugin in trunk.
> This is what I do
> 1) clean out everything from local repository.
> 2) cd geronimo/repsoitory ... mvn install
> 3) cd plugins/monitor ... mvn clean
> 3) cd plugins/monitor/agent-ds ... mvn install
> ... and it will end up in
> [INFO] [car:package]
> [INFO] Packaging module configuration: /usr/local/proj/geronimo- 
> server/plugins/monitoring/agent-ds/target/resources/META-INF/plan.xml
> [INFO]  GBean references are not using proxies
> [INFO]  ClassLoading behaviour has changed.  The Original  
> Classloading mode is in effect.  If you are experiencing a problem
> you can change the behaviour by specifying - 
> DXorg.apache.geronimo.kernel.config.MPCLSearchOption= property.   
> Specify
> ="safe" to revert to the original behaviour.  This is a temporary  
> change until we decide whether or not to make it
> permanent for the 2.0 release
> [ERROR] Error while starting; GBean is now in the FAILED state:  
> abstractName="org.apache.geronimo.framework/jee-specs/2.2-SNAPSHOT/ 
> car?configurationName=org.apache.geronimo.framework/jee-specs/2.2- 
> org.apache.geronimo.kernel.repository.MissingDependencyException:  
> Missing dependency: org.apache.geronimo.specs/geronimo- 
> jaspi_1.0_spec/1.0-20080804.213256-1/jar  <<< ===== Problem ========
> org 
> .apache 
> .geronimo 
> .kernel 
> .config.ConfigurationResolver.resolve(
> I do not know if this is a thing I am the only one seeing but if not  
> I think It would be a good idea to try make plugin:s self contained  
> even in geronimo/server/trunk.
> IMHO it would be great if it would be possible to start a build of a  
> plugin (or assembly) from the root (or otherwise) of the plugin (or  
> assembly) and succeed in building it from a clean local repository.  
> A good start in being able to do this is to add the "geronimo  
> private repository" to the cmp section of the plugins parent pom.

A better start would be to actually release these artifacts.  IIUC  
this is going to be required to keep using maven and releasing to the  
central repo.

> My point is that by doing this and also maybe add some test case  
> that ensures that a plugin/assembly will build successfully  from a  
> clean repository may help in ensuring that the plugin/assembly  
> infrastructure will remain as self contained as possible and by  
> doing so also making sure that external projects making use of this  
> great concept of building Geronimo assemblies/plugins by use of the  
> car-maven-plugin will be able to do so without having to depend on a  
> local build of the geronimo/server.
> One drawback I can see (there are probably more) by doing this is  
> that it may mean more maintenance work on version updates but maybe  
> a property in the properties section of the root pom would make it  
> more obvious and less likely to be missed during version transactions.

I think this would be a great thing to do to check for lots of kinds  
of problems, not just versioning problems.  I think the particular  
problem bedeviling you is a bug of some kind however. Unfortunately  
I'm too involved in classloading work right now to try to figure out  
what is going on.

Another idea I have is to see what happens if you build the jaspi spec  
jar locally before building the plugin (but starting with a clean repo).

> I am not sure I have the knowledge that it takes to provide a patch  
> that build the test case I describe above and also integrate good  
> into the geronimo/server test suite but if time gives and it is  
> feasible/useful I could try to come up with something but this is  
> probably better done by someone having more understanding of  
> Geronimo:s test infrastructure and svn access.
> This is my two cent's but things are moving fast in trunk and likely  
> the problem I see now (if there are any) will pass in a moment or  
> two making my suggestion less useful.
> For now I will try to hunt down the problem I describe above.

david jencks

> regards
>  peter petersson


View raw message