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
>
-- 

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: 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


Reply via email to