Jackrabbit Content Repository
  1. Jackrabbit Content Repository
  2. JCR-2389

Update dependency versions for commons-collections, slf4j and derby

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0-beta1
    • Fix Version/s: 2.0-beta4
    • Component/s: None
    • Labels:
      None

      Description

      Some of the dependencies used by the 2.0-beta1 could be upgraded:
      commons-collections from 3.1 to 3.2.1
      slf4j from 1.5.3 to 1.5.8
      derby from 10.2.1.6 to 10.5.3.0

      Not sure about derby but the other two seems to be just drop in replacements for their older verisons.

        Issue Links

          Activity

          Hide
          Sébastien Launay added a comment -

          I agree that using old release of libraries can be painful in an application when you do not have access to separate classloader mechanism (like in OSGI) and you use additional libraries with conflicting dependencies.

          I think that upgrading runtime transitive dependencies can be done in the 2.0 development branch as this is a major version upgrade from 1.x.

          So I proposed the following patch for:

          • migrating slf4j dependency from 1.5.3 to 1.5.8
          • migrating commons-collections dependency from 3.1 to 3.2.1 with deprecation modifications [1]
            this implies a new dependency on commons-beanutils for jackrabbit-core (test) and jackrabbit-webapp
          • migrating commons-beanutils (previously not used but defined in jackrabbit-parent) from 1.7.0 to 1.8.2
          • migrating jetty dependencies from 6.1.14 to 6.1.22
          • migrating xerces dependencies from 2.8.1 to 2.9.0
          • removing unused parent dependencies (commons-digester, commons-lang)
          • remove duplicates servlet-api and jsp-api dependencies

          With this patch applied to trunk build with tests is successful (I just disable the AdministratorTest#testAdminNodeCollidingWithRandomNode test case).

          I believe we can also upgrade from commons-httpclient 3.0 to HttpClient 4.0 on jackrabbit-spi2dav with a few modifications.

          For Derby, i agree that upgrading is not safe and must be reviewed by a PersistenceManager expert .

          [1] http://commons.apache.org/collections/api-release/org/apache/commons/collections/BeanMap.html

          Show
          Sébastien Launay added a comment - I agree that using old release of libraries can be painful in an application when you do not have access to separate classloader mechanism (like in OSGI) and you use additional libraries with conflicting dependencies. I think that upgrading runtime transitive dependencies can be done in the 2.0 development branch as this is a major version upgrade from 1.x. So I proposed the following patch for: migrating slf4j dependency from 1.5.3 to 1.5.8 migrating commons-collections dependency from 3.1 to 3.2.1 with deprecation modifications [1] this implies a new dependency on commons-beanutils for jackrabbit-core (test) and jackrabbit-webapp migrating commons-beanutils (previously not used but defined in jackrabbit-parent) from 1.7.0 to 1.8.2 migrating jetty dependencies from 6.1.14 to 6.1.22 migrating xerces dependencies from 2.8.1 to 2.9.0 removing unused parent dependencies (commons-digester, commons-lang) remove duplicates servlet-api and jsp-api dependencies With this patch applied to trunk build with tests is successful (I just disable the AdministratorTest#testAdminNodeCollidingWithRandomNode test case). I believe we can also upgrade from commons-httpclient 3.0 to HttpClient 4.0 on jackrabbit-spi2dav with a few modifications. For Derby, i agree that upgrading is not safe and must be reviewed by a PersistenceManager expert . [1] http://commons.apache.org/collections/api-release/org/apache/commons/collections/BeanMap.html
          Hide
          Thomas Mueller added a comment -

          Upgrading Derby should be no problem. Jackrabbit doesn't need any special features.

          Show
          Thomas Mueller added a comment - Upgrading Derby should be no problem. Jackrabbit doesn't need any special features.
          Hide
          Attila Király added a comment -

          Nice to see this progressing!

          I would also like to add one that I forgot last time: H2 db. It seems it is not listed as dependency in the poms but it is needed by the o.a.j.core.persistence.bundle.H2PersistenceManager. It would be nice to add it to the dependencies (maybe marked as optional) with the most recent stable version (currently 1.2.23).

          This also needs some expert checking that the upgrade is safe with the PersistenceManager.

          Show
          Attila Király added a comment - Nice to see this progressing! I would also like to add one that I forgot last time: H2 db. It seems it is not listed as dependency in the poms but it is needed by the o.a.j.core.persistence.bundle.H2PersistenceManager. It would be nice to add it to the dependencies (maybe marked as optional) with the most recent stable version (currently 1.2.23). This also needs some expert checking that the upgrade is safe with the PersistenceManager.
          Hide
          angela added a comment -

          > I believe we can also upgrade from commons-httpclient 3.0 to HttpClient 4.0 on jackrabbit-spi2dav with a few modifications.

          -1 for changing this dependency.

          i don't have any time left to run after problems that might be introduced by 'few modifications' or changed behavior or unknown bugs of the
          httpclient 4.0... and i'm pretty confident that this would cause problems here and there. after all HttpClient 4.0 was just released a couple of
          month ago (August 17, 2009).

          Show
          angela added a comment - > I believe we can also upgrade from commons-httpclient 3.0 to HttpClient 4.0 on jackrabbit-spi2dav with a few modifications. -1 for changing this dependency. i don't have any time left to run after problems that might be introduced by 'few modifications' or changed behavior or unknown bugs of the httpclient 4.0... and i'm pretty confident that this would cause problems here and there. after all HttpClient 4.0 was just released a couple of month ago (August 17, 2009).
          Hide
          Jukka Zitting added a comment -

          httpclient: Agreed with Angela, the 3.0 -> 4.0 upgrade is a non-trivial change that should be handled as a separate task.

          beanutils: AFAIK we only use BeanMap in two places anymore. Instead of the new dependency, I'd rather use a copy of the BeanMap class or refactor the reference away.

          Show
          Jukka Zitting added a comment - httpclient: Agreed with Angela, the 3.0 -> 4.0 upgrade is a non-trivial change that should be handled as a separate task. beanutils: AFAIK we only use BeanMap in two places anymore. Instead of the new dependency, I'd rather use a copy of the BeanMap class or refactor the reference away.
          Hide
          Thomas Mueller added a comment -

          > H2 ... needed by the o.a.j.core.persistence.bundle.H2PersistenceManager.

          It is not required to add H2 as a dependency. Specially, the version is not needed.
          If your application uses H2, you can still add it there.

          Show
          Thomas Mueller added a comment - > H2 ... needed by the o.a.j.core.persistence.bundle.H2PersistenceManager. It is not required to add H2 as a dependency. Specially, the version is not needed. If your application uses H2, you can still add it there.
          Hide
          Attila Király added a comment -

          > It is not required to add H2 as a dependency. Specially, the version is not needed.
          > If your application uses H2, you can still add it there.

          Okay. Could you add a note somewhere in the documentation or on the site about the H2 version that was tested with H2PersistenceManager? Currently this information is not available.

          Show
          Attila Király added a comment - > It is not required to add H2 as a dependency. Specially, the version is not needed. > If your application uses H2, you can still add it there. Okay. Could you add a note somewhere in the documentation or on the site about the H2 version that was tested with H2PersistenceManager? Currently this information is not available.
          Hide
          Thomas Mueller added a comment -

          > the H2 version that was tested with H2PersistenceManager

          You can use any version of H2 The features required by Jackrabbit (by the H2PersistenceManager) are very basic. I'm not aware of a combination that doesn't work.

          Show
          Thomas Mueller added a comment - > the H2 version that was tested with H2PersistenceManager You can use any version of H2 The features required by Jackrabbit (by the H2PersistenceManager) are very basic. I'm not aware of a combination that doesn't work.
          Hide
          Sébastien Launay added a comment -

          New proposed patch with:

          • migrating slf4j dependency from 1.5.3 to 1.5.8
          • migrating commons-collections dependency from 3.1 to 3.2.1 and keeping the 2 classes using deprecated BeanMap [1]
          • migrating jetty dependencies from 6.1.14 to 6.1.22
          • migrating xerces dependencies from 2.8.1 to 2.9.0
          • migrating derby dependencies from 10.2.1.6 to 10.5.3.0_1 (10.5.3.0 has a buggy pom.xml)
          • removing unused parent dependencies (commons-beanutils, commons-digester, commons-lang, derbynet, derbyclient)
          • remove duplicates servlet-api and jsp-api dependencies

          Again with this patch applied to trunk build with tests is successful (minus the AdministratorTest#testAdminNodeCollidingWithRandomNode test case).

          > httpclient: Agreed with Angela, the 3.0 -> 4.0 upgrade is a non-trivial change that should be handled as a separate task.

          I did not realized that this dependency is critical, it's just that from my experience httpclient is one of these libs that tends to be pulled by another third party lib and often with conflicted versions .

          > beanutils: AFAIK we only use BeanMap in two places anymore. Instead of the new dependency, I'd rather use a copy of the BeanMap class or refactor the reference away.

          I think we can keep using the deprecated BeanMap till migrating to future common-collections 4.0.
          Moreover one of the two places is for one of the jackrabbit-core test cases.

          I am not very familiar with maven (more of an Ivy guy ) but FWIU the derby dependency is mandatory for jackrabbit-core even if there is no java import of any Derby class (the same apply for H2 or any *PM with a JDBC driver).
          But when a user pull jackrabbit from maven he must exclude derby if he does not want it (rather than explicitly pulling the JR derby dependency like with Ivy configuration [1]).
          I think that Derby and H2 are pretty much on the same level in jackrabbit-core.
          This is not the case for jackrabbit-webapp or jackrabbit-standalone where we explicitly want to use a DerbyPM.

          Are there specific reasons for this maven configuration? (maybe a thread on the dev list is more appropriate for such discussion)

          [1] http://ant.apache.org/ivy/history/latest-milestone/ivyfile/conf.html

          Show
          Sébastien Launay added a comment - New proposed patch with: migrating slf4j dependency from 1.5.3 to 1.5.8 migrating commons-collections dependency from 3.1 to 3.2.1 and keeping the 2 classes using deprecated BeanMap [1] migrating jetty dependencies from 6.1.14 to 6.1.22 migrating xerces dependencies from 2.8.1 to 2.9.0 migrating derby dependencies from 10.2.1.6 to 10.5.3.0_1 (10.5.3.0 has a buggy pom.xml) removing unused parent dependencies (commons-beanutils, commons-digester, commons-lang, derbynet, derbyclient) remove duplicates servlet-api and jsp-api dependencies Again with this patch applied to trunk build with tests is successful (minus the AdministratorTest#testAdminNodeCollidingWithRandomNode test case). > httpclient: Agreed with Angela, the 3.0 -> 4.0 upgrade is a non-trivial change that should be handled as a separate task. I did not realized that this dependency is critical, it's just that from my experience httpclient is one of these libs that tends to be pulled by another third party lib and often with conflicted versions . > beanutils: AFAIK we only use BeanMap in two places anymore. Instead of the new dependency, I'd rather use a copy of the BeanMap class or refactor the reference away. I think we can keep using the deprecated BeanMap till migrating to future common-collections 4.0. Moreover one of the two places is for one of the jackrabbit-core test cases. I am not very familiar with maven (more of an Ivy guy ) but FWIU the derby dependency is mandatory for jackrabbit-core even if there is no java import of any Derby class (the same apply for H2 or any *PM with a JDBC driver). But when a user pull jackrabbit from maven he must exclude derby if he does not want it (rather than explicitly pulling the JR derby dependency like with Ivy configuration [1] ). I think that Derby and H2 are pretty much on the same level in jackrabbit-core. This is not the case for jackrabbit-webapp or jackrabbit-standalone where we explicitly want to use a DerbyPM. Are there specific reasons for this maven configuration? (maybe a thread on the dev list is more appropriate for such discussion) [1] http://ant.apache.org/ivy/history/latest-milestone/ivyfile/conf.html
          Hide
          Thomas Mueller added a comment -

          Derby is the default persistence manager, so it is required when using Jackrabbit out-of-the-box.
          I'm not completely sure, but I think for Jackrabbit core the Derby dependency could be <scope>test</scope>.

          H2 (and MySQL, PostgreSQL,... any database or JDBC driver) are not needed at all
          (not used for testing and not used as the default database).

          Show
          Thomas Mueller added a comment - Derby is the default persistence manager, so it is required when using Jackrabbit out-of-the-box. I'm not completely sure, but I think for Jackrabbit core the Derby dependency could be <scope>test</scope>. H2 (and MySQL, PostgreSQL,... any database or JDBC driver) are not needed at all (not used for testing and not used as the default database).
          Hide
          Attila Király added a comment -

          These are typical optional dependencies. Maven has support for it [1]. Defining a dependency as optional in jackrabbit would mean that it will not be pulled unless it is explicitely specified by the jackrabbit user project.

          [1]: http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

          Show
          Attila Király added a comment - These are typical optional dependencies. Maven has support for it [1] . Defining a dependency as optional in jackrabbit would mean that it will not be pulled unless it is explicitely specified by the jackrabbit user project. [1] : http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
          Hide
          Thomas Mueller added a comment -

          As far as I understand Maven (and I'm definitely not an expert), "optional dependencies" mean dependencies that are needed to compile the project, but not necessarily needed at runtime. You don't need any JDBC driver to compile Jackrabbit core (not even Derby). You only need Derby (the default persistence manager) when running the tests.

          Show
          Thomas Mueller added a comment - As far as I understand Maven (and I'm definitely not an expert), "optional dependencies" mean dependencies that are needed to compile the project, but not necessarily needed at runtime. You don't need any JDBC driver to compile Jackrabbit core (not even Derby). You only need Derby (the default persistence manager) when running the tests.
          Hide
          Lutz Horn added a comment -

          I'd very much prefer httpclient 4.0 to be used. For development of new applications it makes no sense to use 3.x. After all: "Commons HttpClient 3.x codeline is nearing the end of life. All users of Commons HttpClient 3.x are strongly encouraged to upgrade to HttpClient 4.0."

          Show
          Lutz Horn added a comment - I'd very much prefer httpclient 4.0 to be used. For development of new applications it makes no sense to use 3.x. After all: "Commons HttpClient 3.x codeline is nearing the end of life. All users of Commons HttpClient 3.x are strongly encouraged to upgrade to HttpClient 4.0."
          Hide
          Sébastien Launay added a comment -

          After reading the source code, I indeed found that derby is required by the default repository.xml configuration (new TransientRepository()).

          Therefore this dependency cannot be optional (needed both for test and runtime) and the only solution is to explicitly exclude derby when depending jackrabbit-core.

          Any objections/concerns with the latest patch?

          Show
          Sébastien Launay added a comment - After reading the source code, I indeed found that derby is required by the default repository.xml configuration (new TransientRepository()). Therefore this dependency cannot be optional (needed both for test and runtime) and the only solution is to explicitly exclude derby when depending jackrabbit-core. Any objections/concerns with the latest patch?
          Hide
          Thomas Mueller added a comment -

          No objections for the patch.

          About Derby: Derby is not required to compile Jackrabbit. It is required when running the tests (that's why I wrote <scope>test</scope>). And it is used as the default persistence manager, so jackrabbit-standalone should include Derby. However, Derby is not required at runtime if you configure a different persistence manager. In the long term, I believe the Derby dependency within jackrabbit-core should be <scope>test</scope> and not anything else. Short term, it doesn't really matter.

          Show
          Thomas Mueller added a comment - No objections for the patch. About Derby: Derby is not required to compile Jackrabbit. It is required when running the tests (that's why I wrote <scope>test</scope>). And it is used as the default persistence manager, so jackrabbit-standalone should include Derby. However, Derby is not required at runtime if you configure a different persistence manager. In the long term, I believe the Derby dependency within jackrabbit-core should be <scope>test</scope> and not anything else. Short term, it doesn't really matter.
          Hide
          Sébastien Launay added a comment -

          > I'd very much prefer httpclient 4.0 to be used.

          I just created JCR-2406 feel free to provide a patch tested against multiple WebDAV clients.

          > About Derby.

          I agree that this dependency is needed only at runtime and only if it is used in a PersistenceManager/DataStore.
          But removing it or rendering it optional implies a non working use of new TransientRepository() with jackrabbit-core (and also by transitivity jackrabbit-webapp/standalone).

          Maybe the solution is to remove the default repository.xml (only for testing purpose) and force the user to specify one.
          But this leads to a more difficult first approach of Jackrabbit (first hops).

          Show
          Sébastien Launay added a comment - > I'd very much prefer httpclient 4.0 to be used. I just created JCR-2406 feel free to provide a patch tested against multiple WebDAV clients. > About Derby. I agree that this dependency is needed only at runtime and only if it is used in a PersistenceManager/DataStore. But removing it or rendering it optional implies a non working use of new TransientRepository() with jackrabbit-core (and also by transitivity jackrabbit-webapp/standalone). Maybe the solution is to remove the default repository.xml (only for testing purpose) and force the user to specify one. But this leads to a more difficult first approach of Jackrabbit (first hops).
          Hide
          Thomas Mueller added a comment -

          You are right, TransientRepository needs it, so let's keep the Derby dependency.

          Show
          Thomas Mueller added a comment - You are right, TransientRepository needs it, so let's keep the Derby dependency.
          Hide
          Jukka Zitting added a comment -

          Seems like we are in an agreement, so I committed Sébastien's patch. Resolving as Fixed.

          Show
          Jukka Zitting added a comment - Seems like we are in an agreement, so I committed Sébastien's patch. Resolving as Fixed.

            People

            • Assignee:
              Unassigned
              Reporter:
              Attila Király
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development