From nmaven-dev-return-520-apmail-incubator-nmaven-dev-archive=incubator.apache.org@incubator.apache.org Thu Dec 20 01:55:46 2007 Return-Path: Delivered-To: apmail-incubator-nmaven-dev-archive@locus.apache.org Received: (qmail 81458 invoked from network); 20 Dec 2007 01:55:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Dec 2007 01:55:46 -0000 Received: (qmail 2712 invoked by uid 500); 20 Dec 2007 01:55:35 -0000 Delivered-To: apmail-incubator-nmaven-dev-archive@incubator.apache.org Received: (qmail 2690 invoked by uid 500); 20 Dec 2007 01:55:35 -0000 Mailing-List: contact nmaven-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: nmaven-dev@incubator.apache.org Delivered-To: mailing list nmaven-dev@incubator.apache.org Received: (qmail 2681 invoked by uid 99); 20 Dec 2007 01:55:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Dec 2007 17:55:34 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [210.50.30.235] (HELO mx05.syd.iprimus.net.au) (210.50.30.235) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Dec 2007 01:55:12 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEJaaUc6sl2d/2dsb2JhbAAIqi8 X-IronPort-AV: E=Sophos;i="4.24,186,1196600400"; d="scan'208";a="84820614" Received: from 157.191.dsl.syd.iprimus.net.au (HELO [192.168.237.213]) ([58.178.93.157]) by smtp05.syd.iprimus.net.au with ESMTP; 20 Dec 2007 12:55:11 +1100 Message-Id: <183D93A6-31B2-48C0-8441-9A1777D3E03D@apache.org> From: Brett Porter To: nmaven-dev@incubator.apache.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: platform independence for the build Date: Thu, 20 Dec 2007 12:54:55 +1100 References: <6107C17E-8FC9-4B79-B555-DAE83883C9F7@apache.org> X-Mailer: Apple Mail (2.915) X-Virus-Checked: Checked by ClamAV on apache.org 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: http://jira.codehaus.org/browse/NMAVEN-14 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 >>>>>> >>>> >>>> >>> >>