Hi Stevo, me again, though a bit later than originally thought.
Cheers Werner Stevo Slavić wrote: > 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. > - 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. +1. > - There are also multiple build helper plugin configurations with > comments that they should be removed once new castor-maven-plugin is > released. There's already a Jira issue that deals with this. > IMO it is questionable whether build helper configuration should > be removed, I think they should, as most of the functionality provided by the build-helper-plugin has been moved into the castor-maven-plugin, such as the addition of generated resource files to the project, etc. Again, the aforementioned patch should be dealing with this. > .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 Please no m2eclipse .. ;-), but in general the use of mvn eclipse:eclipse provides you - after a checkout - with everything required to work on the Castor sources. > - 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. I personally agree with you here, but this is down to personal preferences of committers. I can live with it, but for others convenience is very important. > - 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; > - .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. Same as above. I am much in favour of Maven, and would think along the same lines. But then gain, for others this is less importamt. > If you agree, I can create a patch with all these adjustments included for > you to verify. Thank you very much for this offer, but one patch for all these adjustments won't work (for the reasons stated above). But I'd appreciate any help with verifying some of my own patches and providing patches for isolated areas (where everybody agrees). > > Regards, > Stevo. > > 2009/11/29 Ralf Joachim <[email protected]> > >> 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 >>>> E-Mail: [email protected] >>>> >>>> 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 >> E-Mail: [email protected] >> >> 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
