Commons Dbcp
  1. Commons Dbcp
  2. DBCP-68

[dbcp] Commons Collection dependency version clash when using Commons DBCP via Maven2

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2
    • Fix Version/s: 1.2.2
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

      Description

      When using Maven2 to incorporate Commons DBCP 1.2.1 into your project a
      transient dependency on Commons Collections 2.1 is added. This will clash with
      other Commons Components like Commons Configuration 1.2 for example that depend
      on Commons Collections 3.1. Upon adding Commons DBCP 1.2.1 to your project the
      existing transient dependency on Commons Collections 3.1 gets changed into
      Commons Collections 2.1. This will result in runtime errors like the following:

      java.lang.NoClassDefFoundError: org/apache/commons/collections/map/LinkedMap
      at
      org.apache.commons.configuration.BaseConfiguration.<init>(BaseConfiguration.java:53)

      Since Commons Collections is incorporated into most Commons Components please
      update the dependency within Commons DBCP to Commons Collections 3.1 if possible.

        Activity

        Hide
        Henri Yandell added a comment -

        There's a DBCP release in the planning, so I imagine this will be very easy to integrate into that.

        I believe you can override such things in Maven2 in the meantime .

        Show
        Henri Yandell added a comment - There's a DBCP release in the planning, so I imagine this will be very easy to integrate into that. I believe you can override such things in Maven2 in the meantime .
        Hide
        Henri Yandell added a comment -

        svn ci -m "Updating to Collections 3.1 as suggested in #39502" project.xml
        Sending project.xml
        Transmitting file data .
        Committed revision 404836.

        Not marking as fixed though as this bug is not fixed until a release is done (into maven repository).

        Show
        Henri Yandell added a comment - svn ci -m "Updating to Collections 3.1 as suggested in #39502" project.xml Sending project.xml Transmitting file data . Committed revision 404836. Not marking as fixed though as this bug is not fixed until a release is done (into maven repository).
        Hide
        Phil Steitz added a comment -

        Updating to collections 3.1 may cause dependency problems for some users. Per discussion on commons-dev, I would prefer to bundle the required classes in their 2.1 versions. There are two classes required - o.a.c.collections.LRUMap and o.a.c.collections.SequencedHashMap and only one dbcp class that depends on them - o.a.c.dbcp.datasources.SharedPoolDataSource. The collections classes have been deprecated, but still exist, in Collections 3.x. I propose that we take the versions from the collections 2.1 source and include them with package scope in o.a.c.dbcp.datasources, then remove collections dependency altogether.

        Show
        Phil Steitz added a comment - Updating to collections 3.1 may cause dependency problems for some users. Per discussion on commons-dev, I would prefer to bundle the required classes in their 2.1 versions. There are two classes required - o.a.c.collections.LRUMap and o.a.c.collections.SequencedHashMap and only one dbcp class that depends on them - o.a.c.dbcp.datasources.SharedPoolDataSource. The collections classes have been deprecated, but still exist, in Collections 3.x. I propose that we take the versions from the collections 2.1 source and include them with package scope in o.a.c.dbcp.datasources, then remove collections dependency altogether.
        Hide
        Stephen Colebourne added a comment -

        Upgrading to a later version of collections shouldn't prove to be a problem. But, I agree with the proposed solution of removng the dependency in this case. Just ensure that neither class being copied is in the public API at the moment, or in the future.

        Show
        Stephen Colebourne added a comment - Upgrading to a later version of collections shouldn't prove to be a problem. But, I agree with the proposed solution of removng the dependency in this case. Just ensure that neither class being copied is in the public API at the moment, or in the future.
        Hide
        Phil Steitz added a comment -

        Sources have been added and dependency removed in r449319. Waiting to resolve until 1.2.2 release is cut.

        Show
        Phil Steitz added a comment - Sources have been added and dependency removed in r449319. Waiting to resolve until 1.2.2 release is cut.
        Hide
        Phil Steitz added a comment -

        1.2.2 has (at last) been released.

        Show
        Phil Steitz added a comment - 1.2.2 has (at last) been released.

          People

          • Assignee:
            Unassigned
            Reporter:
            Christoph Cenowa
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development