I'd really like to customize the output of the "Hibernate Code Generation..." wizard for POJO and DAO generation, but somehow I think my current approach is not very good. I am using the results of the wizard to share the .launch configuration with other users.

I have copied the templates from the hibernate-tools.jar as outlined in the docs and adapted them. From within the eclipse plugins I could not see any possibility to set the extends property, so I changed PojoTypeDeclaration.ftl.

The next problem was putting the results of DAO and POJO exports in two different packages - I created a second run configuration with the different properties. Now I even have a third one for the Mapping files.

Is there a way to set properties from within the configuration to customize the output? I cannot event change the filenames of DAOs to ${declarationName}DAO instead of ${declarationName}Home. Overriding extends and implements would be nice too.

A colleague is using MyEclipse for this task, which provides great integration features, but somehow fails in the flexibility domain. They have provided their own templates and exporter classes.

The problem is that I see all the possibilities when going through the source code, but no way to set these options from within the Eclipse plugins.


Another question: MyEclipse provides Spring-based velocity templates. I could not find anything similar except these templates in the appfuse maven plugin repository. Any advices?


Thank you,
Kariem

but that does work for you, right ?



the docs explain how you can configure extends by meta attributes in the hbm.xml files.

What exactly are you looking for ?



third one for what ?

the multiple directory/package thing is a known limitation at the moment (see jira)



depend on what versyou you are using. the latest one have a properties view for each exporter.

again extends/implements is controlled through the mappings via meta attributes or use the reveng.xml. (we avoid to tie too much to some specific eclipse ui setting so it can actually be shared)

I recommend you read the docs for the various options/possibilities.



What great integration features are you referring too ?

(you do realize that large parts of myeclipse hibernate tooling is based upon an old fork of hibernate tools and they basically decided not to give back any of the enhancements they made - at least i'm still waiting for them ;) ...them using and old fork also means they don't have the immense improvements that have been added to hibernate tools since they decided to have their "own version"



what options are you missing exactly ?



Interesting - did not know appfuse used hibernate tools...;)

note that those templates you point to are freemarker templates (Good!), and the MyEclipse's are velocity because of them doing work based on the old tools which used Velocity templates (bad!) in the beginning.

with respect to spring templates then you probably won't see us providing those since we don't belive in HibernateTemplate being a good way of accessing Hibernate.

But as you can see from AppFuse it's pretty trivial to do customizations.

To summarize what I think you are looking for is something resembling <hbmtemplate> from our ant support in eclipse. This is not there yet but I hope it soon will be.

Next you want to control the file and package naming via something like filepattern (from hbmtemlate) this is also on the todo list.

Feel free to jump in and provide patches.

Yes, somehow. But I feel like using a lot of functionality by replacing the dynamic parts with my stuff instead of just using it. I think I am doing something wrong.

Instead setting the extends property and using

I just replace that part with this

Don't think it should be that way



I am trying do use the "Code Generation" Wizard provided by the Hibernate tools Eclipse plugin. I could not find any option to set the extends property without having HBM files. Currently the path is

JDBC => (HBM+DAO+POJO)

I cannot set anything on the HBM, because it is created in the same step.

1. DAO => my.package.base.dao.hibernate
2. POJO => my.package.base.model
3. HBM => my.package.base.model (but other directory)

Sure I have the latest: beta 9 :) And I read through the docs.

I have created the reveng file and use it for the code generation. But, does it really provide the option to set the extends property? This would not be the right place.


Most of the things that come with the hibernate tools are easier to use with myeclipse. And they provide a lot of glue stuff between hibernate and spring. With the Add Hibernate Capabilities wizard you can automatically add the libraries to the build path, or just reference the library. It is possible to choose from different types of DAO generation, but what I liked most is the option to include referenced or referencing tables during reverse engineering configuration.

I don't like the wizard stuff at all, because for this special project I wanted to show a new project team how nice it is to work with hibernate, and want them to understand how it works, not how to use a nice wizard.


Sure, that's the main problem for me with myeclipse. It seems they have great features, but if you look at it in more detail, you cannot really do a lot of customization. When I saw the velocity templates for the spring libraries I knew I would not want to do the customization with myeclipse.


Sorry, I admit that my message was not very exact.

Eclipse plugin - Hibernate Code Generation should support

• Setting more properties for POJO and DAO generation, especially implements and extends. Currently only global settings can be set (Java 5, EJB 3), but I would really like all my classes implement one interface, or let the hibernate tools create the toString and hashCode methods.
• Different output folders for different exporters. Schema documentation is usually not at the same place as HBM files

What I really need is some documentation on how to really use the templates. How can I set the file names for generated DAOs (currently it is set to ${declarationName}Home.


Yes, perfect. I made it difficult to understand me, but You got it right :)


Sure, if I find a solution I would be proud to support such a great project. With little time in my hands this task is quite difficult, but such a quick answer really motivates :)

Well, it is one of the ways to do it (but does not work well if you have mapped any subclasses).



So use a reveng.xml with something like:



This will add the extends attribute for every table that is reverse engineered.



yes; this is on my todo list...



It does provide that option (see above); and why don't you think that is the right place ?

The other option is to allow you to set a property on the codegeneration part (hbm2java to be exact) that says what is the default extends....that is on my todo; but not critical at the moment since you have the above options (and I like that the settings are not scattered too much).



This is one of my favorite love/hate features of most "integration" done with eclipse. People tend to forget that eclipse already provide a nice userlibrary configuration that does not require any special plugins.

