Re: working around the local repository / filename limitation

> I believe the description of a very old JIRA I created against the  
> original C# support in the maven sandbox is still relevant to your  
> questions.
>
> ---------------------------
> The JIRA issue is:
> URL: http://jira.codehaus.org/browse/MSANDBOX-13
> Date: Aug 23, 2006
>
> --------------------------
> Description in MSANDBOX-13:
>
> 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.
>
> --- On Tue, 9/30/08, Brett Porter <brett@...> wrote:
>
>> From: Brett Porter <brett@...>
>> Subject: working around the local repository / filename limitation
>> To: nmaven-dev@...
>> Date: Tuesday, September 30, 2008, 1:36 PM
>> Hi,
>>
>> Trunk previously required a re-compiled NUnit assembly to
>> work, which
>> disappeared in the snapshot repository house keeping. I
>> wanted to try
>> again with a standard NUnit assembly, and saw that it
>> failed to run
>> the tests due to the filename issue. Fixing this is
>> important, as not
>> all assemblies can be recompiled.
>>
>> I added a simple class DotnetArtifactLocator that will load
>> the POM of
>> the artifact and check the finalName. If it is set, it is
>> returned
>> instead of the previous filename. If requested, it will
>> copy it to the
>> $version/$finalName.dll location in the local repository
>> (ie, one
>> level deeper in the current directory, as Dan suggested),
>> if it
>> doesn't already exist, and return that location
>> instead. This is meant
>> to be a very simple utility that plugins can use when they
>> need a
>> renamed artifact, and is potentially compatible with a
>> future local
>> repository layout adjustment.
>>
>> This resolved the issue for NUnit (as the file in
>> target-assemblies
>> could easily be renamed). I noted it wasn't needed for
>> compilation at
>> all, so I didn't include that. On the current trunk,
>> nothing else uses
>> artifacts.
>>
>> Questions:
>> - any thoughts on this approach?
>> - is there any reason the rename would be needed for
>> compilation?
>> - are there other scenarios on the current trunk where the
>> rename is
>> needed?
>>
>> I'd like to put this matter to bed :) The work is on
>> the branch
>> 'NMAVEN-8-nunit'. I still have a bit more to do,
>> but would like to
>> merge it back into trunk after those changes tomorrow.
>>
>> The repository I'm building up is at
>> http://people.apache.org/~brett/repositories/dotnet/
>>  for now - I still need to go back and add licenses, etc
>> before
>> pushing this anywhere permanent.
>>
>> Thanks,
>> Brett
>>
>> --
>> Brett Porter
>> brett@...
>> http://blogs.exist.com/bporter/