I think that you might be falling victim to a fundamental problem with unit test design. Unit tests should really not be connecting to the database at all. If possible, they should be mocked out entirely, or at worst, simulated with an in-memory database such as HSQLDB.
If you absolutely need to do so, then you're going to have to abide by open and plain-text passwords being visible, or you'll have to do more creative things like setting up some authentication scheme with LDAP and variable configurations. As a minimal workaround, you can always use maven variables in your pom.xml files to specify db connections for the tests, and set those variables in your build user's settings.xml file. The settings.xml file should be inaccessible to everyone but root and the build user in question, and you would never see the actual passwords in anything that could be accessed by continuum. Regardless, providing a database connection to an otherwise secure database server weakens its security to the level of security of the build user, so you need to either deal with that as it is, or find alternatives to the database connection. An alternative is to set up a local, minimal copy of the database sufficient to run tests (i.e. no customer data, but all reference data present with all necessary reference data). This way there's no security downside to providing connection to the build user, because it's not a system with any protected content. All sample data is realistic, but not real. Regards, Christian. christian gruber + agile coach and architect Israfil Consulting Services Corporation email [EMAIL PROTECTED] + bus +1 (905) 640-1119 cell: +1 (416) 998-6023 + cell: +1 (410) 900-0796 -----Original Message----- From: Shute, James [mailto:[EMAIL PROTECTED] Sent: Friday, August 11, 2006 11:47 AM To: Continuum Users Subject: DB connection details Hi, I've got a Maven1 project building under Continuum, but now have some unit tests that need to connect to a database. When I just run the tests on my box via Maven then I leave the username / password blank so it uses the integrated security and picks up the username / password of the current user, which is great and works nicely. But when running under Continuum this doesn't work as the account it's running as doesn't have DB access. Now due to various audit / security policies in place here giving that account access to the db isn't an option. Now the only working solution I've come up with so far is to specify system properties on the command line which give the username and password. These can then be specified in the arguments section on the project build definition page in Continuum. BUT. Those values are publicly viewable, i.e. everybody can see the password and I'm not exactly keen on that. Access to the build box is more restricted so a solution based on a local file there would be better (even if the password has to be stored as plain text) Anybody got any suggestions? I would just put the properties in the local build.properties file for the project on the build box, but that gets blown away by the CVS update. thanks James ---------------------------------------------------------------------------- -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.