Skip to end of metadata
Go to start of metadata

Fornax Hibernate Cartridge

The latest releases is 1.10.0

Download the versions from SourceForge.net
Version 2.0.0 of the Fornax Hibernate Cartridge will be based on Xpand 1.0 and MWE (oAW5).

Overview

This Cartridge is based on openArchitectureWare 4.3.1 and provides templates and stereotypes for generating entities and Hibernate O/R mappings and configuration.

UML2 is used for modeling your domain. Every modeling tool which can export to EMF UML2 is supported. Just model your domain, export the model and start the generation.

Most of Hibernate's customizing facilitities are supported. Additionally, legacy databases with composite-key and key-references are supported.

The entities are generated by the JavaBasic Cartridge. The generated artifacts consist of three parts for each modeled entity:

  1. An interface, placed into a seperate physical location.
  2. A JavaBean containing all properties and associations with customizable generations of equals() , hashcode() and toString(). This class is completely generated by the Fornax Hibernate Cartridge.
  3. A super class of the JavaBean used for customization with manually written code

Features

Benefit from a simple "out of the box" cartridge, that is highly customizable!

  • Generation of JavaBeans and Hibernate Mappings from a simple UML model
  • Beautiful code using code formatter
    • Fornax XML Formatter
    • Hybridlabs Java Beautifier
  • Inheritance** Table per class hierarchy subclass** Table per subclass joined-subclass** Table per concrete class union-subclass
  • (JPA-) embedded
  • Natural keys and automatic generation of toString(), hashcode() and equals()
  • Java 5, i.e. typed Collections
  • Completion of models with default values (via model transformations)
    • naming unnamed association ends
    • providing default keys
  • many customizing facilities like:
    • customizing Hibernate-specific properties
    • customizing the names of tables and columns with:
      • prefix
      • (name | name.toUpperCase | name.toLowerCase)
      • suffix
  • Support for legacy databases
    • composite keys
    • key references

Uses latest technologies:

  • Hibernate version 3.2.6 GA
  • oAW 4.3.1
  • JavaBasic Cartridge 2.1.0
  • planned: Hibernate Annotations

Documentation

Issues and improvements

Issues, bugs, and feature requests should be submitted to the following issue tracking system for this project:

http://www.fornax-platform.org/tracker/browse/CHB.

Use the forum for questions and discussion.


Powered by itemis and NoMagic

Unknown macro: {rating}
  • No labels
  1. Anonymous

    Looks great!

    attila

  2. Thanks! Were you able to test it successfully?

    Darius will now make the initial release, hopefully on Friday. After that he will provide some documentation. 

  3. The Cartridge works fine. With the tutorial it should be no problem to run it succesfully. Feel free to try out (smile)

  4. Anonymous

    Does it work with hibernate annotations in java 1.5

    1. A first, rudimental, support is implemented. Comprehensive support is planned, but there is no volunteer to do this job (smile)

      1. Anonymous

        The JAVA 1.5 has some problems. The pojo-File do use an import directive, that points to a package and not a class, that -in turn- cause a compile error. Anyway you have to work over the generated work after creation.

        Another question: Where can i configure, that the cardrigde only creaes Java1.4 code?

        1. Hello,

          The JAVA 1.5 has some problems. The pojo-File do use an import directive, that points to a package and not a class, that -in turn- cause a compile error. Anyway you have to work over the generated work after creation.

          We worked over some 1.5 issues. Please try again. The generator should always produce compilable code.

          Another question: Where can i configure, that the cardrigde only creaes Java1.4 code?

           If you set the property

          then no generics are generated.

          Please try the forum for further questions.

           Regards

          Darius

  5. Anonymous

    The cardrige has a nasty bug, when you model a 1:1 relationsship between two table, with a bidirectional navigation. The Problem is, that this relationship is translated into three(!) tables. Two of them are derived by the both UML-classes, which is correct. The third table is a assoc-table, that your be useful for n:m cardinality relationships, but not 1:1.

    Another thing that looks strange is the use of columnames for 1:1 relationsships. For an 1:1 relationsship the generator uses as a columname the name of the association table, that looks like:  LINK_<table1>_<table2>.  This will end up in columnsames that are too long.

    In order to prevent the lenghty assoc. tablename, it would be a help, to allow the designer to chose a table name for assoc-tables in UML in a stereotype value. 

    1. Thank you very much. The problems are fixed. Please try again and use the forum for further bug reports.

  6. Anonymous

    <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal

    Unknown macro: {mso-style-parent}

    @page Section1

    Unknown macro: {size}

    div.Section1

    Unknown macro: {page}

    -->

    Hello

     

    I have a question about the class hierarchies. If I have an abstract class A and a concrete class B which extends A. The hierarchy is made with "TablePerClassHierarchy". For each of these two classes I get an interface, an abstract class and a concrete implementation. That is ok for me, but why the abstract class B extends from the abstract class A? Why not from the concrete class A?

    Because of this I have two problems. In some hibernate queries I get a class cast exception and I don't can use additional methods from the concrete class A in B.

     

    Thank you.

  7. Anonymous

    Hello

    I have a question about the class hierarchies. If I have an abstract class A and a concrete class B which extends A. The hierarchy is made with "TablePerClassHierarchy". For each of these two classes I get an interface, an abstract class and a concrete implementation. That is ok for me, but why the abstract class B extends from the abstract class A? Why not from the concrete class A?

    Because of this I have two problems. In some hibernate queries I get a class cast exception and I don't can use additional methods from the concrete class A in B.

    Thank you.