This makes sense to me - being more like the Java toolchain is a good
thing.
Shane - do these changes make sense to you then?
Cheers,
Brett
On 18/07/2008, at 8:45 PM, Leopoldo Agdeppa wrote:
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/
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
