This content has been marked as final.
Show 3 replies
-
1. Re: db properties reorg
heiko.braun Feb 4, 2009 5:31 AM (in response to tom.baeyens)
Ideally i would like to move to the following situation:
* a config module that has the default persistence configuration and produces it in a jar file in the repo.
right, that something we agree upon. Just that the current configuration resides with the jpdl module which produces a a config jar that goes into the repo: jbpm-jpdl-4.0.0-SNAPSHOT-config.jar
Another requirement is to switch between hibernate managed connections (simple tests, jdbc properties) to container managed connections (intgeration tests, datasources). This is something we already did in jBPM3
and I simply wanted to leverage the existing build, which is non trivial.
Hence the change from hibnerate.cfg.xml+hibernate.properties to a single hibernate.cfg.xml which includes the connection settings.
So basically, the db.properties (i.e. mysql.properties) disappeared and have been replaced by hibernate.mysql.cfg.xml, which ship with the jpdl-config.jar.
Currently this get's expanded into every module that needs db connection settings and is used by the installer to finally create hibernate.cfg.xml and *-ds.xml for deployment into the AS.
The build is driven by profiles.xml which contains the connection properties (i.e. Qa on your local box vs. jboss QA environment) and by the 'mvn -Ddatabase=mysql' switch, that defaults to hsqldb.
Does that answer your question? -
2. Re: db properties reorg
tom.baeyens Feb 4, 2009 6:41 AM (in response to tom.baeyens)"heiko.braun@jboss.com" wrote:
Another requirement is to switch between hibernate managed connections (simple tests, jdbc properties) to container managed connections (intgeration tests, datasources).
that was the use case what i forgot
i don't like the current set up yet. i got the feeling that it must be possible to make it less complex.
but i'll give it some time to get used to it and then see where and how (if at all) things need to be improved.
one thing that i haven't figured out yet is the configuration variation for the pvm tests. in the pvm, we need a jbpm.cfg.xml which is almost as the full configuration file, but it should exclude the jpdl things (only one or two things).
i'm still chewing on how we can get to one unified configuration source for all modules... not trivial. -
3. Re: db properties reorg
heiko.braun Feb 4, 2009 6:51 AM (in response to tom.baeyens)
i'm still chewing on how we can get to one unified configuration source for all modules... not trivial.
We got that already, but maybe I don't understand you correctly.
What do you see missing?
i got the feeling that it must be possible to make it less complex.
complexity doesn't matter at build time. it aims at automation anyway.
but it's complex, I agree. Hence the reason to leverage the experience and build constructs that thomas introduced in jbpm3. Remember that there is already 6 month work in it and a lot under the covers that is not obvious at a first glance.