harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: [classlib] debug compilation as default
Date Mon, 17 Jul 2006 14:55:35 GMT
+1 for property files.
The one of the main benefits for me is the possibility to define all
the needed properties just once. But not execute a huge number of "set
SMTH" and "set ANOTHERTHING" each time I open a new window or reboot
my machine.

That's why it is better to get proxy info from property file instead
of setting ANT_OPTS variable :)
http://issues.apache.org/jira/browse/HARMONY-523

SY, Alexey

2006/7/17, Geir Magnusson Jr <geir@pobox.com>:
>
>
> Salikh Zakirov wrote:
> > Mark Hindess wrote:
> >> I'll let Geir speak for himself, but I think he was alluding to the use
> >> of a user properties file:
> >>
> >>   <property file="${user.home}/.harmony.properties" />
> >>
> >> that would *not* be checked in and would be read (if it existed or
> >> ignored otherwise).
> >>
> >> Which is exactly what you can achieve in a platform-independent way with
> >> a property file as described above.
> >
> > This solution is okay with me.
>
> That's not a solution.  It's what people do to personalize.  I'm
> targeted at normalizing how we handle configuration properties.
>
> >
> >>> And by the way, the solution to run 'HY_CFG=xyz ant' with
> >>> corresponding
> >>>     <property environment="env"/>
> >>>     <condition property='hy.cfg' value='${env.HY_CFG}'>
> >>>        <isset property="env.HY_CFG"/>
> >>>     </condition>
> >>> worked perfectly for the DRLVM builds on Windows. What's more,
> >>> it is *compatible* with 'ant -Dhy.cfg=...' syntax.
> >>>
> >>> I have not heard any specific concerns why this can't be used.
> >> Read the list archive.  Environment variables are platform-specific and
> >> differ - if they exist - from platform to platform.  Windows for example
> >> treats environment variable names as case-insensitive but when ant reads
> >> them from env.VaR you must get the case exactly right.  Ant properties
> >> are platform-independent and so will work the same everywhere.
> >
> > I have read the discussion, and still consider this as non-issue,
> > because anyone can be careful enough to define the name in correct case.
> > (So one must define the variable in proper case as HY_CFG even on Windows)
>
> The point is that we want to reduce the number of places that things can
> get broken...
>
> >
> > In my practice, environment variables worked fine on Windows.
> >
> > And I have not heard a single report on how environment variables failed in real
life.
> > I have only seen discussion how this *may* fail if the user is not careful enough
> > to do precisely what is written in instruction.
> >
> > Still unconvinced why we can't allow careful users to use environment
> > variables for configuration.
>
> because as a matter of engineering practice, you want to reduce the
> number of places that errors can happen, and increase the amount of
> easily reusable configuration.
>
> Notice how you keep saying "can be careful enough" or "allow careful
> users"....
>
> We can make it easier to work with Harmony, I believe, by removing the
> 'extra care' requirement when possible.
>
> geir
>
> ---------------------------------------------------------------------
> 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
>
>


-- 
Alexey A. Petrenko
Intel Middleware Products Division

---------------------------------------------------------------------
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


Mime
View raw message