[Geoserver-devel] A bit of warning to those trying to setup a unified geotools/geoserver eclipse workspace

GeoServer GeoServer Developer
1

Hi,
these days I've tried to setup a single eclipse workspace where
all the geoserver projects do depend directly on the needed geotools
projects. This would speed up development, because one could simply
work directly in Eclipse, without having to build and refresh the
modified gt2 modules in order to make the geoserver ones see them
(which is what you get when you run mvn eclipse:eclipse separately
on the two modules).

Well, in theory the recipe is simple:
*) checkout the two projects side by side
*) create a fictitious super-pom that has geoserver and geotools
    as modules
*) run mvn eclipse:eclipse from that root

In practice, this does not work. First I had to upgrade commons
logging, otherwise GeoServer run from the "Start" java program
would crash during startup (due to silly dependencies the old
commons logging had).
After fixing that, GeoServer starts, but other issues are waiting.
Test running from Eclipse start to fail (and they would not from
maven, or using the old separate mvn eclipse:eclipse approach).

Little investigation shows the problem lies in some gt2 modules
still using epsg-wkt for tests. This ends up in the eclipse
project classpath, and transitively up to the geoserver
unit tests and Start program. This means both epsg-wkt and
epsg-hsql are in the classpath, and hell doors open.

To solve that all projects still using epsg-wkt for testing
would have to be upgraded to epsg-hsql... but I'm a little
discouraged, this "time saving" thing is ending up being quite
a time sink instead. What awaits me when the epsg-xxxx issue
is fixed? :wink:

Did anyone successfully managed to have everything working?
If not, at least you know what the problem is, and you won't
have to go thru the same debugging as me to find out why.
Cheers
Andrea

2

Andrea,

I tried this as well, using an aggregate POM so that all Maven modules
are processed by eclipse:eclipse in one run and all GeoServer/GeoTools
references are resolved intra-workspace. This caused substantial
problems debugging in Jetty from Eclipse, because conflicting transitive
dependencies are included by maven-eclipse-plugin, e.g. servlet-api 2.3
and 2.4 (there are other examples). With separate workspaces, Eclipse
references are resolved in the Maven repository, which acts as a
dependency "firewall", protecting from conflicts.

I think the core problem is that the GS/GT2 POMs are not written with
aggregation in mind. Fixing these or putting explicit exclusions in the
aggregate POM will take a little work (as least for me, a Maven newbie).
As an aside, I also found some problems in geoserver/community that
suggest that maven-eclipse-plugin might not be honouring exclusions
(explicitly excluded projects ending up on my runtime classpath). Using
exclusions to fix POMs that should have optional dependencies might thus
not work with maven-eclipse-plugin.

The transitive dependencies problem has come up on these
open-season-on-Maven pages (previously mentioned on the list):
http://java.dzone.com/news/draft-workarounds-five-maven-2
http://www.infoq.com/news/2008/01/maven-debate

I have fallen back to using separate workspaces, as documented here:
https://www.seegrid.csiro.au/twiki/bin/view/Infosrvices/GeoserverDevelop
mentSetup

A single workspace for GS+GT2 would be ideal!

Regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Exploration and Mining
26 Dick Perry Avenue, Kensington WA 6151, Australia

-----Original Message-----
From: geoserver-devel-bounces@lists.sourceforge.net
[mailto:geoserver-devel-bounces@lists.sourceforge.net] On Behalf Of
Andrea Aime
Sent: Wednesday, 13 February 2008 4:09 AM
To: Geoserver-devel
Subject: [Geoserver-devel] A bit of warning to those trying to setup a
unified geotools/geoserver eclipse workspace

Hi,
these days I've tried to setup a single eclipse workspace where
all the geoserver projects do depend directly on the needed geotools
projects. This would speed up development, because one could simply
work directly in Eclipse, without having to build and refresh the
modified gt2 modules in order to make the geoserver ones see them
(which is what you get when you run mvn eclipse:eclipse separately
on the two modules).

Well, in theory the recipe is simple:
*) checkout the two projects side by side
*) create a fictitious super-pom that has geoserver and geotools
    as modules
*) run mvn eclipse:eclipse from that root

In practice, this does not work. First I had to upgrade commons
logging, otherwise GeoServer run from the "Start" java program
would crash during startup (due to silly dependencies the old
commons logging had).
After fixing that, GeoServer starts, but other issues are waiting.
Test running from Eclipse start to fail (and they would not from
maven, or using the old separate mvn eclipse:eclipse approach).

Little investigation shows the problem lies in some gt2 modules
still using epsg-wkt for tests. This ends up in the eclipse
project classpath, and transitively up to the geoserver
unit tests and Start program. This means both epsg-wkt and
epsg-hsql are in the classpath, and hell doors open.

To solve that all projects still using epsg-wkt for testing
would have to be upgraded to epsg-hsql... but I'm a little
discouraged, this "time saving" thing is ending up being quite
a time sink instead. What awaits me when the epsg-xxxx issue
is fixed? :wink:

Did anyone successfully managed to have everything working?
If not, at least you know what the problem is, and you won't
have to go thru the same debugging as me to find out why.
Cheers
Andrea

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

Ben.Caradoc-Davies@anonymised.com ha scritto:

Andrea,

I tried this as well, using an aggregate POM so that all Maven modules
are processed by eclipse:eclipse in one run and all GeoServer/GeoTools
references are resolved intra-workspace. This caused substantial
problems debugging in Jetty from Eclipse, because conflicting transitive
dependencies are included by maven-eclipse-plugin, e.g. servlet-api 2.3
and 2.4 (there are other examples). With separate workspaces, Eclipse
references are resolved in the Maven repository, which acts as a
dependency "firewall", protecting from conflicts.

