incubator-nmaven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shane Isbell" <shane.isb...@gmail.com>
Subject Re: platform independence for the build
Date Mon, 17 Dec 2007 21:19:16 GMT
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 <shane.isbell@gmail.com> wrote:

>
>
>  On Dec 16, 2007 9:38 PM, Brett Porter <brett@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 <brett@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
> > >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message