Jorg Heymans wrote: > Marc Portier wrote: > >> after some digging I found >> - this missing class is provided by excalibur-pool-instrumented >> - which is a *provided* dependency from excalibur-datasources-2.2.1 >> (which is in turn required for our cocoon-databases-impl block) > > ... > >> for now I've just added an explicit dependency from our databases-impl >> to this pool-instrumented which makes me able to run cocoon 2.2. trunk >> (hurray!) > >>> Index: blocks/cocoon-databases/cocoon-databases-impl/pom.xml >>> =================================================================== >>> --- blocks/cocoon-databases/cocoon-databases-impl/pom.xml >>> (revision 529640) >>> +++ blocks/cocoon-databases/cocoon-databases-impl/pom.xml >>> (working copy) >>> @@ -83,5 +83,10 @@ >>> <artifactId>excalibur-datasource</artifactId> >>> <version>2.2.1</version> >>> </dependency> >>> + <dependency> >>> + <groupId>org.apache.excalibur.components</groupId> >>> + <artifactId>excalibur-pool-instrumented</artifactId> + >>> <version>2.2.1</version> >>> + </dependency> >>> </dependencies> >>> </project> > >> anyone with an opinion? > > Dependency hickup. I will release a new excalibur-datasource-2.2.2 with > the corrected pom. For now your fix seems OK (don't know though about > whether it should go in the samples block or not) >
dunno if we should apply the fix at all, if your fixing this at the source (and its ready for 2.2.-RC) then we can just remember this as a useful note for those doing clean installs/test-runs I am left to wonder though why this doesn't seem to hurt other people? haven't checked yet but how is the jetty classpath being built up? in other words: if the dependency isn't there how could it ever end up in the jetty classpath on e.g. your end? regards, -marc=
