I'll take a look at the patch again. To me, the Java extension for the toolchain seems overly complicated (even going to point of reading private fields of a class) which I was never comfortable with. The patch replicates a similar extension implementation for .NET toolchains; if we can what we need to do with a simpler impl that would be preferable.
Shane On Thu, Jul 31, 2008 at 1:20 PM, Brett Porter <[EMAIL PROTECTED]> wrote: > 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/ > >
