[Geotools-devel] Use of stable versions

pi3orama wrote: > We tried to use stable version. But we met some compilation problems > (it seems caused by losing of "community" or "maven" directories). > Then we find svn version works and we choose it. Now we can work with > it and we don't want another migration. > If you are already using

Re: [Geotools-devel] How to manage so many projects?

We tried to use stable version. But we met some compilation problems (it seems caused by losing of "community" or "maven" directories). Then we find svn version works and we choose it. Now we can work with it and we don't want another migration. If use stable version, which version combination (ge

[Geotools-devel] mvn deploy working; but still randomly fails ...

So using the right command "mvn deploy maven.test.skip=true" sure helps; however we still have a few glitches. Here is a sample error message from run number 1: > Uploading: > http://lists.refractions.net/m2/org/geotools/maven/gt2-jjtree-javacc/2.5-SNAPSHOT/gt2-jjtree-javacc-2.5-SNAPS > HOT.jar

[Geotools-devel] Maven 2.0.8 is working; and yes the directions were correct, jts 1.9.RC6 is uploaded

Gabriel Roldán wrote: > know what? I've deployed back in October using the maven 2.0.5 with dav > support from here: > found > on this page: > > may that h

Re: [Geotools-devel] Going to try maven 2.0.8, and jts 1.9.RC6

know what? I've deployed back in October using the maven 2.0.5 with dav support from here: found on this page:

[Geotools-devel] Going to try maven 2.0.8, and jts 1.9.RC6

I am going to try using 2.0.8 in order to deploy a new copy of jts that has a vastly faster union, and that prepared geometry stuff. I will document this on our user guide, and martin is okay with us kick starting the wiki with the jts word documentation. It looks like the last person to deploy

[Geotools-devel] [jira] Created: (GEOT-1619) Add support for extracting features with versioning attributes

Add support for extracting features with versioning attributes -- Key: GEOT-1619 URL: http://jira.codehaus.org/browse/GEOT-1619 Project: GeoTools Issue Type: Improvement C

Re: [Geotools-devel] How to manage so many projects?

pi3orama wrote: > About the other problem, we don't think we need to follow svn update > because we haven't determined to join geotools/geoserver developer > team or not. We just need workable environment in which we can do our > work, and we think we have built it up. But we decide to do "mvn > in

Re: [Geotools-devel] How to manage so many projects?

It seems very helpful, especially the "fake" pom solution, it may solve our dependencies problem. We have wrote a find and sed script to help us add the geoapi project: $ for file in `find -name ".classpath" -exec grep -l geoapi {} \;` ; do sed s/""/""/g -i $file ; done It is ugly indeed, but

Re: [Geotools-devel] How to manage so many projects?

Good points all. Here are my suggestions: 1) How to get geoserver/geotools linking together not via SNAPSHOT-jar dependencies but via "eclipse-project" dependencies: * Make a "fake" pom that's a parent pom to both GT and GS. * Add two modules to this pom, "geoserver-dir-name" and "geotools-di

Re: [Geotools-devel] How to manage so many projects?

pi3orama wrote: > Hello every one, we (some graduate students) have some problem: > We are trying to do some work on geoserver and geotools. We have > merged geoserver and geotools into a single eclipse workspace (nearly > 100 projects), but then we find other dependence should be take care > about

[Geotools-devel] [jira] Created: (GEOT-1618) Hints prevent creation of lenient OperationAuthorityFactory

Hints prevent creation of lenient OperationAuthorityFactory --- Key: GEOT-1618 URL: http://jira.codehaus.org/browse/GEOT-1618 Project: GeoTools Issue Type: Bug Components: cor

[Geotools-devel] lenient true plus hints fails ... in geotools

So I have boiled this down to a test case that fails in geotools... > public void testSamplePixel() throws Exception { > Map map = new HashMap(); > map.put( Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER, true ); > map.put( Hints.FORCE_STANDARD_AXIS_DIRECTIONS, true ); >

[Geotools-devel] The madness of referencing ...lenient true fails

Is finally making me mad :-( FactorySPI may come out of the box with Java but it is not simple; and in the form we are using it here not understandable; ie it was never intended to have parameters (in the form of hints) or keep functional implementations around to share between threads. Seem t

Re: [Geotools-devel] The madness of referencing ... and the end of epsg-wkt ?

Jody Garnett wrote: > So after a long debug session with notes I think I finally can > understand what has gone wrong with referening on trunk. Okay I am back to knowing nothing ... I have been able to sort out the pom.xml dependencies so that: - epsg-wkt no longer depends on main (it only needs