[ 
https://issues.apache.org/jira/browse/CONFIGURATION-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579521#action_12579521
 ] 

Olivier Vierlinck commented on CONFIGURATION-317:
-------------------------------------------------

Thanks for the input on assembly bug; i'll try to check this with them.
For information, one work-around I found is not to use "dependenciesManagement" 
but directly "dependencies", with a version set explicitely to 3.2.

So, as this is out of the hand of commons-config, I guess you can close this 
issue... 

Some other comments:

"Then we would have to release immediately " Maybe not immediately but at least 
at the next release of this other commons component.

"it would require to test the same project [...] manageable": I certainly 
understand the size of the testing effort. But the problem is that this tests 
MUST be performed, at least by users of the commons components, because of the 
combination induced between various (commons or not) components using commons 
components.
(and this seems to be done by commons-configuration team, as described in 
http://commons.apache.org/configuration/dependencies.html: "Below is a table 
with the version numbers that have been tested"

Thanks again,
Cheers,
Olivier


> Version conflict on dependence for commons-collections
> ------------------------------------------------------
>
>                 Key: CONFIGURATION-317
>                 URL: https://issues.apache.org/jira/browse/CONFIGURATION-317
>             Project: Commons Configuration
>          Issue Type: Wish
>          Components: Build
>    Affects Versions: 1.4, 1.5
>         Environment: Seen on Windows XP but should be platform independant
>            Reporter: Olivier Vierlinck
>            Priority: Minor
>
> Based on the pom.xml files:
> commons config (1.4 and 1.5) depends on commons colletions ** 3.2 **  and on 
> commons-beanutils 1.7
> Unfortunately commons-beanutils 1.7depends on commons-collection ** 2.0 **
> I know this kind of jar version clash is not unusual with java/Maven. I know 
> also we can fix it with <dependencyManagement> instruction in maven.
> However, i experienced trouble when using the assembly:assembly project, 
> which does not seem to take into account my <dependencyManagement>.
> But as all these project are coming from apache-commons, I think it would be 
> nice if they all fit together, with a coherent version choice. Probably just 
> uprading beanutils so that it depends on commons-collection 3.2 would work 
> and solve this (I didn't test that)
> i consider this issue as a general comment on common, to have better version 
> management, possibly using ranges (for example if beanutils has been tested 
> succesfully with commons-collections from 2.0 to 3.2)
> What do you think?
> Cheers and thanks for all the work and tools you gave us
> Olivier

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to