DO NOT REPLY [Bug 16873] New: - Specifying a different latka.properties file

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16873>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16873

Specifying a different latka.properties file

           Summary: Specifying a different latka.properties file
           Product: Commons
           Version: 1.0 Alpha
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Latka
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: richard@dallaway.com


I'd like to be able to specify the values for variable substitutions on a
per-developer basis.

In deail...

When working with a team of developers I like to allow the developers the
freedom to configure their HTTP/app server how best suits them.  For Latka tests
this means changing the value for of latka.default.host in the expression:
defaultHost="${latka.default.host}"

We configure the setting for latka.default.host in latka.properties however this
could have a different value for different developers.  One developer might be
running localhost:80, another might be running localhost:8080, where as a
non-developer tester might want to default to a stanging/early-access/beta server.

Given that we have many common entries in our latka.properties file we keep
latka.properties in CVS.  A developer would have to change his or her local copy
of latka.properties BUT remember not to commit those changes, as one developer's
local configuration may not be workable for a different developer.

Off the top of my head there are a number of ways to make this cleaner.  One I
like is the following:
1.  Load latka.properties as normal
2.  If the VM has a
-Dorg.apache.commons.latka.user.properties=filename.properties set then ALSO
read those properties, over-riding any set in the global latka.properties file.

This would allow (1) backward compatibility with the current set up and (2)
allow a user to specify his or her own (local) latka.properties configuration.  

BTW, the current release includes a latka.properties in the .jar, which prevents
Latka from reading my own latak.properties file unless I'm careful with my
classpath.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org