Á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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > -- Ben Caradoc-Davies <[email protected]> Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
