Chris Holmes a écrit :
First cruise control seems to be spitting failure messages at us, and
when I do 'maven build' I get a bunch of compile errors on main,
Trunk build fine for me too, both using Maven 1 and Maven 2. Could you
tell us about the error message you get?
Note that because of the new module addition (referencing, coverage,
api), "maven clean" will not work until you get a successfull "maven
install". It seems to be a kind of Maven bug to me. Cruise Control fails
exactly for this reason (it try to performs a "maven clean" before
"maven install"). It need a manual "maven install" (without "maven
clean"), but I believe that only James has administrator rights for
performing this task. As long as this task is not done, Cruise Control
will still broken.
when I do 'maven jar:install' in a module, I don't seem to get the
tests running any more? Is that intentional? How do I get them to
run?
The tests should continue to be run... Which module did you tried?
Also, I'm a bit in fear of this module split. From what I see now we
have 'api', which sounds good, bring back the old 'core', get
everything shifted to GeoAPI. But, uh, it _depends_ on coverage? Oh
wait, I think it doesn't actually, it's just in the project.xml?
API doesn't depends on coverage. I guess that the coverage dependency in
project.xml is a remanescence of a copy-and-paste from main (I'm not the
one who did the api split). Note that pom.xml (the Maven 2 project file)
do not contains this coverage dependency.
I maintain the Maven 2 build, but I do not maintain the Maven 1 build
and really do not want to put any energy on it (it seems a little bit
chaotic to me). In the Maven 2 build, I put some energy in trimming down
the dependencies, including for the new 'api' module.
I would like to move as much as we can from 'api' module to geoapi at
some later stage. But the GeoAPI process is slower than Geotools, which
is in my understanding the main reason why 'api' exists.
I have not checked why 'api' depends on 'referencing'. I suspect that
yours hypothesis is right (maybe it depends of org.geotools.factory). If
this is true, we could move the org.geotools.factory package somewhere
else. But I would rather investigate if there is anyway to completly
avoid a 'org.geotools.factory' dependency in 'api'. If the 'api' module
is only about interfaces, it should not contains any implementation. And
if it doesn't contains any implementation, then it shouldn't need to
look for factories.
Martin.
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_idv28&alloc_id845&op=click
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
