The M.E.T.A. plugin can operate in different modes. Currently it supports the following modes:
The goals of the M.E.T.A. plugin interact with many other goals from maven to create your build environment. As the function of some is not really intuitive, this is how the plugin is intended to be used:
Development cycle for java code =============================== [development start] | V maven turbine:setup - generate skeleton | V +-----> [application development] | | | V ^ maven java:compile - compile code | | | V +-<-- yes <--- Errors / Test failures? | | ^ | no | V | optional: maven turbine:deploy - deploy to container | (not needed in "inplace" mode) | | | V ^ [In-container testing] | | | V +-<-- yes <--- Errors? | | ^ | no | V +-<-- no <---- Ready to ship? | | yes V maven turbine:war - bind a war file | V Ship application
Development cycle for SQL code ============================== [development start] | V maven turbine:setup - generate skeleton | V maven torque:create-db - generate DB | V +-----> [application development] | | | V ^ maven turbine:sql - generate SQL code | | | V ^ maven torque:insert-sql - put SQL in DB | | | V +-<-- yes <--- Errors? | | ^ | no | V +-<-- no <---- Ready to ship? | | yes V Ship files from target/sql directory
If you have tried out the "helloworld" example from the Getting Started page, then you already know that setting up a new Turbine-based application is just a single maven command away. We will refer to this as "ad hoc" setup, because you do not need to prepare anything before running the turbine:setup goal.
Ad hoc setup is best used if you plan on doing lots of customization work to your properties anyway or if you just need a quick skeleton to test out something or jot down a few classes. You simply provide the application name on the maven command line and M.E.T.A. sets up the rest for you using the plugin defaults.
maven -Dturbine.app.name=<application name> turbine:setup
Note: In the subdirectory which contains your application skeleton, there will be a M.E.T.A. properties file, called setup.properties. This is auto-generated by the plugin to make your setup reproducible.
Sometimes, ad hoc simply will not cut the cake. Then you need to prepare a properties file for the M.E.T.A. plugin called setup.properties. It must be placed in the directory where you will run the turbine:setup goal. This properties file allows you to customize the layout of the new application.
You can change the name of the properties file with the turbine.setup.properties property:
maven -Dturbine.setup.properties=helloworld.properties turbine:setup
Turbine supports the retrieval of information from databases through
various OM layers. The most popular is Torque and Turbine itself uses
Torque for the Security
Service and the Scheduler
Service. With the M.E.T.A. plugin, different OM layers can be
configured. The default is to use Torque. The OM layer is configured
by setting the turbine.app.om.layer
property. Currently supported settings are:
In the "helloworld" example from the Getting Started page, you have seen that a newly generated turbine application already contains a few files which allow to check the correct setup. If you don't want M.E.T.A. to put these files into the skeleton, you can set the turbine.app.setup.demo property to false:
maven -Dturbine.app.setup.demo=false turbine:setup
Application development happens in cycles of programming, compile and
deploy. If you use an external web container, you deploy your compiled
application into its
webapp directory. If you have a
local web container that you can customize, you might want to develop
directly in the
webapp directory and skip the
All your application code and Turbine support files are copied into a web container which is outside your development tree. You must configure the appserver plugin (which also gives you the power to start and stop your container from maven. See the appserver plugin documentation for more information) and its configuration is then used by M.E.T.A. The required appserver properties are listed on the Properties Page.