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


Reply via email to