geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Petersson <>
Subject Re: G trunk and maven dependencies question
Date Wed, 15 Apr 2009 19:03:50 GMT
David Jencks skrev:
> 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-SNAPSHOT/car"

>> 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.
Yes, but IIUC in this case it should mot matter as both 
geronimo/server/trunk cmp:s (and my project cmp:s) has included the 
that has the (and only the) geronimo-jaspi_1.0_spec 1.0-SNAPSHOT (and it 
gets pulled in to the local repository)
>> 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.
Yes, if it is not a missing version in the "configuration tree" it could 
be some other problem with the cmp making the explicit or transient 
version handling to kick in, although I think the former is the more 
likely and that the cmp dose just what is shall do, the question is 
where and how it gets hold of the timestamp version.
No problem I understand you have a handful, hopefully I will be able to 
figure out whats going on, my Liferay v5.2.2 on Geronimo v2.2 assembly 
works fine so this is just a sidestep to make thins more smooth during  
build and install.
> 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).
As I thing you (like me) already suspected this did not help but now 
it's confirmed, no success.
>> 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.
    peter petersson
> Thanks!
> david jencks
>> regards
>>  peter petersson
> <snip>

View raw message