Furthermore the libraries we would tend to bundle with the plugins would probably never be the exact version you want to use.

But yes, I do realize it is easier I've just refrained from adding this kind of setup since I feel eclipse already provides this functionallity (user libraries). But maybe I should just bite the bullet and add some sugar coating on top of those built in user libraries to help users setup hibernate; but still let the related projects classpath be independent of the plugins.



The same functionallity that are in that screen (but not as limited/constrained) is very close to what we have...but yes we need to get the things you bumped into fixed/implemented to make it happen.

The conrecte dao generation is not spring bound; but that would be trivial for someone in the community to add/support.



Yes, we should have an easy switch for doing the same (to trivial to do to leave it out ;)

Could you explain what the difference is between the 4 lower checkboxe's ? I would naively think only 2 of them would be needed...(one of each)



are they that bad ? :) Anyway I hope myeclipse keeps up their promise to make sure that they stay compatible with hibernate tools so you at least can use the newer/fixed features while inside myeclipse.



the interface implements part is controllable by meta attributes (and thus can be configured in reveng.xml)

the tostring and hashcode (and don't forget equals) is also possible to enable but *definitly* not recommended to do blindly since it is *bad*.
I would definitly hope myeclipse does not allow that to be toggled globally!

What is the code they generate for that ?


got ya!



only possible with hbmtemplate from ant at the moment.



Giving feedback/ideas and telling what works and what does not work is also very much welcomed!

Wow, cool. Didn't know that. So you can use the meta attribute to add properties for code generation during reverse engineering. I know you could set the class and package names. I just thought this kind of property would fit better in code generation. But in fact it is part of the meta-model, which is generated at the time of reverse engineering.




I haven't used the last two checkboxes yet. The first pair is nice: "Include referenced tables (A->B)" includes all the tables this one table references, while the referencing tables includes all the tables that point to this table. You click the checkbox and the tree is updated instantly. According to the documentation, the last pair of checkboxes generates code for tables that are referenced in the DB relation, but are not part of the current generation process.



Again, I was not very clear. With hbm2java I usually enable the toString method individually on every class I need this method to be generated. Last time I used it, I think the toString method was generated with the ToStringBuilder. It should be possible to set all the properties that are possible to set for hbm2java with the meta tags. I don't think it is good to make class or method-specific properties globally available.


Thanks for the answers!

Kariem

be aware though that if you have more table-filter's you will have to specify the meta attributes there (the first table-filter that matches wins).
but if you have the same rules for all your tables the above line will work.



There are use cases for both views; but most of it comes down to what view of code generation you have.

I guess you just want to specify one base class for everything no matter if it makes sense or not. Similar views are found for those who want hbm2java to always generate a base class they can extend for all classes; not considering if its needed or not (and thus it (or at least can) result in having nonneeded extends and twice as many classes "just for fun") - such a (global) setting would be relevant at the codegeneration level.

The other view is to not do this as a global setting but mark the relevant classes that needs the "special" attention and that is what hbm2java currently does/supports by using the meta attributes in the meta model and thus it is something to be specified at the reveng time.

Eventually i hope to support both.



I understand "Include referenced tables (A->B)"

I would "argue" that "Include referenced tables (A->B)" + an optional "depth" value would be what is needed indicating how far one should go in including references.

The B->A is for getting tables that includes references to A I assume...probably also relevant.

don't know if these should be pure ui helpers or one should be allowed to specify this in reveng.xml "declarertively"..



hmm...i guess that is relevant if you are generating code in "batches" so that it can generated add/remove/set/get for classes that is already generated.



These meta attributes are also possible to set via reveng.xml on specific table and column elements.

You can even implement your own custom reveng strategy to control it programmatically if you so pleases.

Hi!

I want to know if I can set somehow that I can distinguish the primary key field from a pojo.

I generated the pojo with reverse engineering, without xml mappings.
I have a simple bean, with some fields. Can I somehow mark the bean field to know that, that is the primary key? For ex. adding a "table_pk_" prefix to it.

Or, can I add a new field without getter and setter to that bean like


Note: I want to generate with hbm2java the POJO-s from a DB, and that is all, so I don`t want to use it in real hibernate world.


So, I run hbm2java, and is generated a POJO, a simple bean for ex. with these fields:



From here I don`t see which is the primary key.
I want to make a generic pojo generator, I set just the connection settings, and I need the pojo-s. Till now it is ok, but I need to know which fields from these is the PK.
(In this case is the ninfonr.)

what do you mean ?

if your table have a primary key it will be mapped as a primary key.

I have edited my question.
If that is not possible, It will be great if I could obtain from ftl templates if one field is primary key or not.



I mean something like:

So you want to rename the property to "id" or how ?

note in JPA it is marked with an @Id annotation; do you have that ?

anyway - you can find the Id Property by calling $pojo.getIdentifierProperty()

Thank You!
That-s what I want!

PS. Can You tell me where can I find a description for these properties, and what properties are accessible.

Hibernate tools sourcecode ;)

Hibernate Core API (look in org.hibernate.Configuration and the org.hibernate.mapping.* package)

Yes; it would be great if someone had the time to document the default available properties in the templates......anyone up for contributing that ?

Hi!
I have a question again. :)
It is possible to get somehow the original table name from template?
For ex. if I have in db a table with name customer_service_provider then the POJO`s name will be CustomerServiceProvider. But I need to access from template the original table name.

yes - look in the hbm ftl templates how they are accessed.