I have what I hope is a reasonable question:
Why SWT with JFace? Is there some reason that combination works well?
The reason I'm asking is because I am starting to work on building a web
version of what I created in Swing, and I'm not sure of the best
approach. I want to skip past Applets and
Chris Holmes a écrit :
> I actually explicitly raised DB2 to Jody as one that should perhaps go
> in 'supported', since David's been providing great support whenever
> needed. But I guess that didn't make it's way back to the steering
> document.
I will move the "db2" module back to plugin the
I actually explicitly raised DB2 to Jody as one that should perhaps go
in 'supported', since David's been providing great support whenever
needed. But I guess that didn't make it's way back to the steering
document.
Chris
Martin Desruisseaux wrote:
David Adler a écrit :
What does "unsuppor
My understanding was that the oracle distribution license, which the
oracle jars are distributed under, are actually fine for us to
distribute (indeed, such is the name of the license), as long as we meet
the terms. Which includes posting the terms when we distribute it. It
even has a special
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061031183937Lbuild.110
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integr
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061031182911
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated techn
Hi Marc,
Over the last year you have suggested I look at the oracle sdoapi jars.
I have started up my oracle experiment again (unsupported/oracle) and am
attempting to set things up in the manner you suggest.
Paul and I have been in contact with your friend Xavier (although I
missed him at FOS
Martin Desruisseaux wrote:
> David Adler a écrit :
>
>> What does "unsupported" mean and where are the modules going?
>>
>
> My understanding is that they still part of Geotools build (from a Maven user
> point of view, there is no difference; the artifactID still "gt2-db2"), but
> the
>
Ok, but I still dont understand why you are against changing the method
name from getIDs to getIdentifiers ?
Jody Garnett wrote:
> Your second idea works, and I carefully defined Identifier.toString() to
> be the textual representation of the identifier so you
> should be good.
>
> Jody
>> This
There is the list:
http://svn.geotools.org/geotools/trunk/gt/modules/unsupported
If a module should not be there, please let me know. I would be glad to move it
to its right place, if peoples feel that the procedure for that as suggested in
http://docs.codehaus.org/display/GEOT/Supporting+your+
Your second idea works, and I carefully defined Identifier.toString() to
be the textual representation of the identifier so you
should be good.
Jody
> This still doesn't help me. I will still get a bunch of exceptions with
> client code trying to cast to String. The whole point of changing the
>
David Adler a écrit :
> What does "unsupported" mean and where are the modules going?
My understanding is that they still part of Geotools build (from a Maven user
point of view, there is no difference; the artifactID still "gt2-db2"), but the
risk may be a little bit higher than "supported" mod
This still doesn't help me. I will still get a bunch of exceptions with
client code trying to cast to String. The whole point of changing the
method name is that i could hunt down all those instances, and as a
client I know where things will break, as you say getting the compiler
to help me.
This
David Adler wrote:
> I haven't been following the discussion on this.
> What does "unsupported" mean and where are the modules going?
>
Unsupported means that the modules are not meeting library standards (QA
and Docs for the most part). Martin/David DB2 is in use (uDig is
shipping with DB2 su
I haven't been following the discussion on this.
What does "unsupported" mean and where are the modules going?
Regards,
David (DB2 plug-in supporter)
At 11:11 AM 10/31/2006, Martin Desruisseaux wrote:
>The modules listed in GTSteering document as "unsupported" are:
>
>arcsde
>db2
>directory
>eps
Justin Deoliveira wrote:
> Jody Garnett wrote:
>
>> To be clear, both GeoTools and GeoAPI assumed strings would make good
>> identifiers.
>> The filter specification:
>> a) strongly types identifier (FeatureId, GMLObjectId, RecordId, ...)
>> b) allows for non String, or compound identifiers (ID
Jody Garnett wrote:
> To be clear, both GeoTools and GeoAPI assumed strings would make good
> identifiers.
> The filter specification:
> a) strongly types identifier (FeatureId, GMLObjectId, RecordId, ...)
> b) allows for non String, or compound identifiers (ID and VERSION anyone?)
>
> Justin fo
To be clear, both GeoTools and GeoAPI assumed strings would make good
identifiers.
The filter specification:
a) strongly types identifier (FeatureId, GMLObjectId, RecordId, ...)
b) allows for non String, or compound identifiers (ID and VERSION anyone?)
Justin for your first cut do you want to jus
This is a good question Martin, two ways to think about it:
- we should keep it in "unsupported" until it passes QA and
documentation requirements
- it is core technology that needs to be supported ...
So the only person who can answer this is the Justin (as the module
maintainer)
Jody
> The new
The new "xml-sld" module (added yesterday) is not listed in the GTSteering
document. Should it live in the "extension" or in the "unsupported" directory?
Martin
-
Using Tomcat but need to do more? Need to support web
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061031122048Lbuild.107
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integr
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061031115815
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated techn
Hi all,
Issue with the new geoapi identifier stuff with regard to getting
geotools on board with it.
Right now, the geotools filter implementations implement the geoapi
interfaces. The semantics of FeatureId have changed, so the geotools
FidFilter interface needs to implement Id now, instead of F
The modules listed in GTSteering document as "unsupported" are:
arcsde
db2
directory
epsg-ext-esri
geomedia
geometryless
gml
hsql
mif
mysql
oraclespatial
referencing3D
tiger
vpf
oracle
go
xml
xml-filter
xml-gml2
xml-gml3
jpox
portrayal
viewport
I will move those modules soon unless someone object
I just added it, if you are going to throw all the other xml modules in
unsupported go ahead with that one too.
Martin Desruisseaux wrote:
> The new "xml-sld" module (added yesterday) is not listed in the GTSteering
> document. Should it live in the "extension" or in the "unsupported" directory?
Andrea Aime a écrit :
>> Since I do not use Eclipse (I use Netbeans, which doesn't add any file
>> in our workspace), I don't know if there is other directories that
>> need "svn:ignore". Please let me know if there is any.
>
> I thought Netbeans added its own Ant build files, no?
Yes, but not
Justin Deoliveira a écrit :
> I also notice that you set the svn:ignore for .classpath and .project
> files. However the .settings directory seems to have been missed.
Oups! Fixed now.
Since I do not use Eclipse (I use Netbeans, which doesn't add any file in our
workspace), I don't know if there
Martin Desruisseaux ha scritto:
> Justin Deoliveira a écrit :
>> I also notice that you set the svn:ignore for .classpath and .project
>> files. However the .settings directory seems to have been missed.
>
> Oups! Fixed now.
>
> Since I do not use Eclipse (I use Netbeans, which doesn't add any fi
28 matches
Mail list logo
