Ákos,
you are not the first to have the idea of combining GeoTools and GeoServer so that Eclipse dependencies are resolved within a single workspace. When I last tried it using an "aggregating pom" to combine all the modules into one super-project, I encountered intractable dependency problems. I think Andrea did as well. This was in 2008 or so; you might have better success (at least now both projects target the same Java version!). See this discussion:
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Aggregation
One of the big problems is that Eclipse has no concept of Maven phases; all dependencies are included whether for the test or compile phases. Making an aggregating pom causes GeoServer modules to depend on transitive GeoTools test dependencies. This causes problems because while Maven is able to version-manage conflicting dependencies, Eclipse is not and just picks the first matching class on the classpath, causing nasty dependency conflicts. This causes Bad Things To Happen. You are also exposed to SPI surprises with different plugins on your classpath in Eclipse compared to in Maven. There are even classes in the code base that exist purely to allow unit tests to succeed in Eclipse. See for example EPSGCRSAuthorityFactory in get-xsd-gml3:
http://jira.codehaus.org/browse/GEOT-3112
Diagnosing test discrepancies between Eclipse and Maven (tests that pass in one but not the other) requires remote debugging:
http://maven.apache.org/plugins/maven-surefire-plugin/examples/debugging.html
Instead of using separate workspaces for GeoTools and GeoServer, I save memory and time by using two Eclipse working sets inside a single workspace:
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Fconcepts%2Fcworkset.htm
GeoServer's dependencies on GeoTools are still resolved through the Maven repository. The way I have GeoServer running from Eclipse recognise a change to a GeoTools module is as described by Justin below; I change into that module's directory and
mvn -o -DskipTests clean install
at the command line and then refresh all projects in Eclipse. Slightly clunky, but it works.
Kind regards,
Ben.
On 09/10/12 21:16, Justin Deoliveira wrote:
Hi Akos,
Other devs do this differently but i generally just keep separate
workspaces for geotools and geoserver. If you have the source jars in
your maven repo (which you can get by running mvn eclipse:eclipse with
-DdownloadSources or by compiling geotools locally) then eclipse will
pick them up and allow you to browse the sources as if they were in the
workspace.
Now when making a change in geotools, to get it picked up you have to:
1. make it in your geotools workspace
2. build the relevant module with maven
3. refresh your geoserver eclipse workspace
I have found that once you get used to this it is not too much overhead.
But again, this is just one way to do it.
That said, the log messages regarding gdal and kakadu you list below are
normal unless you have those native libs installed. So it does appear
that you have a running geoserver. As for not finding the data directory
is it possible you have the GEOSERVER_DATA_DIR set to a bad location? Do
you see any other exceptions on start up?
On Tue, Oct 9, 2012 at 4:27 AM, Ákos Maróy <akos@anonymised.com
<mailto:akos@anonymised.com>> wrote:
Hi,
I wonder if there is a simple & proven way to have both geoserver &
geotools in the same eclipse environment, so that geoserver when ran
from eclipse would use the geotools libraries also from with eclipse?
I tried to set this up by first importing the geotools libraries, using
the mvn eclipse:eclipse command, and then importing geotools.
after this, I imported geoserver basically the same way. now, geoserver
will prefer geotools libraries from the maven repository as opposed to
the ones present in eclipse.
fine, so I deleted the gt-* dependencies from the web-app project, and
added the gt-* projects from eclipse as requirements. this created a
number of dependency issues, and geoserver wouldn't run properly at the
end, for example I get:
Oct 9, 2012 12:19:42 PM
it.geosolutions.imageio.gdalframework.GDALUtilities loadGDAL
WARNING: Failed to load the GDAL native libs. This is not a problem
unless you need to use the GDAL plugins: they won't be enabled.
java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path
Oct 9, 2012 12:19:42 PM it.geosolutions.util.KakaduUtilities loadKakadu
WARNING: Failed to load the Kakadu native libs. This is not a problem
unless you need to use the Kakadu plugin: it won't be enabled.
java.lang.UnsatisfiedLinkError: no kdu_jni in java.library.path
log4j:WARN File option not set for appender [geoserverlogfile].
and then it fails the find the data directory which it previously found,
etc.
so maybe this is quite lame, but is there a simple way to make this
work?
what I want to do is to make changes in the geotools code that is used
in geoserver, and see the effect of these changes. the simplest way I
figured would be to have everything open in eclipse, so I can change,
debug, etc. easily.
Akos
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre