incubator-nmaven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: platform independence for the build
Date Thu, 20 Dec 2007 01:54:55 GMT
sounds good to me!

On 20/12/2007, at 9:48 AM, Shane Isbell wrote:

> I've been crawling around the toolchain implementation and have a  
> rough idea
> of how this is going to work.
> First, we have a dead simple rule that chooses microsoft for windows  
> and
> mono for all other platforms. A developer can override this within the
> pom.xml under the compiler plugin configuration in case they need to  
> compile
> with mono on windows. This will require that the user adds the  
> appropriate
> path to the classpath. If they don't, funny behavior could occur. For
> example, on windows, if a developer places mono on the classpath but
> specifies microsoft as the vendor, then it will compiler under mono  
> 1.1.
> Initially, we will only support .NET 2.0 (unless they hit the  
> situation
> outlined above). We can release NMaven against the 2.0.x branch.
> Second, when we are ready, we use the toolchain under shared. This
> requires implementing some classes for .NET support, this is a minor  
> amount
> of effort. It may, however, require some changes to the toolchain  
> API. When
> the toolchain releases under maven 2.0.9+, we will require that  
> version for
> NMaven. This switch means that the developer no longer specifies the  
> vendor
> (and framework versions) under the compiler plugin config, but  
> rather adds
> the toolchain plugin to the pom.xml and uses the toolchains plugin
> configuration to specify the vendor information. This will allow us to
> configure the exact path of the executables. At that point, we can  
> expand
> out support for multiple .NET versions, vendor versions and so on.
> In many ways, the toolchain is very similar to the nmaven-settings  
> in 0.14.
> The toolchains, however, will be standardized across Maven, so there  
> will
> not be a divergence; toolchains supports the notion of version  
> ranges; it
> only needs to be initialized once, resulting in a performance  
> improvement;
> and finally, we won't be specifying a state machine to infer the  
> best match
> based on the platform, this will all be in the hands of the developer.
> Since the toolchain can handle passing in framework locations,  
> developers
> won't be modifying their paths. For IT, we would likely specify  
> different
> toolchains.xml files to use for testing under multiple platforms.
> One other feature that I am interested in is a .NET app that reads the
> window's registry and displays toolchain options to the user. In this
> way, we can have a GUI based application for discovering platform
> capabilities and for configuring the toolchain.
> Regards,
> Shane
> On Dec 17, 2007 1:19 PM, Shane Isbell <> wrote:
>> Hi Brett,
>> I'm going to start looking into the current toolchain work and see  
>> what we
>> can leverage. If the CompilerContext implementation can access the  
>> tool
>> chain, the context will be able to pass the path location of various
>> compilers off to the ClassCompiler implementation instances during
>> construction.
>> Regards,
>> Shane
>> On Dec 16, 2007 10:59 PM, Shane Isbell <>  
>> wrote:
>>> On Dec 16, 2007 9:38 PM, Brett Porter <> wrote:
>>>> Thanks for the thorough explanation.
>>>> Pardon my density, but I'm missing something fundamental - how will
>>>> NMaven work in any of the cases below at runtime, without a  
>>>> settings
>>>> file and capability matching, given that you are saying the IT test
>>>> might need some special handling to specify the implementation?
>>> I understand where your confusion comes from. If it works under x,  
>>> y, z
>>> configuration for builds, it should just require configuring x, y,  
>>> z for
>>> testing. I'm not saying that this can't be done by creating  
>>> scripts that
>>> modify systems path and environmental variables, what I am saying  
>>> that there
>>> may be an easier way that requires configuring components that we  
>>> can plug
>>> in to the framework. Both of these are just concepts with no
>>> grounding because right now it doesn't work for the runtime,  
>>> except in the
>>> simplest of cases: Microsoft/Mono .NET 2.0.  It's just tough to  
>>> say at
>>> this point how we want to handle IT tests under multiple platforms  
>>> until we
>>> get the first cut at the implementation.
>>> Shane
>>>> - Brett
>>>> On 17/12/2007, at 9:58 AM, Shane Isbell wrote:
>>>>> Hi Brett,
>>>>> The trunk integration tests are set up the same way as Maven and  
>>>>> my
>>>>> intention for the first release was just to test out the latest
>>>>> version of
>>>>> Mono using .NET 2.0, as well as Microsoft 2.0. This would involve
>>>> just
>>>>> changing the environment on a limited number of configurations.  
>>>>> Just
>>>>> to
>>>>> note, a simple changing out of the path will not completely work  
>>>>> on
>>>>> all
>>>>> configurations, as Mono contains csc.exe (for .NET 1.1) and  
>>>>> gmcs.exe
>>>>> (for
>>>>> .NET 2.0).  Microsoft, on the other hand, has the versions in
>>>>> different
>>>>> directories, which makes swapping out the paths easier. But you  
>>>>> have
>>>>> to keep
>>>>> in mind that for Microsoft .NET 3.0, the framework uses the same
>>>>> compiler as
>>>>> .NET 2.0, but a different one for 1.1 and 3.5. Configurations can
>>>>> get a
>>>>> little funky.
>>>>> If we were only dealing with Mono or only Microsoft, I would be  
>>>>> much
>>>>> more
>>>>> confident that would could pull off doing the IT setup exactly the
>>>>> same as
>>>>> Maven for all the needed configurations. I'm hoping that this is  
>>>>> the
>>>>> case.
>>>>> However, it's a little premature for me to have a good idea of how
>>>> the
>>>>> integration tests will work under multiple platforms now that we
>>>>> don't have
>>>>> capability matching.  Right now we have options of creating  
>>>>> scripts
>>>>> setting
>>>>> up the paths, with modifications for each permutation of
>>>>> installations.
>>>>> Another approach is something like the nmaven-settings file, which
>>>>> contains
>>>>> the parameters and lets some component handle the paths. One thing
>>>>> that I do
>>>>> like about a settings approach is that, on Windows, we can
>>>>> autogenerate the
>>>>> settings file by inspecting the registry, meaning we only test  
>>>>> what
>>>>> the
>>>>> platform is capable of testing. We'll need to open up that to  
>>>>> design
>>>>> and
>>>>> comments when we get to that point.
>>>>> If anyone on the list wants to take up on how IT testing should be
>>>>> done, go
>>>>> for it. The issue: has
>>>>> been out
>>>>> there a long time.
>>>>> As part of the IT testing, we will need to create a .NET assembly
>>>>> (or find a
>>>>> way to do it through Java) that handles the inspection of meta- 
>>>>> data
>>>>> within
>>>>> the project assembly. This is the only way to verify things like
>>>>> resource
>>>>> generation, signing of assemblies, proper dependencies/references,
>>>>> and so
>>>>> on. We may even be able to write this under the verifier.
>>>>> We haven't yet addressed within the compiler interface
>>>> implementation
>>>>> the specifying of framework version for Mono, so I have even  
>>>>> less of
>>>>> an idea
>>>>> of exactly how it will work with the IT tests.
>>>>> Shane
>>>>> On Dec 16, 2007 1:32 PM, Brett Porter <> wrote:
>>>>>> On 17/12/2007, at 8:19 AM, Shane Isbell wrote:
>>>>>>> I agree on all the points. Can you post a bug about what is
>>>>>>> breaking?
>>>>>> Will do.
>>>>>>> This was the original motivation for the nmaven-settings file.
>>>>>>> It
>>>>>>> allowed
>>>>>>> changing the platform configuration to replace vendors, vendor
>>>>>>> versions and
>>>>>>> framework versions. I think that the general nmaven-settings
>>>>>>> file
>>>>>>> concept is
>>>>>>> the right approach for integration testing, it should just be
>>>>>>> used
>>>>>>> for
>>>>>>> integration tests and should be non-obstrusive. This will likely
>>>>>>> require
>>>>>>> adding some component extensions that will allow modifying of
>>>>>>> the
>>>>>>> working
>>>>>>> directory of executables. This approach would avoid having to
>>>> bring
>>>>>>> in all
>>>>>>> the capability matching components to support it.
>>>>>> At this stage I would be happy with the integration tests just
>>>>>> running
>>>>>> under whatever the current execution environment is, like the
>>>> normal
>>>>>> NMaven execution would do. This is basically what the Maven  
>>>>>> ones do
>>>>>> for now, based on the version of Maven in the path. You then
>>>> switched
>>>>>> your execution environment and re-run the test suite. Some tests
>>>> are
>>>>>> excluded on environments they are not suitable for. The  
>>>>>> integration
>>>>>> test tools that are used for Maven should be able to be re-used 

>>>>>> in
>>>>>> NMaven.
>>>>>> Beyond that, I would just use whatever the toolchain capabilities
>>>> are
>>>>>> in Maven at the time to go towards the next step rather than  
>>>>>> adding
>>>>>> anything specific for it in either NMaven or the integration  
>>>>>> tests.
>>>>>> Is that in line with what you were thinking?
>>>>>> - Brett

View raw message