Just a gernal observation. I have got a TO-DO list in front of me that includes the majority of the problems/issues as raised by Stevo. But I agree with Ralf that (sub-)task would be nice to have, so that I cab structure myself in the next coming days.
lG. Werner Ralf Joachim wrote: > Hi Stevo, > > see my comments inline. > > Stevo Slavić schrieb: >> Hello Werner and Ralf, >> >> * My patch hasn't been applied completely. Even so, patch didn't >> remove all references to 2.0-SNAPSHOT version of >> castor-maven-plugin (just ones which prevented building castor), >> and there are some other snapshot references too (default >> release plugin configuration would have prevented this). All the >> modules seem to inherit org.codehaus.castor:castor aggregator >> parent module which has pluginManagement section but it >> currently doesn't specify castor-maven-plugin. IMO it would be >> best to add castor-maven-plugin with latest released version >> there, and then remove all the version references from other >> child modules - this would improve consistency and maintainability. >> > Using pluginManagement sounds like a good idea to me but I expect you > will hit some problems. E.g. there are dependencies to derby in 3 > modules (cpactf, jdo-extension-it and jpa-extension-it). While we need > derby 10.5.3.0_1 for cpactf this version of derby does cause failing > tests in the other 2 modules which is the reason why the other modules > still depend on derby 10.4.xxx. Not sure if there are other dependecies > with similar problems. >> * All the commented out stuff in poms should be cleaned up too - >> poms are under version control after all, and all the commented >> out stuff just lowers readability. >> > Fine by me in general with one exception. To my knowledge there is at > least one part, the clover configuration, that is commented out as we > didn't manage to get this new feature working yet. For this parts jira > issues should be created that allow to reproduce current state. >> * There are also multiple build helper plugin configurations with >> comments that they should be removed once new >> castor-maven-plugin is released. IMO it is questionable whether >> build helper configuration should be removed, .classpath files >> with hardcoded classpath entries to generated sources should >> better be removed from version control (read on for more on >> this) - maven executions will use build helper plugin while for >> eclipse there are maven integration plugins like m2eclipse which >> can handle this dynamically >> > I'm fine with removing build helpers if everything works as expected > thereafter. See my comments on .classpath below. >> * >> >> >> * Why have IDE (eclipse) specific files been put under version >> control? I prefer to put them under svn:ignore and this seems to >> be practice in many if not all maven core and plugin projects. >> o Eclipse specific files like .classpath committed to svn >> have hardcoded stuff like M2_REPO classpath entries. I'm >> using eclipse too, with m2eclipse plugin and subversive >> with m2eclipse integration, so project can be easily >> checked-out as maven project, where m2eclipse configures >> eclipse classpath, not by adding classpath entry for every >> dependency, but by adding a single classpath entry to >> org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER which >> acts as m2eclipse managed dynamic library with all the >> dependencies configured in pom; now, if I manage project >> with m2eclipse it will modify these IDE specific files and >> eclipse projects will appear as if they've been modified, >> and IDE specific files will appear in listings when >> preparing patch; >> o .checkstyle configuration file is also under version >> control; with checkstyle 5.0 out, and eclipse-cs plugin >> and its integration with m2eclipse, it is enough just to >> configure latest maven checkstyle plugin in castor parent >> module pom, this configuration will be used by maven and >> that same configuration through eclipse-cs plugin >> m2eclipse integration will be used in eclipse as well; >> eclipse-cs m2eclipse generation in that case will >> configure eclipse-cs by generating .checkstyle file so it >> can possibly be different to one under version control so >> this file and project it belongs will appear as with >> modifications, thus it would be best to put this, again >> IDE specific, file out of version control and into the >> svn:ignore list. >> > I personally use maven from command line and do not like the eclipse > configuration 'mvn eclipse:eclipse' produces. It's up to you to use any > tool you like to produce your eclipse configurations but don't force > others to use them too. As long as maven isn't able to produce the > configurations as they currently are I like the eclipse configuration > files to be kept in SVN. If you like to tune pom with regard to those > that like to work with generated configurations I'm open to your additions. >> If you agree, I can create a patch with all these adjustments included >> for you to verify. >> >> Regards, >> Stevo. > Could you please create a issue in jira about improvements to maven > build. Maybe it would be a good idea to handle different improvements > with separate subtasks to this issue. > > Regards > Ralf >> 2009/11/29 Ralf Joachim <ralf.joac...@syscon.eu >> <mailto:ralf.joac...@syscon.eu>> >> >> Werner, >> >> you are right, I'm not using mvn eclipse:eclipse. >> >> Ralf >> >> Werner Guttmann schrieb: >> > Ralf, >> > >> > just to make sure, you are not doing a mvn eclipse:eclipse before >> > importing Castor into Eclipse, correct ? If that's the case, you are >> > (probably) right. But I will have to try this myself .... >> > >> > Cheers >> > Werner >> > >> > PS Have you ever tried >> > >> > >> >> svn co .... >> >> mvn eclipse:eclipse >> >> >> > >> > followed by an import of the Castor modules into Eclipse ? >> > >> > Ralf Joachim wrote: >> > >> >> Hi Stevo and Werner, >> >> >> >> if you just do 'mvn clean install' you will still see compile >> errors in >> >> eclipse as generation of sources for cpactf and >> jdo-extension-it modules >> >> will not be executed. To prevent this problems you have to >> execute 'mvn >> >> -Pit clean install'. >> >> >> >> Werner: any chances to get generation of this sources triggered >> without >> >> triggering execution of the tests? >> >> >> >> Regards >> >> Ralf >> >> >> >> Werner Guttmann schrieb: >> >> >> >>> Hi Stevo, >> >>> >> >>> given Ralf committed a patch a few days ago, can we assume >> that you can >> >>> now build things successfully. >> >>> >> >>> Cheers >> >>> Werner >> >>> >> >>> Stevo Slavić wrote: >> >>> >> >>> >> >>>> Hello Castor developers, >> >>>> >> >>>> I was able to build current Castor only after upgrading >> dependency to >> >>>> castor-maven-plugin from 2.0-SNAPSHOT to 2.0. Additionaly >> I've removed >> >>>> castor-maven-plugin dependency to codegen 1.3rc1 at one place >> as IMO it's no >> >>>> longer needed. Attached is patch with these adjustments. >> >>>> >> >>>> Regards, >> >>>> Stevo. >> >>>> >> >>>> >> >>> >> --------------------------------------------------------------------- >> >>> To unsubscribe from this list, please visit: >> >>> >> >>> http://xircles.codehaus.org/manage_email >> >>> >> >>> >> >>> >> >>> >> >> -- >> >> >> >> Syscon Ingenieurbüro für Meß- und Datentechnik GmbH >> >> Ralf Joachim >> >> Raiffeisenstraße 11 >> >> 72127 Kusterdingen >> >> Germany >> >> >> >> Tel. +49 7071 3690 52 >> >> Mobil: +49 173 9630135 >> >> Fax +49 7071 3690 98 >> >> >> >> Internet: www.syscon.eu <http://www.syscon.eu> >> >> E-Mail: ralf.joac...@syscon.eu <mailto:ralf.joac...@syscon.eu> >> >> >> >> Sitz der Gesellschaft: D-72127 Kusterdingen >> >> Registereintrag: Amtsgericht Stuttgart, HRB 382295 >> >> Geschäftsleitung: Jens Joachim, Ralf Joachim >> >> >> >> >> --------------------------------------------------------------------- >> To >> >> unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > >> > >> --------------------------------------------------------------------- >> > To unsubscribe from this list, please visit: >> > >> > http://xircles.codehaus.org/manage_email >> > >> > >> > >> -- >> >> Syscon Ingenieurbüro für Meß- und Datentechnik GmbH >> Ralf Joachim >> Raiffeisenstraße 11 >> 72127 Kusterdingen >> Germany >> >> Tel. +49 7071 3690 52 >> Mobil: +49 173 9630135 >> Fax +49 7071 3690 98 >> >> Internet: www.syscon.eu <http://www.syscon.eu> >> E-Mail: ralf.joac...@syscon.eu <mailto:ralf.joac...@syscon.eu> >> >> Sitz der Gesellschaft: D-72127 Kusterdingen >> Registereintrag: Amtsgericht Stuttgart, HRB 382295 >> Geschäftsleitung: Jens Joachim, Ralf Joachim >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email