Hi Stevo,
see my comments inline.
Post by Stevo SlaviÄ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.
Post by Stevo SlaviÄ* 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.
Post by Stevo SlaviÄ* 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.
Post by Stevo SlaviÄ*
* 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.
Post by Stevo SlaviÄ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
Post by Stevo SlaviÄWerner,
you are right, I'm not using mvn eclipse:eclipse.
Ralf
Post by Werner GuttmannRalf,
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 ?
Hi Stevo and Werner,
if you just do 'mvn clean install' you will still see compile
errors in
Post by Werner Guttmanneclipse as generation of sources for cpactf and
jdo-extension-it modules
Post by Werner Guttmannwill not be executed. To prevent this problems you have to
execute 'mvn
Post by Werner Guttmann-Pit clean install'.
Werner: any chances to get generation of this sources triggered
without
Post by Werner Guttmanntriggering execution of the tests?
Regards
Ralf
Post by Werner GuttmannHi Stevo,
given Ralf committed a patch a few days ago, can we assume
that you can
Post by Werner GuttmannPost by Werner Guttmannnow build things successfully.
Cheers
Werner
Post by Stevo SlaviÄHello Castor developers,
I was able to build current Castor only after upgrading
dependency to
I've removed
as IMO it's no
Post by Werner GuttmannPost by Werner GuttmannPost by Stevo SlaviÄlonger needed. Attached is patch with these adjustments.
Regards,
Stevo.
---------------------------------------------------------------------
Post by Werner GuttmannPost by Werner Guttmannhttp://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>
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
--------------------------------------------------------------------- To
Post by Werner Guttmannhttp://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
Post by Werner Guttmannhttp://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>
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
---------------------------------------------------------------------
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: ***@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