You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/03/29 18:00:17 UTC
[classlib] ant platform property definitions
Currently a number of the classlib ant files "normalize" operating
system and architecture names. Unfortunately they don't
really normalize them in the same way. ;-)
For instance, native-src/build.xml sets target.platform to
"linux.IA32" and modules/security/make/build.xml sets "platform.name"
to "lnx".
I think we should decide on a common normalized form and have a single
common ant file to import that defines them. I'd already started to
create one (as I was about to add platform defines in yet another ant
file) but then I realised there wasn't any consensus about what the
normalized form should be.
I think having a mapping (from os.arch to hy.arch and os.name and
hy.os) is useful because it reduces the coupling between Harmony and
ant, and because it enables use to perform sensible normalizations.
But, I don't think we should make the mapping unnecessarily
complicated. I think we should keep the normal form as close as
possible to the standard ant defines of os.name and os.arch.
So, ${hy.os} would be ${os.name} - with values like 'Linux',
'Solaris', etc. - except for Windows where we would normalize to
"Windows". Similarly, ${hy.arch} would be ${os.arch} - with values
like 'x86', 'x86_64', 'ia64', etc. I see no clear reasons for
exceptions to the ${hy.arch} at the moment, but we should create it
and use it consistently.
This would lead to "hy.platform" being defined as:
Linux.x86
Windows.x86
We could add exceptions - for instance, to make 'Linux' lower case -
but then we'd only need to add exceptions later for 'Solaris', 'Aix',
etc. I think we'd be better to avoid this and only have exceptions
where:
* the name contains characters that can't be used in file names, or
* there is a clear reason to normalize - e.g. "Windows XP", etc.
So, what do people think? Is there a compelling reason to maintain
the differences we have today - e.g. Linux in lowercase, 'ipf' rather
than 'ia64' - or can we just stick with the ant defines?
We also have many definitions of properties like "is.win",
"is.windows", and "if.win". I'd prefer to stick to forms starting
with 'is.' since I think they read better when used, e.g.
<target name="do-windows-stuff" if="is.windows">
...
</target>
and the item following the 'is.' prefix should be the all lowercase
(in line with typical conventions for ant properties) but otherwise
match the ${hy.os} and ${hy.arch} defines above.
Assuming we reach a consensus, I think directories should be renamed
to match the agreed definitions. We might as well change 'win.IA32'
to 'Windows/x86' - or whatever we decide on - while we are doing this.
I'll be happy to do the work to create the common ant file and to
submit a JIRA with any layout changes (I think there will be some
regardless of what decision is reach because of current differences).
Regards,
Mark.
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
Re: [classlib] ant platform property definitions
Posted by Geir Magnusson Jr <ge...@pobox.com>.
not all - just the ones from IBM, or IBM employees?
Even if not...
Is there any harm in this case in expanding it out?
geir
Mark Hindess wrote:
> It's has been in our ant builds for some time - in all the
> modules/*/make/build.xml files for instance. Does that mean we should
> continue to use it?
>
> -Mark.
>
> On 4/3/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>> Tim Ellison wrote:
>>> Geir Magnusson Jr wrote:
>>>> Along with everything everyone else has said...
>>>>
>>>> Yes, please, lets standardize. Get rid of caps as suggested and please,
>>>> lets not use "hy" and use "harmony". It isn't used in such high volume
>>>> that skipping the extra 5 characters isn't that big of a benefit, and it
>>>> makes things easy to read.
>>> It is used in high volume in our native code.
>> I'm not suggesting you change it, just not perpetuate the mistake ;)
>> into our ant builds.
>>
>> geir
>>
>>> Regards,
>>> Tim
>>>
>>>> Mark Hindess wrote:
>>>>> Currently a number of the classlib ant files "normalize" operating
>>>>> system and architecture names. Unfortunately they don't
>>>>> really normalize them in the same way. ;-)
>>>>>
>>>>> For instance, native-src/build.xml sets target.platform to
>>>>> "linux.IA32" and modules/security/make/build.xml sets "platform.name"
>>>>> to "lnx".
>>>>>
>>>>> I think we should decide on a common normalized form and have a single
>>>>> common ant file to import that defines them. I'd already started to
>>>>> create one (as I was about to add platform defines in yet another ant
>>>>> file) but then I realised there wasn't any consensus about what the
>>>>> normalized form should be.
>>>>>
>>>>> I think having a mapping (from os.arch to hy.arch and os.name and
>>>>> hy.os) is useful because it reduces the coupling between Harmony and
>>>>> ant, and because it enables use to perform sensible normalizations.
>>>>> But, I don't think we should make the mapping unnecessarily
>>>>> complicated. I think we should keep the normal form as close as
>>>>> possible to the standard ant defines of os.name and os.arch.
>>>>>
>>>>> So, ${hy.os} would be ${os.name} - with values like 'Linux',
>>>>> 'Solaris', etc. - except for Windows where we would normalize to
>>>>> "Windows". Similarly, ${hy.arch} would be ${os.arch} - with values
>>>>> like 'x86', 'x86_64', 'ia64', etc. I see no clear reasons for
>>>>> exceptions to the ${hy.arch} at the moment, but we should create it
>>>>> and use it consistently.
>>>> I hate "hy" with a real passion. Can we please use "harmony"? That's
>>>> the project name. IBM decided to use 'hy' as a prefix because it was
>>>> easier to type (reasonable, I guess...) but I think that it's not so bad
>>>> to use the full "harmony"
>>>>
>>>>
>>>>> This would lead to "hy.platform" being defined as:
>>>>>
>>>>> Linux.x86
>>>>> Windows.x86
>>>>>
>>>>> We could add exceptions - for instance, to make 'Linux' lower case -
>>>>> but then we'd only need to add exceptions later for 'Solaris', 'Aix',
>>>>> etc. I think we'd be better to avoid this and only have exceptions
>>>>> where:
>>>>>
>>>>> * the name contains characters that can't be used in file names, or
>>>>> * there is a clear reason to normalize - e.g. "Windows XP", etc.
>>>>>
>>>>> So, what do people think? Is there a compelling reason to maintain
>>>>> the differences we have today - e.g. Linux in lowercase, 'ipf' rather
>>>>> than 'ia64' - or can we just stick with the ant defines?
>>>>>
>>>>>
>>>>> We also have many definitions of properties like "is.win",
>>>>> "is.windows", and "if.win". I'd prefer to stick to forms starting
>>>>> with 'is.' since I think they read better when used, e.g.
>>>>>
>>>>> <target name="do-windows-stuff" if="is.windows">
>>>>> ...
>>>>> </target>
>>>>>
>>>>> and the item following the 'is.' prefix should be the all lowercase
>>>>> (in line with typical conventions for ant properties) but otherwise
>>>>> match the ${hy.os} and ${hy.arch} defines above.
>>>>>
>>>>> Assuming we reach a consensus, I think directories should be renamed
>>>>> to match the agreed definitions. We might as well change 'win.IA32'
>>>>> to 'Windows/x86' - or whatever we decide on - while we are doing this.
>>>>>
>>>>> I'll be happy to do the work to create the common ant file and to
>>>>> submit a JIRA with any layout changes (I think there will be some
>>>>> regardless of what decision is reach because of current differences).
>>>>>
>>>>> Regards,
>>>>> Mark.
>>>>>
>>>>> --
>>>>> Mark Hindess <ma...@googlemail.com>
>>>>> IBM Java Technology Centre, UK.
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
> --
> Mark Hindess <ma...@googlemail.com>
> IBM Java Technology Centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] ant platform property definitions
Posted by Mark Hindess <ma...@googlemail.com>.
It's has been in our ant builds for some time - in all the
modules/*/make/build.xml files for instance. Does that mean we should
continue to use it?
-Mark.
On 4/3/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Tim Ellison wrote:
> > Geir Magnusson Jr wrote:
> >> Along with everything everyone else has said...
> >>
> >> Yes, please, lets standardize. Get rid of caps as suggested and please,
> >> lets not use "hy" and use "harmony". It isn't used in such high volume
> >> that skipping the extra 5 characters isn't that big of a benefit, and it
> >> makes things easy to read.
> >
> > It is used in high volume in our native code.
>
> I'm not suggesting you change it, just not perpetuate the mistake ;)
> into our ant builds.
>
> geir
>
> >
> > Regards,
> > Tim
> >
> >> Mark Hindess wrote:
> >>> Currently a number of the classlib ant files "normalize" operating
> >>> system and architecture names. Unfortunately they don't
> >>> really normalize them in the same way. ;-)
> >>>
> >>> For instance, native-src/build.xml sets target.platform to
> >>> "linux.IA32" and modules/security/make/build.xml sets "platform.name"
> >>> to "lnx".
> >>>
> >>> I think we should decide on a common normalized form and have a single
> >>> common ant file to import that defines them. I'd already started to
> >>> create one (as I was about to add platform defines in yet another ant
> >>> file) but then I realised there wasn't any consensus about what the
> >>> normalized form should be.
> >>>
> >>> I think having a mapping (from os.arch to hy.arch and os.name and
> >>> hy.os) is useful because it reduces the coupling between Harmony and
> >>> ant, and because it enables use to perform sensible normalizations.
> >>> But, I don't think we should make the mapping unnecessarily
> >>> complicated. I think we should keep the normal form as close as
> >>> possible to the standard ant defines of os.name and os.arch.
> >>>
> >>> So, ${hy.os} would be ${os.name} - with values like 'Linux',
> >>> 'Solaris', etc. - except for Windows where we would normalize to
> >>> "Windows". Similarly, ${hy.arch} would be ${os.arch} - with values
> >>> like 'x86', 'x86_64', 'ia64', etc. I see no clear reasons for
> >>> exceptions to the ${hy.arch} at the moment, but we should create it
> >>> and use it consistently.
> >> I hate "hy" with a real passion. Can we please use "harmony"? That's
> >> the project name. IBM decided to use 'hy' as a prefix because it was
> >> easier to type (reasonable, I guess...) but I think that it's not so bad
> >> to use the full "harmony"
> >>
> >>
> >>> This would lead to "hy.platform" being defined as:
> >>>
> >>> Linux.x86
> >>> Windows.x86
> >>>
> >>> We could add exceptions - for instance, to make 'Linux' lower case -
> >>> but then we'd only need to add exceptions later for 'Solaris', 'Aix',
> >>> etc. I think we'd be better to avoid this and only have exceptions
> >>> where:
> >>>
> >>> * the name contains characters that can't be used in file names, or
> >>> * there is a clear reason to normalize - e.g. "Windows XP", etc.
> >>>
> >>> So, what do people think? Is there a compelling reason to maintain
> >>> the differences we have today - e.g. Linux in lowercase, 'ipf' rather
> >>> than 'ia64' - or can we just stick with the ant defines?
> >>>
> >>>
> >>> We also have many definitions of properties like "is.win",
> >>> "is.windows", and "if.win". I'd prefer to stick to forms starting
> >>> with 'is.' since I think they read better when used, e.g.
> >>>
> >>> <target name="do-windows-stuff" if="is.windows">
> >>> ...
> >>> </target>
> >>>
> >>> and the item following the 'is.' prefix should be the all lowercase
> >>> (in line with typical conventions for ant properties) but otherwise
> >>> match the ${hy.os} and ${hy.arch} defines above.
> >>>
> >>> Assuming we reach a consensus, I think directories should be renamed
> >>> to match the agreed definitions. We might as well change 'win.IA32'
> >>> to 'Windows/x86' - or whatever we decide on - while we are doing this.
> >>>
> >>> I'll be happy to do the work to create the common ant file and to
> >>> submit a JIRA with any layout changes (I think there will be some
> >>> regardless of what decision is reach because of current differences).
> >>>
> >>> Regards,
> >>> Mark.
> >>>
> >>> --
> >>> Mark Hindess <ma...@googlemail.com>
> >>> IBM Java Technology Centre, UK.
> >>>
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] ant platform property definitions
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>> Along with everything everyone else has said...
>>
>> Yes, please, lets standardize. Get rid of caps as suggested and please,
>> lets not use "hy" and use "harmony". It isn't used in such high volume
>> that skipping the extra 5 characters isn't that big of a benefit, and it
>> makes things easy to read.
>
> It is used in high volume in our native code.
I'm not suggesting you change it, just not perpetuate the mistake ;)
into our ant builds.
geir
>
> Regards,
> Tim
>
>> Mark Hindess wrote:
>>> Currently a number of the classlib ant files "normalize" operating
>>> system and architecture names. Unfortunately they don't
>>> really normalize them in the same way. ;-)
>>>
>>> For instance, native-src/build.xml sets target.platform to
>>> "linux.IA32" and modules/security/make/build.xml sets "platform.name"
>>> to "lnx".
>>>
>>> I think we should decide on a common normalized form and have a single
>>> common ant file to import that defines them. I'd already started to
>>> create one (as I was about to add platform defines in yet another ant
>>> file) but then I realised there wasn't any consensus about what the
>>> normalized form should be.
>>>
>>> I think having a mapping (from os.arch to hy.arch and os.name and
>>> hy.os) is useful because it reduces the coupling between Harmony and
>>> ant, and because it enables use to perform sensible normalizations.
>>> But, I don't think we should make the mapping unnecessarily
>>> complicated. I think we should keep the normal form as close as
>>> possible to the standard ant defines of os.name and os.arch.
>>>
>>> So, ${hy.os} would be ${os.name} - with values like 'Linux',
>>> 'Solaris', etc. - except for Windows where we would normalize to
>>> "Windows". Similarly, ${hy.arch} would be ${os.arch} - with values
>>> like 'x86', 'x86_64', 'ia64', etc. I see no clear reasons for
>>> exceptions to the ${hy.arch} at the moment, but we should create it
>>> and use it consistently.
>> I hate "hy" with a real passion. Can we please use "harmony"? That's
>> the project name. IBM decided to use 'hy' as a prefix because it was
>> easier to type (reasonable, I guess...) but I think that it's not so bad
>> to use the full "harmony"
>>
>>
>>> This would lead to "hy.platform" being defined as:
>>>
>>> Linux.x86
>>> Windows.x86
>>>
>>> We could add exceptions - for instance, to make 'Linux' lower case -
>>> but then we'd only need to add exceptions later for 'Solaris', 'Aix',
>>> etc. I think we'd be better to avoid this and only have exceptions
>>> where:
>>>
>>> * the name contains characters that can't be used in file names, or
>>> * there is a clear reason to normalize - e.g. "Windows XP", etc.
>>>
>>> So, what do people think? Is there a compelling reason to maintain
>>> the differences we have today - e.g. Linux in lowercase, 'ipf' rather
>>> than 'ia64' - or can we just stick with the ant defines?
>>>
>>>
>>> We also have many definitions of properties like "is.win",
>>> "is.windows", and "if.win". I'd prefer to stick to forms starting
>>> with 'is.' since I think they read better when used, e.g.
>>>
>>> <target name="do-windows-stuff" if="is.windows">
>>> ...
>>> </target>
>>>
>>> and the item following the 'is.' prefix should be the all lowercase
>>> (in line with typical conventions for ant properties) but otherwise
>>> match the ${hy.os} and ${hy.arch} defines above.
>>>
>>> Assuming we reach a consensus, I think directories should be renamed
>>> to match the agreed definitions. We might as well change 'win.IA32'
>>> to 'Windows/x86' - or whatever we decide on - while we are doing this.
>>>
>>> I'll be happy to do the work to create the common ant file and to
>>> submit a JIRA with any layout changes (I think there will be some
>>> regardless of what decision is reach because of current differences).
>>>
>>> Regards,
>>> Mark.
>>>
>>> --
>>> Mark Hindess <ma...@googlemail.com>
>>> IBM Java Technology Centre, UK.
>>>
>>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] ant platform property definitions
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> Along with everything everyone else has said...
>
> Yes, please, lets standardize. Get rid of caps as suggested and please,
> lets not use "hy" and use "harmony". It isn't used in such high volume
> that skipping the extra 5 characters isn't that big of a benefit, and it
> makes things easy to read.
It is used in high volume in our native code.
Regards,
Tim
> Mark Hindess wrote:
>> Currently a number of the classlib ant files "normalize" operating
>> system and architecture names. Unfortunately they don't
>> really normalize them in the same way. ;-)
>>
>> For instance, native-src/build.xml sets target.platform to
>> "linux.IA32" and modules/security/make/build.xml sets "platform.name"
>> to "lnx".
>>
>> I think we should decide on a common normalized form and have a single
>> common ant file to import that defines them. I'd already started to
>> create one (as I was about to add platform defines in yet another ant
>> file) but then I realised there wasn't any consensus about what the
>> normalized form should be.
>>
>> I think having a mapping (from os.arch to hy.arch and os.name and
>> hy.os) is useful because it reduces the coupling between Harmony and
>> ant, and because it enables use to perform sensible normalizations.
>> But, I don't think we should make the mapping unnecessarily
>> complicated. I think we should keep the normal form as close as
>> possible to the standard ant defines of os.name and os.arch.
>>
>> So, ${hy.os} would be ${os.name} - with values like 'Linux',
>> 'Solaris', etc. - except for Windows where we would normalize to
>> "Windows". Similarly, ${hy.arch} would be ${os.arch} - with values
>> like 'x86', 'x86_64', 'ia64', etc. I see no clear reasons for
>> exceptions to the ${hy.arch} at the moment, but we should create it
>> and use it consistently.
>
> I hate "hy" with a real passion. Can we please use "harmony"? That's
> the project name. IBM decided to use 'hy' as a prefix because it was
> easier to type (reasonable, I guess...) but I think that it's not so bad
> to use the full "harmony"
>
>
>>
>> This would lead to "hy.platform" being defined as:
>>
>> Linux.x86
>> Windows.x86
>>
>> We could add exceptions - for instance, to make 'Linux' lower case -
>> but then we'd only need to add exceptions later for 'Solaris', 'Aix',
>> etc. I think we'd be better to avoid this and only have exceptions
>> where:
>>
>> * the name contains characters that can't be used in file names, or
>> * there is a clear reason to normalize - e.g. "Windows XP", etc.
>>
>> So, what do people think? Is there a compelling reason to maintain
>> the differences we have today - e.g. Linux in lowercase, 'ipf' rather
>> than 'ia64' - or can we just stick with the ant defines?
>>
>>
>> We also have many definitions of properties like "is.win",
>> "is.windows", and "if.win". I'd prefer to stick to forms starting
>> with 'is.' since I think they read better when used, e.g.
>>
>> <target name="do-windows-stuff" if="is.windows">
>> ...
>> </target>
>>
>> and the item following the 'is.' prefix should be the all lowercase
>> (in line with typical conventions for ant properties) but otherwise
>> match the ${hy.os} and ${hy.arch} defines above.
>>
>> Assuming we reach a consensus, I think directories should be renamed
>> to match the agreed definitions. We might as well change 'win.IA32'
>> to 'Windows/x86' - or whatever we decide on - while we are doing this.
>>
>> I'll be happy to do the work to create the common ant file and to
>> submit a JIRA with any layout changes (I think there will be some
>> regardless of what decision is reach because of current differences).
>>
>> Regards,
>> Mark.
>>
>> --
>> Mark Hindess <ma...@googlemail.com>
>> IBM Java Technology Centre, UK.
>>
>>
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] ant platform property definitions
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Along with everything everyone else has said...
Yes, please, lets standardize. Get rid of caps as suggested and please,
lets not use "hy" and use "harmony". It isn't used in such high volume
that skipping the extra 5 characters isn't that big of a benefit, and it
makes things easy to read.
geir
Mark Hindess wrote:
> Currently a number of the classlib ant files "normalize" operating
> system and architecture names. Unfortunately they don't
> really normalize them in the same way. ;-)
>
> For instance, native-src/build.xml sets target.platform to
> "linux.IA32" and modules/security/make/build.xml sets "platform.name"
> to "lnx".
>
> I think we should decide on a common normalized form and have a single
> common ant file to import that defines them. I'd already started to
> create one (as I was about to add platform defines in yet another ant
> file) but then I realised there wasn't any consensus about what the
> normalized form should be.
>
> I think having a mapping (from os.arch to hy.arch and os.name and
> hy.os) is useful because it reduces the coupling between Harmony and
> ant, and because it enables use to perform sensible normalizations.
> But, I don't think we should make the mapping unnecessarily
> complicated. I think we should keep the normal form as close as
> possible to the standard ant defines of os.name and os.arch.
>
> So, ${hy.os} would be ${os.name} - with values like 'Linux',
> 'Solaris', etc. - except for Windows where we would normalize to
> "Windows". Similarly, ${hy.arch} would be ${os.arch} - with values
> like 'x86', 'x86_64', 'ia64', etc. I see no clear reasons for
> exceptions to the ${hy.arch} at the moment, but we should create it
> and use it consistently.
I hate "hy" with a real passion. Can we please use "harmony"? That's
the project name. IBM decided to use 'hy' as a prefix because it was
easier to type (reasonable, I guess...) but I think that it's not so bad
to use the full "harmony"
>
> This would lead to "hy.platform" being defined as:
>
> Linux.x86
> Windows.x86
>
> We could add exceptions - for instance, to make 'Linux' lower case -
> but then we'd only need to add exceptions later for 'Solaris', 'Aix',
> etc. I think we'd be better to avoid this and only have exceptions
> where:
>
> * the name contains characters that can't be used in file names, or
> * there is a clear reason to normalize - e.g. "Windows XP", etc.
>
> So, what do people think? Is there a compelling reason to maintain
> the differences we have today - e.g. Linux in lowercase, 'ipf' rather
> than 'ia64' - or can we just stick with the ant defines?
>
>
> We also have many definitions of properties like "is.win",
> "is.windows", and "if.win". I'd prefer to stick to forms starting
> with 'is.' since I think they read better when used, e.g.
>
> <target name="do-windows-stuff" if="is.windows">
> ...
> </target>
>
> and the item following the 'is.' prefix should be the all lowercase
> (in line with typical conventions for ant properties) but otherwise
> match the ${hy.os} and ${hy.arch} defines above.
>
> Assuming we reach a consensus, I think directories should be renamed
> to match the agreed definitions. We might as well change 'win.IA32'
> to 'Windows/x86' - or whatever we decide on - while we are doing this.
>
> I'll be happy to do the work to create the common ant file and to
> submit a JIRA with any layout changes (I think there will be some
> regardless of what decision is reach because of current differences).
>
> Regards,
> Mark.
>
> --
> Mark Hindess <ma...@googlemail.com>
> IBM Java Technology Centre, UK.
>
>