richard, The best way to submit your changes would be to submit it as a patch to AndroMDA's patches on sourceforge. One of the AndroMDA developers can then have a look at it and merge it into the source tree.
At that point Matthias can decide whether to add you to the list of developers. At the moment he is on vacation and I have admin privledges, but I plan to use those right sparingly. I have been doing a poor job of keeping up on things. I just moved into a new apartment, and I am working someplace new, so my attention on AndroMDA has been less than I would otherwise like to give. So I cannot say for sure when I can do the merge. tony > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Richard > Kunze > Sent: Wednesday, June 04, 2003 4:24 AM > To: [EMAIL PROTECTED] > Subject: [Andromda-devel] Improved EJB cartridge > > > Hello all, > > I have been working on an improved EJB cartridge that provides > the following > features above the current EJB cartridge: > > - Support for inheritance: If an <<Entity>> or <<Service>> class extends > another class, this is reflected in the generated EJB. If the super class > itself is an <<Entity>> or <<Service>>, the generated *Bean extends the > *BeanInmpl of the super class. In all other cases, the generated *Bean > extends the given super class. > > - Support for arbitrary primary key types: If a <<Entity>> class > or any of its > super classes has a dependency that is stereotyped as <<PrimaryKey>>, the > provider of that dependency is used as the primary key type. If no such > dependency exists but the class (or a super class) has a field > stereotyped as > <<PrimaryKey>>, the type of this field is used as primary key type. If > neither a PK dependency nor a PK field is found, the primary key type > defaults to "java.lang.String" > > - Support for "abstract EJBs": If an <<Entity>> or <<Service>> is > declared > abstract in the model, the "@ejb.bean generate" attribute is set > to "false" > in the *Bean class. This means that XDoclet will generate home > and component > interfaces for this class, but no deployment descriptor entries. > > - Improved support for attributes: > - For attributes that are marked readonly, the setter method is > not exposed > to the component interface. > - Non-public attributes are not exposed to the component interface. > - Attributes marked as both static and read-only are treated as > constants. > For each constant, a getter method is created that returns the initial > value of the attribute as defined in the model. If the > constant is public, > the getter is exposed on both the home and component > interfaces (i.e. the > getter is marked as "@ejb.interface-method", and an additional > ejbHomeGet*() method is generated). If the constant is stereotyped as > <<EnvEntry>>, an corresponding "@ejb.env-entry" tag is > generated and the > getter returns the value of this entry > > - Improved support for relations: > - Relation names are constructed based on the model > - Relations of an abstract <<Entity>> are "inherited" by > all derived <<Entity>> classes: For every such relation, a > corresponding > get* method and "@ejb.relation" tag is generated in the derived *Bean > class. The only restriction is that the navigable target of a > relation must > may not be abstract. If it is abstract, the generator stops with an > exception. > > - Improved support for operations: > - Non-public operations methods are not exposed on the interfaces > - Operations declared as both public and static are interpreted as home > methods, i.e. the method name of the generated method is prefixed with > "ejbHome", and the method is marked as "@ejb.home-method" instead of > "@ejb.interface-method" > > The cartridge is alpha quality right now (mostly finished, seems > to work OK, > but not extensively tested yet) and I'd like to provide it to the > community > for evaluation. How's the best way to do that? Do I mail it to > the list (it's > not that big - ca 25K as a .jar archive), or is there a place where I can > upload the thing? > > The main thing that is still on my todo list is better support in > XDoclet for > the way AndroMDA handles autogenerated and "manual" code. More precisely, > XDoclet doesn't yet support picking up the XDoclet tags from the > *Bean class > when it is run on the *BeanImpl or *CMP class. > > Best regards, > > Richard > -- > Richard Kunze > > [ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg > Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1 > http://www.tivano.de, [EMAIL PROTECTED] > ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
