Could you provide a patch with changes to the pom that would suite your needs?
Shouldn't the dependency be a compile-time dependency instead?

I'll try to provide a patch in the next day or two.

Shouldn't the dependency be a compile-time dependency instead?

It doesn't necessarily matter whether the dependency is declared as runtime or compile (as long as the unit tests pass ). In the end, either one will result in the jar be included at runtime when building an assembly.

The current workaround is to exclude the old castor jar in Maven2 projects that use both groovy-all and a more recent castor. Like so:

<dependency>
    <groupId>groovy</groupId>
    <artifactId>groovy-all</artifactId>
    <version>1.1-beta-2</version>
    <scope>runtime</scope>
    <exclusions>
        <exclusion>
             <artifactId>castor</artifactId>
             <groupId>castor</groupId>
         </exclusion>
     </exclusions>
</dependency>

I was waiting for the 1.0 pom to be fixed. I didn't realise that castor had moved its groupId to org.codehaus.castor which has more recent versions with working POMs. I can have a go at fixing this unless you have already worked out the minimal fix.

I can have a go at fixing this...

That works for me...enjoy

I updated the POM to use 1.1.2.1 but it isn't clear whether we should just delete this dependency altogether. If OpenEjb is now the only thing using castor, I think this is the way to go. I'll leave this issue open until I can investigate.

I've attached a graph of the dependency tree described by the POM. OpenEJB doesn't have a dependency on Castor. It looks to me like Castor doesn't need to be included in Groovy's POM at all. Does anyone know why it's there?

At one stage, our pom used to have a dependency on openejb-core which I changed to openejb-loader as that was all that seemed to be required. Castor is a dependency of openejb-core and at the time it was conflicting with something else, so perhaps castor is a dependency on something else - or perhaps it was just something else that I was playing with at the time while trying to embed Groovy. I'll have to investigate more.

The bigger question for me is around usage of openejb altogether. I don't have a good feel for its use in the wild with Groovy. Perhaps we could remove it or otherwise move it to a module and more closely align its use with Geronimo releases or something.

How did you generate the dependency png by the way? It would be great to have that as part of the build.

I used Dependency Analyzer, which is an open source project at http://sourceforge.net/projects/dep-analyzer/. It's not a Maven plugin though; so I'm not sure how it would be run as part of the build. Netbeans has a similar function in it's the MevenIDE module; but the graphing part seems to be missing from the latest Netbeans Milestone (M10)

I think there is a Maven plugin for generating dependency graphs, but I haven't tried it. The web site for it is at http://el4j.sourceforge.net/plugins/maven-depgraph-plugin/index.html

moved the offending code (which was actually test anyway) to examples - as the test wasn't being called