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/07/14 05:53:39 UTC
comments on trunk patches?
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
brett@apache.org
http://blogs.exist.com/bporter/
Re: comments on trunk patches?
Posted by Brett Porter <br...@apache.org>.
On 14/07/2008, at 11:48 PM, Jason van Zyl wrote:
> We now have something different here then what's in Maven? Or that's
> what's proposed. If so I don't think that's really a good idea.
No.
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: comments on trunk patches?
Posted by Jason van Zyl <ja...@maven.org>.
We now have something different here then what's in Maven? Or that's
what's proposed. If so I don't think that's really a good idea.
On 14-Jul-08, at 9:40 AM, Shane Isbell wrote:
> I was never clear on what was wrong with the existing toolchain
> implementation.
>
> Shane
>
> On Sun, Jul 13, 2008 at 11:31 PM, Leopoldo Agdeppa
> <la...@exist.com>
> wrote:
>
>> brett
>>
>> Thank you
>>
>> bong
>>
>> On Mon, Jul 14, 2008 at 1:53 PM, Brett Porter <br...@apache.org>
>> 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
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.
-- Jakob Burckhardt
Re: comments on trunk patches?
Posted by Brett Porter <br...@apache.org>.
On 01/08/2008, at 6:31 AM, Shane Isbell wrote:
> 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.
You're right - those are there so plugins can keep working pre-2.0.9
but since NMaven is dependent on toolchains and 2.0.9, it can do away
with the extra bits I think.
- Brett
>
>
> Shane
>
> On Thu, Jul 31, 2008 at 1:20 PM, Brett Porter <br...@apache.org>
> 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 <br...@apache.org>
>>> 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 <lagdeppa@exist.com
>>>>> >
>>>>> wrote:
>>>>>
>>>>> brett
>>>>>
>>>>>>
>>>>>> Thank you
>>>>>>
>>>>>> bong
>>>>>>
>>>>>> On Mon, Jul 14, 2008 at 1:53 PM, Brett Porter <br...@apache.org>
>>>>>> 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
>>>>>>> brett@apache.org
>>>>>>> http://blogs.exist.com/bporter/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: comments on trunk patches?
Posted by Shane Isbell <sh...@gmail.com>.
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 <br...@apache.org> 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 <br...@apache.org> 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 <la...@exist.com>
>>>> wrote:
>>>>
>>>> brett
>>>>
>>>>>
>>>>> Thank you
>>>>>
>>>>> bong
>>>>>
>>>>> On Mon, Jul 14, 2008 at 1:53 PM, Brett Porter <br...@apache.org>
>>>>> 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
>>>>>> brett@apache.org
>>>>>> http://blogs.exist.com/bporter/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: comments on trunk patches?
Posted by Brett Porter <br...@apache.org>.
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 <br...@apache.org>
> 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 <lagdeppa@exist.com
>>> >
>>> wrote:
>>>
>>> brett
>>>>
>>>> Thank you
>>>>
>>>> bong
>>>>
>>>> On Mon, Jul 14, 2008 at 1:53 PM, Brett Porter <br...@apache.org>
>>>> 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
>>>>> brett@apache.org
>>>>> http://blogs.exist.com/bporter/
>>>>>
>>>>>
>>>>>
>>>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: comments on trunk patches?
Posted by Leopoldo Agdeppa <la...@exist.com>.
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 <br...@apache.org> 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 <la...@exist.com>
>> wrote:
>>
>> brett
>>>
>>> Thank you
>>>
>>> bong
>>>
>>> On Mon, Jul 14, 2008 at 1:53 PM, Brett Porter <br...@apache.org> 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
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>>
>>>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: comments on trunk patches?
Posted by Brett Porter <br...@apache.org>.
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
> <la...@exist.com>
> wrote:
>
>> brett
>>
>> Thank you
>>
>> bong
>>
>> On Mon, Jul 14, 2008 at 1:53 PM, Brett Porter <br...@apache.org>
>> 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
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: comments on trunk patches?
Posted by Shane Isbell <sh...@gmail.com>.
I was never clear on what was wrong with the existing toolchain
implementation.
Shane
On Sun, Jul 13, 2008 at 11:31 PM, Leopoldo Agdeppa <la...@exist.com>
wrote:
> brett
>
> Thank you
>
> bong
>
> On Mon, Jul 14, 2008 at 1:53 PM, Brett Porter <br...@apache.org> 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
> > brett@apache.org
> > http://blogs.exist.com/bporter/
> >
> >
>
Re: comments on trunk patches?
Posted by Leopoldo Agdeppa <la...@exist.com>.
brett
Thank you
bong
On Mon, Jul 14, 2008 at 1:53 PM, Brett Porter <br...@apache.org> 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
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>