jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Launay (JIRA) <j...@apache.org>
Subject [jira] Updated: (JCR-2389) Update dependency versions for commons-collections, slf4j and derby
Date Wed, 18 Nov 2009 14:36:39 GMT

     [ 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.


Mime
View raw message