[
https://jira.codehaus.org/browse/MSANDBOX-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSANDBOX-13.
----------------------------------
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
> CSharp Plugins-Version overriding and transitive dependencies
> -------------------------------------------------------------
>
> Key: MSANDBOX-13
> URL: https://jira.codehaus.org/browse/MSANDBOX-13
> Project: Maven Sandbox
> Issue Type: Bug
> Environment: Windows XP
> Reporter: James Carpenter
>
> Further experience with the maven csharp plugins has revealed an interesting
> side affect of the current way in which maven built csharp libraries are
> used. As mentioned in MNG-2369, the csharp libraries built by maven have the
> version number in their name.
> Assume the following library heiarchy: A depends upon B which depends upon C
> (A->B->C).
> Lets assume the initial versioned dependencies are as follows:
> A_1.0 (explict dependency upon B_1.0)
> B_1.0 (explict dependency upon C_1.0)
> C_1.0
> Now lets assume C has changed to add some new feature needed by a new version
> of A. Lets assume that although A needs the new feature of C, the interfaces
> from C used B have not changed and hence no code changes are necessary to B.
> So we now try (Will not work with CSharp even though Java code would be fine):
> A_2.0 (explict dependency upon B_1.0, and C_2.0) Note: 2.0 version of C
> superceeds 1.0 in typical mvn fashion
> B_1.0 (explict dependency upon C_1.0)
> C_2.0
> This new configuration fails when the unit tests for A_2.0 are run. When the
> unit tests in A_2.0 are run we see that B_1.0 is looking for C_1.0 which
> doesn't exist as C_2.0 has taken its place in the dependency list. Remember
> that B_1.0 is looking for C_1.0 because the assembly meta-data in B_1.0 says
> it needs an assembly named C_1.0.dll.
> If none of the assemblies are strongly-named (assembly meta-data contains
> digital signatures for each dependency) it would be sufficient if the
> dependencies within the assembly meta-data didn't contain the version
> numbers. (Such a change would have synergies with whatever was done for 3rd
> party libraries.)
> Alternatively, I think one can probably include all versions mentioned by any
> of the dependencies. In this case it is important to maintain version
> numbers as part of the dependency names as doing so allows them to co-exist
> in the same directory. (Could be problematic for 3rd party dlls without
> version numbers in their name.)
> All of the above solutions require a change to the csharp maven support in
> some fashion. The only solution available today is to create a new release
> of B which uses the newer version of C.
> A_2.0 (explict dependency upon B_2.0)
> B_2.0 (explict dependency upon C_2.0)
> C_2.0
> The inability to override versions is both an advantage and disadvantage. As
> you can see there the advantage to the current solution is that B is now
> known to work with C_2.0. The disadvantage is one must re-release B just to
> get the updated C version.
> Summary: Version overriding with CSharp dependencies doesn't work out. A
> general solution to the problem is either impossible or at least awkward.
> The issue stems from the decision by MS to support digitally signed
> libraries, and the particulars of the current mvn csharp plugin behavior.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
