<dependency>
<groupId>andromda</groupId>
<artifactId>andromda-java-cartridge</artifactId>
<version>${andromda.version}</version>
<type>jar</type>
<properties>
<cartridge-area>
<model uri='${maven.andromda.model.uri.1}' all='false'> <!-- all is default true and than cartridge concerns all elements in model -->
<package name='foo' all='false'> <!-- all is default true and than cartridge concerns all elements in package foo (only if all for model was false) -->
<element name='User'/> <!-- concerns elements with some name (usually one element) -->
<element stereotype='Service'> <!-- concerns elements with some stereotype (usually many elements -->
<services>${maven.andromda.java.generated.dir}</services> <!-- outlet can be child of either <model> or <package> or <element> -->
<service-impls.ignore/>
<value-objects>${maven.andromda.common.generated.dir}</value-objects>
<exceptions.ignore/>
<enumerations>${maven.andromda.common.generated.dir}</enumerations>
</package> </model>
<model uri='${maven.andromda.model.uri.2}' all='false'>
...
</model>
</cartridge-area>
</properties>
</dependency>
Such possibility + outles give you chance to manage entire project in one xmi file (if you only want it). I describe my project as example. I use java + hibernate + spring + webservice cartridges. My application is distributed (I need cellular phone client). I could use such configuration:
- java cartridge
- first <model uri="..." all="false"> element is not for entire model, <package name="foo.notdistributed"> element is only for package foo.notdistributed and generates <value-objects> to subproject common,
- second <model uri="..." all="false"> element is not for entire model, <package name="foo.distributed"> element is for package foo.distributed and generates <value-objects> to subproject common-dist. It use i.e. parameter j2me <parameter j2me="true"/> and than java cartridge instead java.util.Collection uses java.util.Vector and does not use java.util.Serializable. My midp subproject has dependency on common-dist.jar and not common.jar (the second one generates error).
- hibernate cartridge is for entire model (does not generate Factory classes - this is easy to enable - <factories.ignore/>) and generates entities + hibernate mapping files
- spring cartidge <model> element is for entire project and generates daos (without entites which has generated hibernate cartridge - it easy to enable too - <entities.ignore> and <entity-impls.ignore/>) + service implementations
- webservice cartridge <model uri="..." all="false"> element is not for entire model, <package name="foo.distributed"> element is only for package foo.distributed
I think such solution is powerful (you can solve more complicated problems with project configuration than in my project) and not too complicated. You can use the same stereotype name in many cartridges (i.e. "Service") without collisions. If you develop cartridge you can give users some examples, how they can use it with other cartridges.
regards Tomek
these days, Christian Seiler asked a question about stereotype collisions in the Java cartridge. He wanted to generate Java interfaces from UML models (using the <<Service>> stereotype) and did not want that the code generation of services by other cartridges was triggered. However, he wanted to make that decision on a class by class basis.
My question today: I can imagine that this is a common case: A user wants services generated with a certain flavor (EJB, Hibernate or
Spring) and *additionally* wants simple Java interfaces and their implementations, possibly using another stereotype. So, wouldn't it be good if we used another stereotype in the Java cartridge?
I know this question is critical because changing the stereotype would possibly render old models temporarily unusable.
What do you think?
You could also leave the service stereotype as it is and add new stereotypes for modelling simple interfaces and classes. The interface stereotype doesn't even need to create any implementation classes (in contrast to the service stereotype). This doesn't break any existing models.
Additionally (but this is a different feature) it could still make sense to be able to address cartridges on a class base, e.g. by using some tagged values
@andromda.core.cartridge.exclude=Spring and/or @andromda.core.cartridge.include=Java
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Andromda-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/andromda-user
------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Andromda-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-user
