Re: [Geotools-devel] Trunk broken? and fear of module split

[Martin D. <mar...@no...>]

Chris Holmes a =E9crit :
> 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=20
tell us about the error message you get?

Note that because of the new module addition (referencing, coverage,=20
api), "maven clean" will not work until you get a successfull "maven=20
install". It seems to be a kind of Maven bug to me. Cruise Control fails=20
exactly for this reason (it try to performs a "maven clean" before=20
"maven install"). It need a manual "maven install" (without "maven=20
clean"), but I believe that only James has administrator rights for=20
performing this task. As long as this task is not done, Cruise Control=20
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=20
project.xml is a remanescence of a copy-and-paste from main (I'm not the=20
one who did the api split). Note that pom.xml (the Maven 2 project file)=20
do not contains this coverage dependency.

I maintain the Maven 2 build, but I do not maintain the Maven 1 build=20
and really do not want to put any energy on it (it seems a little bit=20
chaotic to me). In the Maven 2 build, I put some energy in trimming down=20
the dependencies, including for the new 'api' module.

I would like to move as much as we can from 'api' module to geoapi at=20
some later stage. But the GeoAPI process is slower than Geotools, which=20
is in my understanding the main reason why 'api' exists.

I have not checked why 'api' depends on 'referencing'. I suspect that=20
yours hypothesis is right (maybe it depends of org.geotools.factory). If=20
this is true, we could move the org.geotools.factory package somewhere=20
else. But I would rather investigate if there is anyway to completly=20
avoid a 'org.geotools.factory' dependency in 'api'. If the 'api' module=20
is only about interfaces, it should not contains any implementation. And=20
if it doesn't contains any implementation, then it shouldn't need to=20
look for factories.

	Martin.