Allow environment specific scripts.

[GoogleCodeExporter]

What version of the MyBatis are you using?
3.0.1.GA

Please describe the problem.  Unit tests are best!
I have specific bootstrap scripts that need to be loaded differently for 
different environments

What is the expected output? What do you see instead?
I would like to see scripts support sub-directories with that match the names 
of the environments that can contain their own specific bootstrapping/migration 
scripts

Please provide any additional information below.

Original issue reported on code.google.com by chengt on 10 Aug 2010 at 5:26

[GoogleCodeExporter]

I have no idea how to change the component or the type using this trading tool

Original comment by chengt on 10 Aug 2010 at 5:27

[GoogleCodeExporter]

Please for this kind of questions use the users mailing list before opening any 
issue, it would reduce the time of replying and discuss issues with the team 
accelerate the development time, if required.

In your case it would be better - best practices suggest, but take this as just 
a suggestion - include your environmental info in the build process, rather 
than during the startup. Can you imagine what could happen if you release a 
package that, for some reason, in the production environment would started with 
the test profile? Or during the development you install the test application 
but launching it with the production profile?

If you're using Maven, I suggest you to take a look at how you can profile your 
applications[1]. If you're using different tools, you can simply apply the same 
principle.

[1] http://maven.apache.org/guides/introduction/introduction-to-profiles.html

Original comment by simone.t...@gmail.com on 13 Aug 2010 at 7:06

• Changed state: WontFix

[GoogleCodeExporter]

I've well aware of maven profiles. But I don't understand your argument.
The same 'dangers' that you mentioned could happen even now with that 
migrations work.
How is this any more or less safe?
The point of this is a convenience to developers/integrators when having to 
setup specific environments.
It could even be helpful to setup different types of environments all at the 
same level (for example multiple dbs for different apps all in production) with 
less duplication than what currently is available. especially when combined 
with request #80

Original comment by chengt on 14 Aug 2010 at 5:22