You are viewing a plain text version of this content. The canonical link for it is here.
Posted to nmaven-dev@incubator.apache.org by Brett Porter <br...@apache.org> on 2008/09/30 18:36:13 UTC
working around the local repository / filename limitation
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@apache.org
http://blogs.exist.com/bporter/
Re: working around the local repository / filename limitation
Posted by Brett Porter <br...@apache.org>.
On 01/10/2008, at 8:26 AM, Carlos Sanchez wrote:
> this relates to NMAVEN-193, groupId has changed for nunit in trunk
> vs 0.14
>
> with this new layout do trunk tests using nunit pass? I had noted in
> NMAVEN-186 that the missing nunit was causing ITs to fail
Yep. I think retaining the original group ID is therefore a better
alternative.
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: working around the local repository / filename limitation
Posted by Carlos Sanchez <ca...@carlossanchez.eu>.
this relates to NMAVEN-193, groupId has changed for nunit in trunk vs 0.14
with this new layout do trunk tests using nunit pass? I had noted in
NMAVEN-186 that the missing nunit was causing ITs to fail
On Tue, Sep 30, 2008 at 11:36 AM, Brett Porter <br...@apache.org> wrote:
> 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@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: working around the local repository / filename limitation
Posted by Brett Porter <br...@apache.org>.
Hi James,
I checked in a test case that confirms this situation works, again as
long as you set the finalName. Would you like to check it is what you
expected?
I haven't tested strong names yet. I believe that they will work, as
you use the classifier to reference them and no version mediation is
used, but I'll add a test case as well.
- Brett
On 01/10/2008, at 9:17 AM, James Carpenter wrote:
> 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 <br...@apache.org> wrote:
>
>> From: Brett Porter <br...@apache.org>
>> Subject: working around the local repository / filename limitation
>> To: nmaven-dev@incubator.apache.org
>> 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@apache.org
>> http://blogs.exist.com/bporter/
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: working around the local repository / filename limitation
Posted by James Carpenter <jc...@yahoo.com>.
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 <br...@apache.org> wrote:
> From: Brett Porter <br...@apache.org>
> Subject: working around the local repository / filename limitation
> To: nmaven-dev@incubator.apache.org
> 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@apache.org
> http://blogs.exist.com/bporter/