These I solved by upgrading the commons-logging dependency, the old
one depended on servlet-api 2.3, the new one does not. This allowed
me to start Jetty from Eclipse (the change is committed in gt2, both
branches).

I think the core problem is that the GS/GT2 POMs are not written with
aggregation in mind. Fixing these or putting explicit exclusions in the
aggregate POM will take a little work (as least for me, a Maven newbie).
As an aside, I also found some problems in geoserver/community that
suggest that maven-eclipse-plugin might not be honouring exclusions
(explicitly excluded projects ending up on my runtime classpath). Using
exclusions to fix POMs that should have optional dependencies might thus
not work with maven-eclipse-plugin.

Now exclusions should be honored, the problem is another: eclipse:eclipse generates a single project out of your source and test,
adding both standard and test scope dependencies.
The eclipse project dependency mechanism has no idea of the difference,
meaning projects will see all the jars that project they depend on
use. epsg-wkt is used only by a few modules for testing, but in ends
up being in the single classpath eclipse has.
Changing the modules to use epsg-hsql requires some work as well,
since epsg-wkt defeaults to lon/lat oriented crs, whilst epsg-hsql
does the opposite.

After that, more problems could arise, even if they don't, they
could pop up as a side effect of someone testing a module and
needing an extra jar for testing that ends up breaking geoserver.

I checked, the libraries aren't officially exported, but nevertheless, they end up becoming part of the runtime classpath somehow (I mean,
they are not even listed graphically, but a simple test can show
if espg-wkt is in the runtime classpath, and it is...).

For example, look at the gt2-validation library path. epsg-wkt
is not among the direct dependencies. You cannot see it in the
build-path/order and export list. Yet, if you try to run
a program from there and see the classpath of that program
in the "run as" dialog, you'll see that espg-wkt is part of
the classpath all rigth (it comes from gt2-postgis, which
depends on it for testing).

As I see it, this looks like being a solid limitation of
the project dependency model in eclipse, that is, you cannot
say a project depends on another one just for the
sake of testing (and thus, the dependency should not
cascade onto the other projects).

Hmmm... projects and jars... I just tried removing espg-wkt
from the build and rerun mvn eclipse:eclipse, so that it becomes a jar dependency instead of a project dependency. No luck. It still
ends up being part of the runtime classpath in gt2-validation,
even if the gt2-postgis module that depends directly on it
does not export it. Sigh...

The only cure I can think of, besides trying to fix the gt2
test dependencies, would be make eclipse:eclipse generate
two projects for each module, one source, one test...

Cheers
Andrea

4

Andrea Aime wrote:

Now exclusions should be honored, the problem is another: eclipse:eclipse generates a single project out of your source and test,
adding both standard and test scope dependencies.
The eclipse project dependency mechanism has no idea of the difference,
meaning projects will see all the jars that project they depend on
use.

I think that the underlying problem is that Eclipse has no way of expressing an exclusion when applied to a project that is dependency in the same workspace. It can exclude jars from the classpath, but not transitive project dependencies.

For example, in the community profile we have the web-c and wfs-c forks of web and wfs respectively. The POM for web-c has dependencies on wfs-c and on wms. The dependency on wms excludes wfs, because it conflicts with wfs-c. If wfs is included when running web-c Start (jetty launcher), Bad Things Happen.

To see this in 1.6.x/geoserver

     mvn -Pcommunity -Dmaven.test.skip eclipse:clean clean install eclipse:eclipse

Examining the .classpath and .project for web-c shows that wms is a dependency. These files cannot record the exclusions. Running web-c Start and examining the runtime classpath shows the wfs project classes on the classpath ahead of wfs-c, and the aforementioned Bad Things Happen.

I think that this is the same thing that happens when I try to include all GS and GT2 projects in one workspace. Not just the inability of Eclipse to recognise the difference between compile and test dependencies, but an incompatibility between the Eclipse and Maven dependency models caused by Eclipse's inability to honour Maven's exclusions on transitive dependencies.

epsg-wkt is used only by a few modules for testing, but in ends
up being in the single classpath eclipse has.
Changing the modules to use epsg-hsql requires some work as well,
since epsg-wkt defeaults to lon/lat oriented crs, whilst epsg-hsql
does the opposite.

After that, more problems could arise, even if they don't, they
could pop up as a side effect of someone testing a module and
needing an extra jar for testing that ends up breaking geoserver.

I checked, the libraries aren't officially exported, but nevertheless, they end up becoming part of the runtime classpath somehow (I mean,
they are not even listed graphically, but a simple test can show
if espg-wkt is in the runtime classpath, and it is...).

For example, look at the gt2-validation library path. epsg-wkt
is not among the direct dependencies. You cannot see it in the
build-path/order and export list. Yet, if you try to run
a program from there and see the classpath of that program
in the "run as" dialog, you'll see that espg-wkt is part of
the classpath all rigth (it comes from gt2-postgis, which
depends on it for testing).

As I see it, this looks like being a solid limitation of
the project dependency model in eclipse, that is, you cannot
say a project depends on another one just for the
sake of testing (and thus, the dependency should not
cascade onto the other projects).

Hmmm... projects and jars... I just tried removing espg-wkt
from the build and rerun mvn eclipse:eclipse, so that it becomes a jar dependency instead of a project dependency. No luck. It still
ends up being part of the runtime classpath in gt2-validation,
even if the gt2-postgis module that depends directly on it
does not export it. Sigh...

The only cure I can think of, besides trying to fix the gt2
test dependencies, would be make eclipse:eclipse generate
two projects for each module, one source, one test...

Cheers
Andrea

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia