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.
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.
Thanks!
david jencks
regards
peter petersson
<snip>
