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 2007/12/16 20:47:14 UTC
platform independence for the build
Hi,
Given we have a fresh start - is it a reasonable expectation to be
able to build the entire package on any platform (including my Mac
with no .Net software install whatsoever)?
What I'm thinking of here:
* unit tests don't touch the .net/mono installation(s)
* maven-like integration test setup that can be executed for a single
nmaven version against a set of installed target platforms
* any platform specific builds in a profile (if we get back to plugins
or modules written in C#)
I'm not all that worried about the last one, but I would really like
to get the platform specifics out of the *unit* tests - should I just
go about filing issues and/or fixing these?
Currently, I get as far as: testInit_WithGacGenericAndMicrosoft (and
related tests).
- Brett
Re: platform independence for the build
Posted by Brett Porter <br...@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 <sh...@gmail.com> 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 <sh...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Dec 16, 2007 9:38 PM, Brett Porter <br...@apache.org> 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 <br...@apache.org> 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
>>>>>>
>>>>
>>>>
>>>
>>
Re: platform independence for the build
Posted by Shane Isbell <sh...@gmail.com>.
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 <sh...@gmail.com> 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 <sh...@gmail.com> wrote:
>
> >
> >
> > On Dec 16, 2007 9:38 PM, Brett Porter <br...@apache.org> 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 <br...@apache.org> 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
> > > >>
> > >
> > >
> >
>
Re: platform independence for the build
Posted by Shane Isbell <sh...@gmail.com>.
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 <sh...@gmail.com> wrote:
>
>
> On Dec 16, 2007 9:38 PM, Brett Porter <br...@apache.org> 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 <br...@apache.org> 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
> > >>
> >
> >
>
Re: platform independence for the build
Posted by Shane Isbell <sh...@gmail.com>.
On Dec 16, 2007 9:38 PM, Brett Porter <br...@apache.org> 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 <br...@apache.org> 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
> >>
>
>
Re: platform independence for the build
Posted by Brett Porter <br...@apache.org>.
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?
- 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 <br...@apache.org> 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
>>
Re: platform independence for the build
Posted by Shane Isbell <sh...@gmail.com>.
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 <br...@apache.org> 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
>
Re: platform independence for the build
Posted by Brett Porter <br...@apache.org>.
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
Re: platform independence for the build
Posted by Shane Isbell <sh...@gmail.com>.
I agree on all the points. Can you post a bug about what is breaking? I
added:
DotnetCompilerContextImpl.turnOffAssemblyExistsCheck();
DotnetCompilerContextImpl.turnOffCompilerExistsCheck();
That should have turned off any specific checks within the unit test that
would fail the compiler context initialization. It looks as though I missed
a check somewhere.
More comments in line
Thanks,
Shane
On Dec 16, 2007 12:47 PM, Brett Porter <br...@apache.org> wrote:
> Hi,
>
> Given we have a fresh start - is it a reasonable expectation to be
> able to build the entire package on any platform (including my Mac
> with no .Net software install whatsoever)?
>
> What I'm thinking of here:
> * unit tests don't touch the .net/mono installation(s)
> * maven-like integration test setup that can be executed for a single
> nmaven version against a set of installed target platforms
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.
>
> * any platform specific builds in a profile (if we get back to plugins
> or modules written in C#)
>
>
> I'm not all that worried about the last one, but I would really like
> to get the platform specifics out of the *unit* tests - should I just
> go about filing issues and/or fixing these?
>
> Currently, I get as far as: testInit_WithGacGenericAndMicrosoft (and
> related tests).
>
> - Brett
>