Wait a minute....src/test/resources contains jdbc.properties
jdbc.driverClassName=${jdbc.driverClassName}
jdbc.url=${jdbc.url}
jdbc.username=${jdbc.username}
jdbc.password=${jdbc.password}
hibernate.dialect=${hibernate.dialect}
# Needed by Hibernate3 Maven Plugin defined in pom.xml
hibernate.connection.username=${jdbc.username}
hibernate.connection.password=${jdbc.password}
hibernate.connection.url=${jdbc.url}
hibernate.connection.driver_class=${jdbc.driverClassName}
I guess I will just introduce new parameters like jdbc.test.username and use
them here. Great :)
jimpo wrote:
>
> And have two installations of my application server - server A with
> datasourceX => unit test db - and server B with datasourceX => the other
> db? And run the tests by deploying the war to server A and the actual
> deployment to server B? Right?
>
> That's probably one good way to do it - what if you want to keep your
> database connections configured inside your application and not use server
> datasource - can you think of a solution for that?
>
>
> Mike Horwitz wrote:
>>
>> The easiest way to do this is to configure the database connection as
>> part
>> of the container (as a JNDI resource) rather than embed it in the war
>> file.
>> In applicationContext-resources.xml uncomment the JNDI lookup and comment
>> out the datasource.
>>
>> Mike.
>>
>> On 10/26/07, jimpo <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>> *bump* this one because I think a question still remains unanswered.
>>>
>>> There is a need for have a) unit tests run against database settings 1
>>> (populated by dbUnit) and b) the real application deployment war run
>>> against
>>> a different database settings 2
>>>
>>> The whole point of dbUnit is to run against a different database,
>>> dedicated
>>> to unit testing.
>>>
>>> However I can't figure out how to do a mvn install, so that unit tests
>>> are
>>> run against a different db than the final war. There must be a way to do
>>> this?
>>>
>>>
>>>
>>>
>>> Joachim Ansorg-3 wrote:
>>> >
>>> > Hi Rob,
>>> > thanks for the second reply.
>>> >>> Did you solve that problem somehow or do you just skip the tests in
>>> >>> env-dev?
>>> >>>
>>> >>
>>> >> That's evidently by design. For tests to work reliably they have to
>>> have
>>> >> the
>>> >> DB in a known state.
>>> >>
>>> >>
>>> > I assumed that, too. So I've tried to configure appfuse to use a
>>> > different database for the tests, i.e. src/main should use db1 and
>>> > src/test/ should use db2. So that the main app and the tests are
>>> > independent from each other.
>>> > But since I failed I will follow your approach.
>>> > And profiles are a good idea, anyway.
>>> >
>>> > Thanks again,
>>> > Joachim
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> > For additional commands, e-mail: [EMAIL PROTECTED]
>>> >
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/cargo-maven2-plugin%3A-Configuration-for-seperate-test-database--tf4677233s2369.html#a13425371
>>> Sent from the AppFuse - User mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/cargo-maven2-plugin%3A-Configuration-for-seperate-test-database--tf4677233s2369.html#a13426575
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
