maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Porter (JIRA)" <>
Subject [jira] Moved: (MSANDBOX-13) CSharp Plugins-Version overriding and transitive dependencies
Date Mon, 18 Jun 2007 00:41:57 GMT


Brett Porter moved MNG-2527 to MSANDBOX-13:

    Fix Version/s:     (was: Reviewed Pending Version Assignment)
      Component/s:     (was: Multiple Language Support)
                       (was: Sandbox)
              Key: MSANDBOX-13  (was: MNG-2527)
          Project: Maven 2.x Sandbox  (was: Maven 2)

> CSharp Plugins-Version overriding and transitive dependencies
> -------------------------------------------------------------
>                 Key: MSANDBOX-13
>                 URL:
>             Project: Maven 2.x 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 is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message