Thanks Martin you have helped us here again.. Thanks again
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.
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).
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.
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).
Martin.
-------------------------------------------------------
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=k&kid0944&bid$1720&dat1642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
-------------------------------------------------------
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&kid=110944&bid=241720&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
