Hello,
1) First Reason is this, Executing the compile plugin raises this error:
org.apache.maven.dotnet.ExecutionException: No toolchain found.
at
org.apache.maven.dotnet.compiler.impl.DotnetCompilerContextImpl.getCo
mpilerExecutableFor(DotnetCompilerContextImpl.java:142)
at
org.apache.maven.dotnet.extensions.compiler.CSharpClassCompiler.getCo
mpilerFileName(CSharpClassCompiler.java:200)
at
org.apache.maven.dotnet.extensions.compiler.CSharpClassCompiler.compi
le(CSharpClassCompiler.java:182)
...
I've been tracing this and found out that the reason for this is:
A null is returned in the
DefaultToolchainManager.getToolchainFromBuildContext since its not able to
find
a ToolchainFactory for type dotnet, The plexus component for the donet type
is not loaded, because it might
cause circular componet setting.
the solution that I did just solve that, by creating a toolchain manager for
donet and setting its component
in the same artifact. that is way in the patch there is a toolchain manager.
2) The second reason is something to do with maintainability, and
predictibility of posible change
- the original implimentation for dotnet toolchain is done this way
in the .m2/toolchains.xml
<toolchain>
<type>dotnet</type>
<provides>
<frameworkVersion>2.0</frameworkVersion>
<vendor>MICROSOFT</vendor>
<id>.NET Framework 2.0</id>
</provides>
<configuration>
<csharpCompiler>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc</csharpCompiler>
<nunitConsole>C:\Program Files\NUnit
2.4.6\bin\nunit-console</nunitConsole>
</configuration>
</toolchain>
as you can see, each executable tool is mapped in a single tag, that is
hardcoded in ConfigurationTag enum class,
this means that for each tool that you implement you have to add a new
entry and you will also have to re-build,
the maven-dotnet-toolchain artifact just to cater the change.
another problem with this approach is this discourages others to build
there own dotnet toolchain based plugins.
- The improved toolchain follows the java toolchain way, which is done
this way
original java toolchain:
<toolchain>
<type>jdk</type>
<provides>
<version>1.6.0</version>
</provides>
<configuration>
<jdkHome>C:\Program Files\java\jdk1.6.0</jdkHome>
</configuration>
</toolchain>
new dotnet toolchain:
<toolchain>
<type>dotnet</type>
<provides>
<frameworkVersion>2.0</frameworkVersion>
<vendorVersion>2.0.50727</vendorVersion>
<vendor>MICROSOFT</vendor>
<id>.NET Framework 2.0</id>
</provides>
<configuration>
<installRoot>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727</installRoot>
<sdkInstallRoot>C:\Program Files\Microsoft Visual Studio
8\SDK\v2.0</sdkInstallRoot>
</configuration>
</toolchain>
as you can see, both implementations won't need to add new entries for
new plugins developed.
the two toolchains uses folder locations to where the tools are located,
this minimizes the
posibility of code changes for every new dotnet plugin
implimentation.
if the dotnet vendor tools used different filenames as in the case of
mono,
then it is the responsiblity of the dotnet-plugin developer to handle
that, not the toolchain,
its easier to maintain it in a plugin level, not in the core
level.
3) the user is able to specify a toolchain based on its provides tags. just
like the java toolchian is created
thanks
bong
On Tue, Jul 15, 2008 at 12:35 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> On 14/07/2008, at 11:40 PM, Shane Isbell wrote:
>
> I was never clear on what was wrong with the existing toolchain
>> implementation.
>>
>
> I had some similar questions - will wait to hear what Bong has to say.
>
> What about the plugins themselves?
>
> Cheers,
> Brett
>
>
>
>>
>> Shane
>>
>> On Sun, Jul 13, 2008 at 11:31 PM, Leopoldo Agdeppa <[EMAIL PROTECTED]>
>> wrote:
>>
>> brett
>>>
>>> Thank you
>>>
>>> bong
>>>
>>> On Mon, Jul 14, 2008 at 1:53 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
>>>
>>> Hi,
>>>>
>>>> I've taken a look over NMAVEN-147, 148, 168 and they look suitable to
>>>>
>>> apply
>>>
>>>> to me.
>>>>
>>>> Anyone else had a chance to review them first?
>>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>> --
>>>> Brett Porter
>>>> [EMAIL PROTECTED]
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>>
>>>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>
