Bug 779948 (SOA-2308)

Parent: Added: SOA-2271

This needs more consideration.  In summary, the schema script changes the
database for all the components that use a database, and it makes them all
use the same database.  However, this is too restrictive for ModeShape, which
will normally use multiple data sources.  Also, some ModeShape data sources
(non-database ones) make no sense for the other components.

ModeShape will likely be configured in SOA-P to have a single repository that uses a single database. That will be sufficient out-of-the-box; changes can be made to that by customers if needed, but more likely they will leave the configuration for that repository alone (and maybe add other repositories). So the tool could definitely manipulate the specific fragment in the ModeShape configuration file that corresponds to this out-of-the-box repository source.

The question is whether the ModeShape repository content should be stored in the same database with other data. (I don't know what that other data entails, so it certainly might make sense.) All of the tables in the ModeShape schema should start with "MODE_" or "DNA_" (for legacy reasons), but I'm not sure whether our index names use a prefix. Hopefully there won't be a name conflict with other tables in the shared database.

ModeShape does come with an executable JAR that will generate the DDL script for a particular database, if that's required or useful. (See http://docs.jboss.org/modeshape/latest/manuals/reference/html_single/reference-guide-en.html#jdbc-storage-connector for details.)

To use the schema tool to update modeshape repository appears to be complex, because the modeshape config file can be updated by users (adding other repositories) and therefore a template can't be used to replace the database properties (as is done with the others).   We could build a complex UI so the user can choose what to replace (the most flexible) or use the schema tool to only replace the config when only 1 repository is defined.   If more then one exist, then alternative  (manual)  measures must be taken by the user.

Parent: Removed: SOA-2271 

Link: Added: This issue is duplicated by SOA-2398

First step is to change the DB schema  templates to have a substitution variable:   @JNIDNAME@  that will be substituted for when tool is run.    Doing this will allow modeshape to reuse the templates to create its -ds.xml file that have its defined JNDI name.

Committed changes so that the modeshape-eds-store-ds.xml will be replaced with new settings that were applied to the template.

Changes were applied to the soa build project and should be in the ER5 release.

DataSource is reconfigured but modeshape-config.xml file still contains incorrect dialect configuration - like mode:dialect="org.hibernate.dialect.HSQLDialect

This could be problematic, because the config file can't templetized because we can't be sure what the user has already changed.   They now could have multiple sources that use HSQLDialect.   Do we, by default, change all occurrences?   Maybe, when the db schema tool is run, and modeshape is determined to be deployed, we add a prompt telling the user that they will need to update the config file with this "DIALECT".    Suggestions?

I'd say modify the file in that way that only dialect for eds-store JpaSource is modified, rest is untouched.

Added logic to replace the dialect for the eds-store in the modeshape-config.xml

The db schema-tool has be fixed to update the appropriate files (i.e., config file and -ds.xml) so that all references are updated accordingly.