I have been trying to find out why (and where) Geronimo is finding the
org.apache.geronimo.specs/geronimo-jaspi_1.0_spec/1.0-20080804.213256-1/jar
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
in http://geronimo.apache.org/plugins/geronimo-2.2/geronimo-plugins.xml
but I doubt this file is involved in artifact resolving ;).
regards
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(ConfigurationResolver.java:113)
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
http://people.apache.org/repo/m2-snapshot-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>
