Maven 1.x Hibernate Plugin

Adding POJO from hbm file code generation feature to plugin

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.3
  • Component/s: None
  • Labels:
    None
  • Environment:
    N/A
  • Number of attachments :
    8

Description

I have added a feature to my local version of the hibernate plugin which I thought might be worthy of inclusion in a future version.

In the projects I work on there is a need to generate POJOs classes from hibernate hbm files and I have adapted and incorportated an old ant script into our maven-hibernate plugin to do this.

In order to add this goal all you have to do is:

1. Add the following to project.xml:

<dependency>
<groupId>hibernate-extensions</groupId>
<artifactId>hibernate-tools</artifactId>
<version>2.1.2</version>
<type>jar</type>
</dependency>
<dependency>
<groupId>jdom</groupId>
<artifactId>jdom</artifactId>
<version>1.0</version>
<type>jar</type>
</dependency>

2.

Add the following goal to the plugin.jelly

<goal name="hibernate:hbm-code-generation" prereqs="hibernate:init" description="Generate POJOs from hbm files">

<ant:echo>Generating POJOs from hbm files</ant:echo>

<ant:fileset id="hbm.fileset" dir="${maven.hibernate.generated.input.dir}" includes="${maven.hibernate.input.includes}"/>
<ant:pathconvert property="hbm.files" refid="hbm.fileset" pathsep=" "/>

<ant:java classname="net.sf.hibernate.tool.hbm2java.CodeGenerator"
failonerror="true">

<ant:classpath>
<ant:pathelement location="${plugin.getDependencyPath('hibernate-extensions:hibernate-tools')}"/>
<ant:pathelement location="${plugin.getDependencyPath('commons-collections:commons-collections')}"/>
<ant:pathelement location="${plugin.getDependencyPath('commons-logging:commons-logging')}"/>
<ant:pathelement location="${plugin.getDependencyPath('jdom:jdom')}"/>
<ant:path refid="maven.dependency.classpath"/>
</ant:classpath>

<ant:arg value="--output=${maven.hibernate.generated.output.dir}"/>
<ant:arg line="${hbm.files}"/>
</ant:java>

</goal>

3.

Add the following properties to the plugin.properties

maven.hibernate.generated.input.dir=${maven.src.dir}/conf/hibernate
maven.hibernate.generated.output.dir=${maven.src.dir}/java

4.

Ensure that hibernate-tools-2.1.2.jar is available at ibiblio.

It should now be possible to generate POJOs from hbm files. The POJOs will be placed in the src/java directory by default.

I am in the process of carrying out Step 4 myself and will hopefully do this soon.

Hope you find this worth consideration and hopefully it can make it into a future release.

Attachments

  6. Text File
    patch.txt
    07/Dec/04 6:20 PM
    10 kB
    Paul Kearney
  7. File
    patch-felipeal-1
    12/Dec/04 5:58 PM
    9 kB
    Felipe Leme
  8. Text File
    patch-paulk-1.txt
    12/Jan/05 3:24 PM
    132 kB
    Paul Kearney

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Felipe Leme added a comment -

Paul,

This feature seems very interesting and we would be glad to add a new goal for it in the plugin. But before we do so, I have some comments:

