RE: Hibernate plugin use Ant task instead of custom integration
Konstantin, Did your use of the Ant task include using a hibernate.cfg.xml file instead of .properties? I have spent some more time struggling with this, and I think I need to go back to learning about ClassLoaders... I thought it would be simple, but, apparently not! ERic -Original Message- From: Konstantin Shaposhnikov [mailto:[EMAIL PROTECTED] Sent: Thursday, June 24, 2004 12:23 AM To: Maven Developers List Subject: Re: Hibernate plugin use Ant task instead of custom integration On 18:15 Wed 23 Jun , Eric Pugh wrote: Argh... You were right about classloader hell.. I was able quite quickly to swap it to use the Hibernate SchemaExportTask with a .properties file. However, attempting to get the right mix of classpath's etc to get SchemaExportTask to work with .cfg.xml configuration file has been a very frustrating day! I was able to create a build.xml that worked with a .cfg.xml and .properties file, but converting that into the plugin.jelly just never worked. To say the trueth I get classloader errors when using original maven-hibernate-plugin and start to use ant task to avoid them. I have been able to add a src/plugin-test project that validates things work, which pretty much means only with a .properties file. I tried writing a unit test to load up the SchemaExportBean and use it via a .properties or .cfg.xml but no joy. So, at this point, I do have my nice little /src/plugin-test to contribute. However, is there any feeling on committing the Ant task instead of the custom integration or not? Right now the Ant task version does the same as the custom integration, and neither seems to deal with a .cfg.xml configuration file. I think that using ant task is much more simpler solution. To support schema-export task we need to create bean that simply duplicates all properties of ScemaExportTask. If for example Hibernate team add new option to this Task, with custom integration we need to add this property to bean that used from jelly and to plugin.jelly file. If we will use ant task, than much more less changes will be required. Opinions? About m2. I don't now much about it, but I think that it will definitly needs some plugin that works as wrapper for ant task, because a lot of ant tasks already exists, and it would be nice if they will be supported without significant efforts. Eric Best regards, Konstantin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hibernate plugin use Ant task instead of custom integration
On 12:11 Fri 25 Jun , Eric Pugh wrote: Konstantin, Did your use of the Ant task include using a hibernate.cfg.xml file instead of .properties? I have spent some more time struggling with this, and I think I need to go back to learning about ClassLoaders... I thought it would be simple, but, apparently not! No, I use this task only with .properties file. BTW, I have just checked Hibernate sources from HEAD (thats why I realy like opensource :) and found that SchemaExportTask supports configuration via cfg.xml file you need to set value of 'config' property. So I have tried to use it, and have no success, all I get is strange NPE. I dig into Hibernate source more deeply and found line with NPE: InputStream rsrc = Thread.currentThread().getContextClassLoader().getResourceAsStream(path); So I think you are right: the problem in classloaders, but I must to say that I am not very familiar with classloaders. Konstatin. ERic -Original Message- From: Konstantin Shaposhnikov [mailto:[EMAIL PROTECTED] Sent: Thursday, June 24, 2004 12:23 AM To: Maven Developers List Subject: Re: Hibernate plugin use Ant task instead of custom integration On 18:15 Wed 23 Jun , Eric Pugh wrote: Argh... You were right about classloader hell.. I was able quite quickly to swap it to use the Hibernate SchemaExportTask with a .properties file. However, attempting to get the right mix of classpath's etc to get SchemaExportTask to work with .cfg.xml configuration file has been a very frustrating day! I was able to create a build.xml that worked with a .cfg.xml and .properties file, but converting that into the plugin.jelly just never worked. To say the trueth I get classloader errors when using original maven-hibernate-plugin and start to use ant task to avoid them. I have been able to add a src/plugin-test project that validates things work, which pretty much means only with a .properties file. I tried writing a unit test to load up the SchemaExportBean and use it via a .properties or .cfg.xml but no joy. So, at this point, I do have my nice little /src/plugin-test to contribute. However, is there any feeling on committing the Ant task instead of the custom integration or not? Right now the Ant task version does the same as the custom integration, and neither seems to deal with a .cfg.xml configuration file. I think that using ant task is much more simpler solution. To support schema-export task we need to create bean that simply duplicates all properties of ScemaExportTask. If for example Hibernate team add new option to this Task, with custom integration we need to add this property to bean that used from jelly and to plugin.jelly file. If we will use ant task, than much more less changes will be required. Opinions? About m2. I don't now much about it, but I think that it will definitly needs some plugin that works as wrapper for ant task, because a lot of ant tasks already exists, and it would be nice if they will be supported without significant efforts. Eric Best regards, Konstantin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Hibernate plugin use Ant task instead of custom integration
Well.. It's could to have confirmation that my attemt to use the config property wasn't just some little boneheaded mistake.. I'm going to sit on my changes then for now.. no point in checking a bunch of stuff in that doesn't actually improve anything.. argh.. Eric -Original Message- From: Konstantin Shaposhnikov [mailto:[EMAIL PROTECTED] Sent: Friday, June 25, 2004 10:42 PM To: Maven Developers List Subject: Re: Hibernate plugin use Ant task instead of custom integration On 12:11 Fri 25 Jun , Eric Pugh wrote: Konstantin, Did your use of the Ant task include using a hibernate.cfg.xml file instead of .properties? I have spent some more time struggling with this, and I think I need to go back to learning about ClassLoaders... I thought it would be simple, but, apparently not! No, I use this task only with .properties file. BTW, I have just checked Hibernate sources from HEAD (thats why I realy like opensource :) and found that SchemaExportTask supports configuration via cfg.xml file you need to set value of 'config' property. So I have tried to use it, and have no success, all I get is strange NPE. I dig into Hibernate source more deeply and found line with NPE: InputStream rsrc = Thread.currentThread().getContextClassLoader().getResourceAsStream(path); So I think you are right: the problem in classloaders, but I must to say that I am not very familiar with classloaders. Konstatin. ERic -Original Message- From: Konstantin Shaposhnikov [mailto:[EMAIL PROTECTED] Sent: Thursday, June 24, 2004 12:23 AM To: Maven Developers List Subject: Re: Hibernate plugin use Ant task instead of custom integration On 18:15 Wed 23 Jun , Eric Pugh wrote: Argh... You were right about classloader hell.. I was able quite quickly to swap it to use the Hibernate SchemaExportTask with a .properties file. However, attempting to get the right mix of classpath's etc to get SchemaExportTask to work with .cfg.xml configuration file has been a very frustrating day! I was able to create a build.xml that worked with a .cfg.xml and .properties file, but converting that into the plugin.jelly just never worked. To say the trueth I get classloader errors when using original maven-hibernate-plugin and start to use ant task to avoid them. I have been able to add a src/plugin-test project that validates things work, which pretty much means only with a .properties file. I tried writing a unit test to load up the SchemaExportBean and use it via a .properties or .cfg.xml but no joy. So, at this point, I do have my nice little /src/plugin-test to contribute. However, is there any feeling on committing the Ant task instead of the custom integration or not? Right now the Ant task version does the same as the custom integration, and neither seems to deal with a .cfg.xml configuration file. I think that using ant task is much more simpler solution. To support schema-export task we need to create bean that simply duplicates all properties of ScemaExportTask. If for example Hibernate team add new option to this Task, with custom integration we need to add this property to bean that used from jelly and to plugin.jelly file. If we will use ant task, than much more less changes will be required. Opinions? About m2. I don't now much about it, but I think that it will definitly needs some plugin that works as wrapper for ant task, because a lot of ant tasks already exists, and it would be nice if they will be supported without significant efforts. Eric Best regards, Konstantin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Hibernate plugin use Ant task instead of custom integration
-Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 6:15 PM To: Maven Developers List Subject: RE: Hibernate plugin use Ant task instead of custom integration Argh... You were right about classloader hell.. I was able quite quickly to swap it to use the Hibernate SchemaExportTask with a .properties file. However, attempting to get the right mix of classpath's etc to get SchemaExportTask to work with .cfg.xml configuration file has been a very frustrating day! I was able to create a build.xml that worked with a .cfg.xml and .properties file, but converting that into the plugin.jelly just never worked. I have been able to add a src/plugin-test project that validates things work, which pretty much means only with a .properties file. I tried writing a unit test to load up the SchemaExportBean and use it via a .properties or .cfg.xml but no joy. So, at this point, I do have my nice little /src/plugin-test to contribute. However, is there any feeling on committing the Ant task instead of the custom integration or not? Right now the Ant task version does the same as the custom integration, and neither seems to deal with a .cfg.xml configuration file. IMO classloader problems can be more easly addressed in Java code then in jelly + ant :) If I remember correctly I managed to deal with .cfg.xml files with some classloader tricks. If you go with Java you'll have to write bit more code but you won't have to deal with ant classloaders... Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Hibernate plugin use Ant task instead of custom integration
-Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 2:42 PM To: Maven-Dev Subject: Hibernate plugin use Ant task instead of custom integration Hi all, I noticed a patch a while ago to the list from Konstantin Shaposhnikov which converted the Hibernate plugin to use the SchemaExportTask that is now available from the main Hibernate jar. I am going to update to using the Ant task as the existing interface to SchemaExport hasn't kept up with the various properties now available to SchemaExport (like using a .cfg.xml configuraiton file instead of .properties). This will hopefully reduce maintaince as well. If anyone sees this as a bad idea, please holler! As for me (I started this plugin) - please feel free to do whatever you want with it ... I didn't feel that it is the right idea to use ant tasks as I had some nasty problems with classloaders. For m2 the preferred way of writing plugins is using Java and so called Maven Pojos (Mojos). regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Hibernate plugin use Ant task instead of custom integration
Argh... You were right about classloader hell.. I was able quite quickly to swap it to use the Hibernate SchemaExportTask with a .properties file. However, attempting to get the right mix of classpath's etc to get SchemaExportTask to work with .cfg.xml configuration file has been a very frustrating day! I was able to create a build.xml that worked with a .cfg.xml and .properties file, but converting that into the plugin.jelly just never worked. I have been able to add a src/plugin-test project that validates things work, which pretty much means only with a .properties file. I tried writing a unit test to load up the SchemaExportBean and use it via a .properties or .cfg.xml but no joy. So, at this point, I do have my nice little /src/plugin-test to contribute. However, is there any feeling on committing the Ant task instead of the custom integration or not? Right now the Ant task version does the same as the custom integration, and neither seems to deal with a .cfg.xml configuration file. Opinions? Eric -Original Message- From: Maczka Michal [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 3:12 PM To: 'Maven Developers List' Subject: RE: Hibernate plugin use Ant task instead of custom integration -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 2:42 PM To: Maven-Dev Subject: Hibernate plugin use Ant task instead of custom integration Hi all, I noticed a patch a while ago to the list from Konstantin Shaposhnikov which converted the Hibernate plugin to use the SchemaExportTask that is now available from the main Hibernate jar. I am going to update to using the Ant task as the existing interface to SchemaExport hasn't kept up with the various properties now available to SchemaExport (like using a .cfg.xml configuraiton file instead of .properties). This will hopefully reduce maintaince as well. If anyone sees this as a bad idea, please holler! As for me (I started this plugin) - please feel free to do whatever you want with it ... I didn't feel that it is the right idea to use ant tasks as I had some nasty problems with classloaders. For m2 the preferred way of writing plugins is using Java and so called Maven Pojos (Mojos). regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hibernate plugin use Ant task instead of custom integration
On 18:15 Wed 23 Jun , Eric Pugh wrote: Argh... You were right about classloader hell.. I was able quite quickly to swap it to use the Hibernate SchemaExportTask with a .properties file. However, attempting to get the right mix of classpath's etc to get SchemaExportTask to work with .cfg.xml configuration file has been a very frustrating day! I was able to create a build.xml that worked with a .cfg.xml and .properties file, but converting that into the plugin.jelly just never worked. To say the trueth I get classloader errors when using original maven-hibernate-plugin and start to use ant task to avoid them. I have been able to add a src/plugin-test project that validates things work, which pretty much means only with a .properties file. I tried writing a unit test to load up the SchemaExportBean and use it via a .properties or .cfg.xml but no joy. So, at this point, I do have my nice little /src/plugin-test to contribute. However, is there any feeling on committing the Ant task instead of the custom integration or not? Right now the Ant task version does the same as the custom integration, and neither seems to deal with a .cfg.xml configuration file. I think that using ant task is much more simpler solution. To support schema-export task we need to create bean that simply duplicates all properties of ScemaExportTask. If for example Hibernate team add new option to this Task, with custom integration we need to add this property to bean that used from jelly and to plugin.jelly file. If we will use ant task, than much more less changes will be required. Opinions? About m2. I don't now much about it, but I think that it will definitly needs some plugin that works as wrapper for ant task, because a lot of ant tasks already exists, and it would be nice if they will be supported without significant efforts. Eric Best regards, Konstantin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
