Thank you for your reply. I think we have combine geotools and
geoserver successfully. We use eclpse:eclipse maven plugin and import
every geoserver and geotools projects into a single eclipse workspace.
But we have to change every geoserver's project dependency about
geotools manully, from maven "
Thanks Saul; added to the developers guide:
- http://docs.codehaus.org/display/GEOT/2.5.8+Maven+Eclipse+Plugin+Goals
> A really important part of working with geotools/geoserver is to use
> maven's "eclipse:eclipse" plugin/goal.
>
> So start with nothing in your eclipse workspace (delete all projec
A really important part of working with geotools/geoserver is to use
maven's "eclipse:eclipse" plugin/goal.
So start with nothing in your eclipse workspace (delete all projects you
have in eclipse, but leave the svn checkout)
Then do "mvn clean install" in the root geotools directory (optionally
The combination of eclipse and maven works very well. I usually build
most things as needed in maven; and work on one code base at a time in
Eclipse. I have a workspace set up for each project (geoapi / geotools /
geoserver / udig) and sometimes a couple of workspaces for the different
branches
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, like geoapi and geowidge
Jody Garnett wrote:
> This brings up the last reason to make milestone releases; to make sure
> we can still release software :-)
>
So I rolled back the clock to try and deploy from GeoTools 2.2.x (which
I am sure worked with maven 2.0.5 recently). Looks like
http://lists.refractions.net/m2
Erik Løvlie wrote:
> Ok, that is good to know. But my point was that if there was a need to
> have a method to check if a change needs to be written to disk, then I
> think it should not have been the equals method. Because the equals
> method is used to check for logical equality, not necessari
Rendering of rotated tiled coverages
Key: GEOT-1617
URL: http://jira.codehaus.org/browse/GEOT-1617
Project: GeoTools
Issue Type: Improvement
Components: core render
Environment: windows
RetypingFeatureCollection returns wrong schema
--
Key: GEOT-1616
URL: http://jira.codehaus.org/browse/GEOT-1616
Project: GeoTools
Issue Type: Improvement
Components: core main
Affects
Ok, that is good to know. But my point was that if there was a need to
have a method to check if a change needs to be written to disk, then I
think it should not have been the equals method. Because the equals
method is used to check for logical equality, not necessarily exact.
I am not saying
DijkstraIterator members private to protected
-
Key: GEOT-1615
URL: http://jira.codehaus.org/browse/GEOT-1615
Project: GeoTools
Issue Type: Wish
Components: ext graph
Affects Versions
I think this may of already been done on trunk Erik.
Jody
> Yes, but in that case it would be better in my opinion to supply a
> method "equalsExact" like JTS, instead of doing this strict check in
> the overridden equals method.
>
> Most datastructures use the equals method somehow (Quadtree,
Yes, but in that case it would be better in my opinion to supply a
method "equalsExact" like JTS, instead of doing this strict check in the
overridden equals method.
Most datastructures use the equals method somehow (Quadtree, ArrayList,
HashMap, etc), and they run much slower than they need to
13 matches
Mail list logo