1.We are not using Jelly to write this plugin - all features are implemented in Java and we use Jelly only as a wrapper (take a look on the current code, it's pretty simple)

2.We need test cases for the new feature

3.Also, we would need that new feature documented (tipycally at xdocs/properties.xml and xdocs/goals.xml)

3.The best way to contribute is providing a patch (using cvs diff or a patch feature from your IDE - Eclipse, for instance, have a nice cvs support).

Could you try these 4 improvements and then attach the patch here on Jira?

– Felipe

Show
Felipe Leme added a comment - Paul, This feature seems very interesting and we would be glad to add a new goal for it in the plugin. But before we do so, I have some comments: 1.We are not using Jelly to write this plugin - all features are implemented in Java and we use Jelly only as a wrapper (take a look on the current code, it's pretty simple) 2.We need test cases for the new feature 3.Also, we would need that new feature documented (tipycally at xdocs/properties.xml and xdocs/goals.xml) 3.The best way to contribute is providing a patch (using cvs diff or a patch feature from your IDE - Eclipse, for instance, have a nice cvs support). Could you try these 4 improvements and then attach the patch here on Jira? – Felipe
Hide
Permalink
David Eric Pugh added a comment -

Paul, I think we corresponded offline about this bug. I wanted to make sure this hadn't fallen through the cracks. What is the current status on this.. I thought you sent me some files, but I can't find them. Can you attach them directly to the bug?

Show
David Eric Pugh added a comment - Paul, I think we corresponded offline about this bug. I wanted to make sure this hadn't fallen through the cracks. What is the current status on this.. I thought you sent me some files, but I can't find them. Can you attach them directly to the bug?
Hide
Permalink
Paul Kearney added a comment -

Eric,

yes we did correspond about this. I sent you some files that can be recreated by following the steps I detailed in my original comment. I have been a bit pressed for time recently but am going to look at implementing Felipes suggestions.

Once I have a working version of this I'll let you know.

Paul

Show
Paul Kearney added a comment - Eric, yes we did correspond about this. I sent you some files that can be recreated by following the steps I detailed in my original comment. I have been a bit pressed for time recently but am going to look at implementing Felipes suggestions. Once I have a working version of this I'll let you know. Paul
Hide
Permalink
Paul Kearney added a comment -

Patch for source required in order to provide hbm-code-genration target. There is a futher zip'd file to be attached that contains the complete file structure with all my amendments included as the changes to the plugin.jelly, etc did not seem to be included in the patch (generated using Eclipse)

Show
Paul Kearney added a comment - Patch for source required in order to provide hbm-code-genration target. There is a futher zip'd file to be attached that contains the complete file structure with all my amendments included as the changes to the plugin.jelly, etc did not seem to be included in the patch (generated using Eclipse)
Hide
Permalink
Paul Kearney added a comment -

Zip inlcudes plugin.jelly etc

Show
Paul Kearney added a comment - Zip inlcudes plugin.jelly etc
Hide
Permalink
Paul Kearney added a comment -

I have (I think) carried out all of Felipe's suggestions. I have updated the xdocs and provided a basic test case. I am reusing some properties that are used in other targets and maybe these should be seperated out.

Any further comments let me know and I'll see what I can do. I haven't as yet got round to uploading the hibernate-extenstions jar required for this plugin to work onto ibiblio and I have made assumptions about its group id.

Paul

Show
Paul Kearney added a comment - I have (I think) carried out all of Felipe's suggestions. I have updated the xdocs and provided a basic test case. I am reusing some properties that are used in other targets and maybe these should be seperated out. Any further comments let me know and I'll see what I can do. I haven't as yet got round to uploading the hibernate-extenstions jar required for this plugin to work onto ibiblio and I have made assumptions about its group id. Paul
Hide
Permalink
Felipe Leme added a comment -

Hi Paul,

I've tried to apply your patch, but that hibernate-extensions:hibernate-tools jar is not on ibiblio.

Could you please open a jira request for uploading it? Prefereably, versions 2.1.3 (which is the current version used by the plugin) and 2.1.6 (which is the most recent).

– Felipe

PS: here are the instructions on how to upload it:

http://maven.apache.org/repository-upload.html

Show
Felipe Leme added a comment - Hi Paul, I've tried to apply your patch, but that hibernate-extensions:hibernate-tools jar is not on ibiblio. Could you please open a jira request for uploading it? Prefereably, versions 2.1.3 (which is the current version used by the plugin) and 2.1.6 (which is the most recent). – Felipe PS: here are the instructions on how to upload it: http://maven.apache.org/repository-upload.html
Hide
Permalink
Paul Kearney added a comment -

Adding ibiblio upload bundle to this jira in order to make it readily available for inclusion in a further jira request to have it uploaded to the ibiblio server.

Show
Paul Kearney added a comment - Adding ibiblio upload bundle to this jira in order to make it readily available for inclusion in a further jira request to have it uploaded to the ibiblio server.
Hide
Permalink
Paul Kearney added a comment -

Apologies added the wrong jar. Adding the upload bundle jar this time.

Show
Paul Kearney added a comment - Apologies added the wrong jar. Adding the upload bundle jar this time.
Hide
Permalink
Paul Kearney added a comment -

Felipe,

I have placed a request for the upload of the hibernate-tools-2.1.3.jar to ibiblio as you suggested. If this goes ahead the project.xml for my patch will require to be updated to reflect the newer version of this jar (2.1.3 now, not 2.1.2).

Paul

Show
Paul Kearney added a comment - Felipe, I have placed a request for the upload of the hibernate-tools-2.1.3.jar to ibiblio as you suggested. If this goes ahead the project.xml for my patch will require to be updated to reflect the newer version of this jar (2.1.3 now, not 2.1.2). Paul
Hide
Permalink
Paul Kearney added a comment -

Updated to include actual hibernate-tools.jar

Show
Paul Kearney added a comment - Updated to include actual hibernate-tools.jar
Hide
Permalink
Felipe Leme added a comment -

Paul,

I did some minor modifications in the testcases and the patch is almost done. Still, I think it needs some more features before it can be applied:

  • we need to tell the plugin which classes should or should not be generated. For instance, the current test case is regenerating the Item.java from Item.hbm.xml. In other words, we need a exclude/include pair of properties (something like maven.hibernate.generated.input.includes)
  • also, the new goal should automaticaly add maven.hibernate.generated.output.dir to the src set expected by java:compile. I added 2 lines to teh tag, but I'm nto sure if that's the right way to do it (I mean, we should be doing that in the Java class, not in the Jelly script). Also, the test case is failing because now we have some duplicated Java files (see item above)

Anyway, I'm attaching the new patch (patch-felipeal-1).

Thanks,

Felipe

PS: to run the test-cases, simply type 'maven plugin:test' at the hibernate directory

properties

Show
Felipe Leme added a comment - Paul, I did some minor modifications in the testcases and the patch is almost done. Still, I think it needs some more features before it can be applied:
  • we need to tell the plugin which classes should or should not be generated. For instance, the current test case is regenerating the Item.java from Item.hbm.xml. In other words, we need a exclude/include pair of properties (something like maven.hibernate.generated.input.includes)
  • also, the new goal should automaticaly add maven.hibernate.generated.output.dir to the src set expected by java:compile. I added 2 lines to teh tag, but I'm nto sure if that's the right way to do it (I mean, we should be doing that in the Java class, not in the Jelly script). Also, the test case is failing because now we have some duplicated Java files (see item above)
Anyway, I'm attaching the new patch (patch-felipeal-1). Thanks, Felipe PS: to run the test-cases, simply type 'maven plugin:test' at the hibernate directory properties
Hide
Permalink
Paul Kearney added a comment -

Updated to change id to articactId and the groupId to hibernate

Show
Paul Kearney added a comment - Updated to change id to articactId and the groupId to hibernate
Hide
Permalink
Paul Kearney added a comment -

Felipe,

The current plugin.jelly does support the exclusion of files from being generated. If you set maven.hibernate.input.excludes = org/apache/maven/hibernate/Item.hbm.xml then this should exclude the Item.java from being generated.

This just re-uses existing properties and I agree it may well be clearer to provide hbm generation specific properties rather than reusing existing ones. Both maven.hibernate.input.includes and maven.hibernate.input.excludes are reused in the plugin.jelly I submitted.

The second point regarding the addition of the generated source to the src set expected by the java:compile target I am not sure about.

For one this sounds like it may require overriding the class loader (something I have never attempted before), but it also strikes me as being beyond the scope of the plugin. It makes an assumption that everyone using the plugin will run java:compile after the code is generated. Would it not be more sensible to allow the person using the plugin to add the generated source directory to their java:compile set by configuring the maven.compile.src.set property of the java plugin. Personally, I set the maven.hibernate.generated.output.dir property to point to my projects java source directory (not that I am suggesting everyone should have to do this, but it does make sense to me).

Let me know if you agree or not.

Paul

Show
Paul Kearney added a comment - Felipe, The current plugin.jelly does support the exclusion of files from being generated. If you set maven.hibernate.input.excludes = org/apache/maven/hibernate/Item.hbm.xml then this should exclude the Item.java from being generated. This just re-uses existing properties and I agree it may well be clearer to provide hbm generation specific properties rather than reusing existing ones. Both maven.hibernate.input.includes and maven.hibernate.input.excludes are reused in the plugin.jelly I submitted. The second point regarding the addition of the generated source to the src set expected by the java:compile target I am not sure about. For one this sounds like it may require overriding the class loader (something I have never attempted before), but it also strikes me as being beyond the scope of the plugin. It makes an assumption that everyone using the plugin will run java:compile after the code is generated. Would it not be more sensible to allow the person using the plugin to add the generated source directory to their java:compile set by configuring the maven.compile.src.set property of the java plugin. Personally, I set the maven.hibernate.generated.output.dir property to point to my projects java source directory (not that I am suggesting everyone should have to do this, but it does make sense to me). Let me know if you agree or not. Paul
Hide
Permalink
Felipe Leme added a comment -

I will be off-line for a couple of weeks, but will take a better look on the issue when I'm back (early January).

Show
Felipe Leme added a comment - I will be off-line for a couple of weeks, but will take a better look on the issue when I'm back (early January).
Hide
Permalink
Paul Kearney added a comment -

Felipe,

I have updated the plugin to have its own properties for excluding and including files for POJO generation.

Hope this solves some of the problems you raised with the previous version.

Show
Paul Kearney added a comment - Felipe, I have updated the plugin to have its own properties for excluding and including files for POJO generation. Hope this solves some of the problems you raised with the previous version.
Hide
Permalink
Felipe Leme added a comment -

Hi Paul,

Sorry, but I've been too busy lately, so I hadn't have the time to look on your changes yet.

– Felipe

Show
Felipe Leme added a comment - Hi Paul, Sorry, but I've been too busy lately, so I hadn't have the time to look on your changes yet. – Felipe
Hide
Permalink
Felipe Leme added a comment -

Paul,

I committed the changes, with one minor change: using codeGeneration instead of generated on the properties.

I also have a question for you: do you know how to setup hbm2java to add XDoclet tags (@hibernate) on the generated POJOs? I thought that would be possible, but didn't find anything on the CodeGenerator class...

– Felipe

Show
Felipe Leme added a comment - Paul, I committed the changes, with one minor change: using codeGeneration instead of generated on the properties. I also have a question for you: do you know how to setup hbm2java to add XDoclet tags (@hibernate) on the generated POJOs? I thought that would be possible, but didn't find anything on the CodeGenerator class... – Felipe
Hide
Permalink
Felipe Leme added a comment -

Nevermind the XDoclet question, I figured it out myself - you need to add the XDoclet tags in a <meta> tag inside the .hbm.xml.

– Felipe

Show
Felipe Leme added a comment - Nevermind the XDoclet question, I figured it out myself - you need to add the XDoclet tags in a <meta> tag inside the .hbm.xml. – Felipe
Hide
Permalink
Paul Kearney added a comment -

Excellent new Felipe. Do you know when this will make it into a release?

Paul

Show
Paul Kearney added a comment - Excellent new Felipe. Do you know when this will make it into a release? Paul
Hide
Permalink
Felipe Leme added a comment -

Hi Paul,

I'd like to have released 1.3 already, but haven't had the time yet

Hopefully I will do it by middle of next week.

– Felipe

Show
Felipe Leme added a comment - Hi Paul, I'd like to have released 1.3 already, but haven't had the time yet Hopefully I will do it by middle of next week. – Felipe

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.