Chris,
On Sat, Mar 16, 2019 at 8:22 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Igal,
>
> On 3/15/19 22:38, Igal Sapir wrote:
> > Chris,
> >
> > On Fri, Mar 15, 2019 at 4:56 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >>
> >> Igal,
> >>
> >> On 3/15/19 16:45, Igal Sapir wrote:
> >>> <snip/> I looked deeper into build.xml and I found some
> >>> interesting information and a simple solution for my issue. In
> >>> build.xml we have the following:
> >>>
> >>> <property file="${user.home}/build.properties"/> <property
> >>> file="build.properties"/> <property
> >>> file="build.properties.default"/>
> >>>
> >>> So I can place my settings for test.threads in
> >>> ~/build.properties.
> >>>
> >>> The current order of precedence, however, gives
> >>> ${user.home}/build.properties a higher priority than the one
> >>> at {tomcat}/build.properties.
> >>>
> >>> That is wrong IMHO and should be the other way around, i.e.
> >>> {tomcat}/build.properties should
> >>> override${user.home}/build.properties . I would like to
> >>> change that order if everyone agrees.
> >>
> >> I do not agree. The local configuration (~/build.properties)
> >> should override the default configuration (build.properties).
> >> That's why it's called "local configuration".
> >>
> >> Besides, if you implement your proposed switch, then you will be
> >> UNABLE to use ~/build.properties to customize this configuration
> >> that you don't like.
> >>
> >
> > Perhaps I'm missing something, but I think that the term "Local"
> > is ambiguous here, so I will avoid using it to prevent confusion.
> > We have (applied in order):
> >
> > 1) Project Default Config.: {tomcat}/build.properties.default 2)
> > Instance Config........: {tomcat}/build.properties 3) System
> > Config..........: {user.home}/build.properties
> >
> > Tomcat only ships with the Project Default Config file. The other
> > two are optional and can be created by the user.
> >
> > Suppose that I usually want to run tests with 8 threads. I can
> > set `test.threads=8` in the System Config file and each time I
> > download a new version of Tomcat I simply run `ant test` in the
> > directory of that instance. It will run with 8 threads, resolving
> > my original issue here.
> >
> > But, if now I download a version and want to run only that one with
> > 4 threads (a more likely scenario would be to set different
> > versions or paths for OpenSSL), I can not simply set the new value
> > for the Instance Configuration, {tomcat}/build.properties, to
> > affect only that instance -- I have to modify the System Config,
> > which will change the settings for all other instances.
> >
> > The way I see it, the System Config is Default for the system, and
> > each instance should be able to specify its own Instance
> > Configuration which will override both the Project's Defaults and
> > the System Defaults. My proposal is therefore that the order of
> > applying the settings will be:
> >
> > 1) Project Default Config.: {tomcat}/build.properties.default 2)
> > System Config..........: {user.home}/build.properties 3) Instance
> > Config........: {tomcat}/build.properties
> >
> > That way I do not need to add an Instance Config anywhere unless a
> > specific instance requires unique settings. I can set my System
> > Config (~/build.properties) with the values that I normally use,
> > and only override them with an Instance Config, i.e.
> > {tomcat}/build.properties where needed.
> >
> > What am I missing?
>
> Just remember that ant properties are write-once, so all your orders
> above are backward. If you want the instance config to override all
> others, you'll have to load it first.
>
You are right. I tried to simplify my example with pseudo-config that has
a "last value wins", but that probably caused more confusion, so I'll try
to avoid that in the future.
>
> Nobody is going to agree on this, so maybe:
>
> {tomcat}/build.first.properties
> {user.home}/build.properties (which is a really weird default, IMO)
> {tomcat}/build.properties
> {tomcat}/build.default.properties
>
> This preserves the current behavior in all environments and allows you
> to have your new type of overriding configuration.
>
I don't think that I would use `build.first.properties` if I have to create
or copy it to the {tomcat} directory each time.
If anything, I would prefer to specify a path to a properties file, e.g.
`build.properties.file` or something like that, which will be read first.
That will allow me to have multiple properties file at the home directory,
and specify them as needed. For example, I could then add a file named
`{user.home}/build.properties.tomcat7` with Tomcat 7-specific settings in
it, and then point to it in ANT_OPTS for Tomcat 7 tests.
If I'm the only one who thinks that that would be useful then there's no
need to change anything. I can set a few properties that I usually use,
e.g. `test.threads` and `java.7.home`, in {user.home}/build.properties for
system-wide configuration, and modify or disable (by renaming) it seldomly
when needed.
Thanks,
Igal
>
> Making a change to the current behavior runs the risk of breaking all
> downstream projects, so let's not do that.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyNFLUACgkQHPApP6U8
> pFgByQ//S9oHh5vA2clnJw07M0LyDOu9MYh7i3N2Yiz0KneHwD1zN6K6IxmAk3Vl
> utyXEjJcJ8cZQ1dsgppUCKqDhqvXe+Ke+ySQ5es63mGY6CNlPMQnifca+CSEeJxA
> 9vLotQSeknnzOCR+h0xc0ICJAVUIhWDbc/YRdZV4iOf3/7oZ+N94QZz+1gKc6MVL
> 6yip6IVLs+3qgpemEDnGZS3NT9iSTlP4YsJ7DzhTkUqUkfPwEPJBkc8F+lywCAY/
> 47CGDL7mPulUQi1EJvG/N9KCNBWUjBQe+DX9gb2AQzPhysPwPjavNBoEXFNEBhM6
> 3nr1DlZaf91bNaW0EnVvaOxACAiIYvgDXnBLNISoRQURyvB4srH7Idmjp93vF+el
> 2N6/f8AUSAKODWyjWRVGf3fTJzoYejDgkDV8q3Ia23gTTLn8nZdohTTg1t59wpjH
> E6j0e0/z/CwHv/5Z+cj955MZzMoX8YNeH9540SZoIFADYTmSftugwvK6Itj1MHcF
> KGE0QjdBihJOvIBLB323mayCK03OufKgzFs03oA5OxZi8rYBZ9kz3Jv9EKcYHOLT
> qBNWM0INzwrUHFfhmXBo+Kdg4/DnHdszI2uResaqaOcUOzKMfdvOn+q4aMmnC4q5
> 6gmoa+hb+JnLYGdgxMtZ4Gzt5UWqLTHDYcghKT7wdZZ+v4Zj7nE=
> =qOG1
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
