groovy

Groovy-all pom.xml has dependency to an outdated version of Castor

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.1-beta-2
  • Fix Version/s: 1.1-rc-1
  • Component/s: groovy-jdk
  • Labels:
    None
  • Number of attachments :
    1

Description

I'm using the groovy-all-1.1-beta-2.jar in a Maven project that is also using a recent version of Castor (1.1.2.1). Unfortunately, the groovy-all pom.xml includes a runtime dependency to castor-0.9.9.jar. 0.9.9 is several years old and should be updated to a more recent version of Castor.

Activity

Hide
Guillaume Laforge added a comment -

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?

Show
Guillaume Laforge added a comment - 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?
Hide
Brian Schlining added a comment -

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>
Show
Brian Schlining added a comment - 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>
Hide
Paul King added a comment -

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.

Show
Paul King added a comment - 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.
Hide
Brian Schlining added a comment -

I can have a go at fixing this...

That works for me...enjoy

Show
Brian Schlining added a comment -
I can have a go at fixing this...
That works for me...enjoy
Hide
Paul King added a comment -

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.

Show
Paul King added a comment - 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.
Hide
Brian Schlining added a comment -

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?

Show
Brian Schlining added a comment - 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?
Hide
Paul King added a comment -

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.

Show
Paul King added a comment - 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.
Hide
Paul King added a comment -

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

Show
Paul King added a comment - How did you generate the dependency png by the way? It would be great to have that as part of the build.
Hide
Brian Schlining added a comment -

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

Show
Brian Schlining added a comment - 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
Hide
Paul King added a comment -

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

Show
Paul King added a comment - moved the offending code (which was actually test anyway) to examples - as the test wasn't being called

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: