[
https://issues.apache.org/jira/browse/JCR-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Launay updated JCR-2389:
----------------------------------
Attachment: JCR-2389-update-dependencies-2009-11-18_2.patch
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
> Update dependency versions for commons-collections, slf4j and derby
> -------------------------------------------------------------------
>
> Key: JCR-2389
> URL: https://issues.apache.org/jira/browse/JCR-2389
> Project: Jackrabbit Content Repository
> Issue Type: Task
> Affects Versions: 2.0-beta1
> Reporter: Attila Király
> Priority: Minor
> Attachments: JCR-2389-update-dependencies-2009-11-18.patch,
> JCR-2389-update-dependencies-2009-11-18_2.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
