Incremental development and regeneration cycles are supported by AndroMDA
For classes this is not a problem, abstract parent classes are regenerated, the child
classes are only generated when they do not yet exist, so you will put your custom code in
there and you are sure it will stay there, worst case you'll have compilation
errors when building your project
Jsps, properties files, etc... are a different story because the notion of extending one another
does not exist. Tackling this problem is not so easy as with classes. Anyway, it is partially
supported. For the Bpm4Struts cartridge JSPs will be using Tiles to separate as much as possible
those parts that need update and those that don't need update. The cartridge also generates CSS
stylesheets, i18n properties files, etc.. subsequently making it easier to identify which files
would need manual update
what most users will do anyway is fine-tune the templates to their needs, they are quite easy to
read and are written in Velocity (any other template-engine can easily be supported), and in
doing so the generated files will be customized to your very needs.
The purpose of AndroMDA is not to generate your complete application with the click of a button,
maybe that will be possible in the future :-) but not yet for now. If you are tired of writing the same
code all the time, updating XDoclet tags, etc... and you want to keep focus on
the business, AndroMDA is for you.
For users not familiar with AndroMDA, here's an approximation of the percentage of code generated:
- Persistence (EJB/Hibernate): 100%
- Business (EJB): 30%
- WebServices (Axis): 100%
- Presentation (Struts): 80%
The presentation layer is taken care of.
The business layer needs an implementation since this is (or at least should be) unique for each
different application.
The presentation will also run out-of-the-box but you'll still need to wire it to the business
layer. The web application can be deployed and run without it though, be it with a 'dummy'
implementation behind.
Since each layer is cleanly separated each one of them can be developed and tested independently
before linking them together.
[top]
Yes, both Maven as well as Ant have a property enabling you to point to a
log4j XML configuration file. The default
configuration file used can be found in the andromda-core-XXX.jar artifact. Open
this jar file and go into the /org/andromda/core/common directory, you will see the
log4j.xml file there. Copy it to an external location, edit it and point to it
using the property.
Maven users specify maven.andromda.loggingConfigurationUri in their
project.properties file, Ant users use the loggingConfigurationUri
property in their build.xml. The location of the log4j.xmlfile
must be preceeded by the file: prefix. Here's an example:
maven.andromda.loggingConfigurationUri=file:${logging.cfg.dir}/my-log4j.xml
[top]
