Martin Desruisseaux wrote:
Jody Garnett a écrit :
We found that the number of dependencies in the "parent" pom actually
masks the real needs of a module like referencing.
According to the current sturcture, referencing needs batik for example.
Referencing do not need batik, I'm pretty sure of that. Unless I
didn't noticed some change recently commited by somebody else. The
current pom.xml structure do *not* said that referencing need batik.
More details below.
I understand that it is nice to have a single place to go to update
version numbers, is there anything else we can do?
We are going to try to remove all dependencies from the parent pom,
and then count on transitive dependencies to carry things forward.
Are you sure? The parent pom.xml do not declares any dependency.
Everything in the parent pom.xml are <dependencyManagement>, not
<dependencies> (this is not the same). <dependencyManagement> means
"if this dependency is used in a child pom.xml, then the version
number shall be XXX", but it does *not* add this dependency as long as
it doesn't appears in a <dependency> section in a child pom.xml.
Wow - you are so right! We tested by removing the vecmath dependency
and watching it still compile - apparently the test cases do not use it...
So the fact that referencing uses JTS would mean that API would not
need to say so explicitly.
referencing do not need JTS (or it did in 2.2, but is doesn't need it
anymore in 2.3).
Okay we can update that then - I am making a picture and will send it
out before we commit anything.
The goal here is to have the GeoServer Data module that can depend on
main + data plugins and not get a dependency on batik.
The fact that the GeoServer WMS module depends on rendering will
cause batik to be included there.
Hope this make sense, and also the push for maven 2.
Before to make any changes, please make sure that there is no
confusion between <dependencies> and <dependencyManagement>. Again,
the parent pom.xml file do not add any dependency. So main + data
plugins should not have batik dependency, except if batik appears
explicitly in the <dependencies> section in main/pom.xml or
data-plugin/pom.xml.
Got it - and thank you for the explanation.
Are you sure that this is the cause of Maven 2 test failure? Maven 2
were building well two months ago. If the trouble was a wrong
dependency, the code should not compile or the test should fails at
execution time. In current situation, the code compile and the test
are not executed at all (so the failure reason is not a
NoClassDefFoundError).
Sorry Martin, the cause of maven2 failures was the shapefile modeule -
we are on to the next problem - checking the dependencies before getting
GeoServer 1.4.x to use maven 2.
Thanks again for all your help, and I am glad we are finally catching up
with you.
Jody
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
