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, 22 Apr 2009 22:52:49 GMT
I have been trying to find out why (and where) Geronimo is finding the 
Although maven (mvn -X install) dose not find this version in any 
repository specified by the cmp or otherwise (only the 1.0-SNAPSHOT)
somehow the org.apache.geronimo.kernel.config.ConfigurationResolver and 
org.apache.geronimo.kernel.repository.DefaultArtifactResolver (kicked in 
by the GBean) has got hold of (and correctly elects) this timestamp 
version causing the missing dependency exception.

Finding out witch files/repositories is actually searched during 
artifact/dependency resolving by the g kernel would probably lead to the 
answer but I have found it hard to find out if any additional 
repositories (or files) is searched by the kernel expect the ones 
specified by the cmp that makes it possible for the resolver to find 
this timestamp version although it seems to be something there.

Searching repositories, the web and my local comp for this 
artifact/version the only place where I actually found it specified is 
but I doubt this file is involved in artifact resolving ;).

    peter petersson

Peter Petersson skrev:
> 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 
> source-repository 
> 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.
> regards
>    peter petersson
>> Thanks!
>> david jencks
>>> regards
>>>  peter petersson
>> <snip>

View raw message