[
https://issues.apache.org/jira/browse/CONFIGURATION-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579355#action_12579355
]
Joerg Schaible commented on CONFIGURATION-317:
----------------------------------------------
IIRC this issue has been reported as bug of the assembly plugin. While I
understand your position very well, your suggestion is imply not manageable.
Suppose that we release lang 2.5. Then we would have to release immediately a
lot of other commons components as well. And the next user might argue, since
all those artifacts are delivered by the ASF ... ;-)
The referenced version always states the version of a dependent artifact the
release was tested against. Whether another version of the dependency really
works cannot be answered easily, especially since it would require to test the
same project at least against the available versions of all directly used
dependencies (and any permutation of it). It is again simply not manageable.
> 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.