[Geotools-devel] Strange Build Failure
Hello, I am having a build failure in the render module : [INFO] [INFO] Building Render [INFO]task-segment: [clean, install] [INFO] [INFO] Reloading plugin container for: org.geotools.maven:verifier. The plugin artifact has changed. [INFO] [clean:clean] [INFO] Deleting directory /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/target [INFO] Deleting directory /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/target/classes [INFO] Deleting directory /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/target/test-classes [INFO] Deleting directory /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/target/site [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] snapshot it.geosolutions.imageio-ext:imageio-ext-arcgrid:1.0-SNAPSHOT: checking for updates from refractions [INFO] snapshot it.geosolutions.imageio-ext:imageio-ext-plugin:1.0-SNAPSHOT: checking for updates from refractions [INFO] snapshot it.geosolutions.imageio-ext:imageio-ext:1.0-SNAPSHOT: checking for updates from refractions [INFO] snapshot it.geosolutions.imageio-ext:imageio-ext-customstreams:1.0-SNAPSHOT: checking for updates from refractions [INFO] snapshot it.geosolutions.imageio-ext:imageio-ext-library:1.0-SNAPSHOT: checking for updates from refractions [INFO] [compiler:compile] [INFO] Compiling 95 source files to /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/src/main/java/org/geotools/referencing/piecewise/DefaultDomainElement1D.java:[323,20] wrap(org.geotools.util.Range) in org.geotools.util.NumberRange cannot be applied to (org.geotools.util.NumberRange) /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/src/main/java/org/geotools/referencing/piecewise/DefaultDomainElement1D.java:[323,20] wrap(org.geotools.util.Range) in org.geotools.util.NumberRange cannot be applied to (org.geotools.util.NumberRange) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] I compile with a : java version "1.6.0" OpenJDK Runtime Environment (build 1.6.0-b09) OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode) -- Johann Sorel Company - Geomatys GIS Developer Mail - [EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Strange Build Failure
Not 100% sure, but I believe I had the same issue earlier tonight. Switching to Java 1.5.x appeared to solve it (not ideal, but for my purpose I had to do it anyway). -Arne johann sorel wrote: > Hello, > > > I am having a build failure in the render module : > > [INFO] > > [INFO] Building Render > [INFO]task-segment: [clean, install] > [INFO] > > [INFO] Reloading plugin container for: org.geotools.maven:verifier. The > plugin artifact has changed. > [INFO] [clean:clean] > [INFO] Deleting directory > /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/target > [INFO] Deleting directory > /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/target/classes > [INFO] Deleting directory > /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/target/test-classes > [INFO] Deleting directory > /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/target/site > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] snapshot > it.geosolutions.imageio-ext:imageio-ext-arcgrid:1.0-SNAPSHOT: checking > for updates from refractions > [INFO] snapshot > it.geosolutions.imageio-ext:imageio-ext-plugin:1.0-SNAPSHOT: checking > for updates from refractions > [INFO] snapshot it.geosolutions.imageio-ext:imageio-ext:1.0-SNAPSHOT: > checking for updates from refractions > [INFO] snapshot > it.geosolutions.imageio-ext:imageio-ext-customstreams:1.0-SNAPSHOT: > checking for updates from refractions > [INFO] snapshot > it.geosolutions.imageio-ext:imageio-ext-library:1.0-SNAPSHOT: checking > for updates from refractions > [INFO] [compiler:compile] > [INFO] Compiling 95 source files to > /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/target/classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/src/main/java/org/geotools/referencing/piecewise/DefaultDomainElement1D.java:[323,20] > > wrap(org.geotools.util.Range) in org.geotools.util.NumberRange > cannot be applied to (org.geotools.util.NumberRange extends java.lang.Number>) > > > > /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/src/main/java/org/geotools/referencing/piecewise/DefaultDomainElement1D.java:[323,20] > > wrap(org.geotools.util.Range) in org.geotools.util.NumberRange > cannot be applied to (org.geotools.util.NumberRange extends java.lang.Number>) > > > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > > I compile with a : > java version "1.6.0" > OpenJDK Runtime Environment (build 1.6.0-b09) > OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode) > > > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Strange Build Failure
Arne Kepp a écrit : > Not 100% sure, but I believe I had the same issue earlier tonight. > Switching to Java 1.5.x appeared to solve it (not ideal, but for my > purpose I had to do it anyway). > > -Arne > > johann sorel wrote: >> Hello, >> >> >> I am having a build failure in the render module : >> >> [INFO] >> >> [INFO] Building Render >> [INFO]task-segment: [clean, install] >> [INFO] >> >> [INFO] Reloading plugin container for: org.geotools.maven:verifier. >> The plugin artifact has changed. >> [INFO] [clean:clean] >> [INFO] Deleting directory >> /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/target >> [INFO] Deleting directory >> /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/target/classes >> [INFO] Deleting directory >> /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/target/test-classes >> >> [INFO] Deleting directory >> /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/target/site >> [INFO] [resources:resources] >> [INFO] Using default encoding to copy filtered resources. >> [INFO] snapshot >> it.geosolutions.imageio-ext:imageio-ext-arcgrid:1.0-SNAPSHOT: >> checking for updates from refractions >> [INFO] snapshot >> it.geosolutions.imageio-ext:imageio-ext-plugin:1.0-SNAPSHOT: checking >> for updates from refractions >> [INFO] snapshot it.geosolutions.imageio-ext:imageio-ext:1.0-SNAPSHOT: >> checking for updates from refractions >> [INFO] snapshot >> it.geosolutions.imageio-ext:imageio-ext-customstreams:1.0-SNAPSHOT: >> checking for updates from refractions >> [INFO] snapshot >> it.geosolutions.imageio-ext:imageio-ext-library:1.0-SNAPSHOT: >> checking for updates from refractions >> [INFO] [compiler:compile] >> [INFO] Compiling 95 source files to >> /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/target/classes >> [INFO] >> >> [ERROR] BUILD FAILURE >> [INFO] >> >> [INFO] Compilation failure >> /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/src/main/java/org/geotools/referencing/piecewise/DefaultDomainElement1D.java:[323,20] >> >> wrap(org.geotools.util.Range) in org.geotools.util.NumberRange >> cannot be applied to (org.geotools.util.NumberRange> extends java.lang.Number>) >> >> >> >> /home/sorel/DEV/GEOTOOLS/trunk/modules/library/render/src/main/java/org/geotools/referencing/piecewise/DefaultDomainElement1D.java:[323,20] >> >> wrap(org.geotools.util.Range) in org.geotools.util.NumberRange >> cannot be applied to (org.geotools.util.NumberRange> extends java.lang.Number>) >> >> >> [INFO] >> >> [INFO] For more information, run Maven with the -e switch >> [INFO] >> >> >> I compile with a : >> java version "1.6.0" >> OpenJDK Runtime Environment (build 1.6.0-b09) >> OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode) not ideal like you say :-( I have other projects that needs 1.6, It will be hell if I have to switch between JDK. I'll way for a better solution. regards -- Johann Sorel Company - Geomatys GIS Developer Mail - [EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Strange Build Failure
Arne Kepp ha scritto: > Not 100% sure, but I believe I had the same issue earlier tonight. > Switching to Java 1.5.x appeared to solve it (not ideal, but for my > purpose I had to do it anyway). Hmm, gt2 trunk is meant to be built with java 1.5 anyways. The error seem to be due to a different handling in generics between 1.5 and 1.6? Do anyone know if they changed anything in 1.6 about that? Cheers Andrea - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1800) Expose filter and expression encoding abilities thru SQLBuilder
Expose filter and expression encoding abilities thru SQLBuilder --- Key: GEOT-1800 URL: http://jira.codehaus.org/browse/GEOT-1800 Project: GeoTools Issue Type: Improvement Reporter: Andrea Aime Fix For: 2.4.3, 2.5-M2 This boils down to adding an expression encoding abilities to the SQLBuilder, so that users can build their own special queries (in particular, for the select part). For completeness, we should also expose a method that allows for encoding a filter... this would make the interface more consistent and would allow the creation of "group by" and "having" parts of a sql queries in the future -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Strange Build Failure
Andrea Aime a écrit :
> Hmm, gt2 trunk is meant to be built with java 1.5 anyways.
> The error seem to be due to a different handling in generics between
> 1.5 and 1.6? Do anyone know if they changed anything in 1.6 about that?
Yes there is some difference between 1.5 and 1.6 in corner cases, but from my
experience with NumberRange 1.6 is usually better. For example:
>
NumberRange convertAndCast(Range range, Class type) {
// Some processing
return new NumberRange(type, range);
}
Is legal but fail with Java 1.5 will it is correcly accepted by Java 1.6. But I
admit that this is convolved case.
I have not hear about the opposite way around however (code accepted by Java
1.5
but failing with Java 1.6)...
A temporary workaround (until someone resolve the case) is to force a
unparameterized cast:
wrap((Range) range);
Break parameterized type safety, but at least fix the build in the maintime...
Martin
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] KML Writer in Geotools
Hi Justin, Thanks for putting so much effort into this. I tried to run my prior code for KML encoding (see snippet in one of the emails below), but still do not get any KML stuff generated. I am using gt-2.5 SNAPSHOTs from gt's maven repository and I am not sure, if they are up-to-date. For kml I include the gt2-xml-kml dependency into my POM. Thanks for any hint. Theodor > -Original Message- > From: Justin Deoliveira [mailto:[EMAIL PROTECTED] > Sent: Monday, May 05, 2008 8:32 PM > To: Theodor Foerster > Cc: GeoTools Devel List > Subject: Re: [Geotools-devel] KML Writer in Geotools > > Hi Theodor, > > Perhaps you are thinking about GeoServer. We have some KML > writing stuff there.. but its not part of geotools, and its > not GTXML based. However, i have been working on a parser in > geotools, and that is what is there. > > I added basic support for writing over the weekend, i just > committed it to geotools trunk. If you try it out now... you > should get something. > There are no styles hooked up yet though however. > > -Justin > > Theodor Foerster wrote: > > Hi Justin, > > Thanks for your answer. However, I am a bit confused, as I > read in one > > of the previous posts about KML, that some facilities for > writing KML > > would exist. Or did I understood that wrongly? Anyway, when > would you > > plan to put some time for it. We are thinking of migrating > to geotools > > 2.5 and could support you with testing. > > > > Thanks & best regards > > > > > >> -Original Message- > >> From: Justin Deoliveira [mailto:[EMAIL PROTECTED] > >> Sent: Friday, May 02, 2008 8:25 PM > >> To: Theodor Foerster > >> Cc: GeoTools Devel List > >> Subject: Re: [Geotools-devel] KML Writer in Geotools > >> > >> Hi Theodor, > >> > >> The kml stuff in geotools as of now only does parsing... > no encoding. > >> Adding encoding would be too much work... but a little. I > can try to > >> slot it into some volunteer time... should only take me a few > >> hours... > >> (famous last words :)) > >> > >> -Justin > >> > >> Theodor Foerster wrote: > >>> Hi, > >>> We are struggeling with KML support in GT 2.5. We got the > >> parsing of > >>> GML working and are now trying to write those GT features > >> back as KML > >>> (using the GTXML framework). Is there any possibility to > >> get it working? > >>> Please find attached our current experimental code. > >>> > >>> Thanks for your help > >>> > >>> Theodor > >>> > >>> BTW: Why does the Parser (configured with GMLConfiguration > >> and a WFS > >>> getFeature result as input) return a HashMap and not a > >>> FeatureCollection, as expected. > >>> > >>> SNIPPET: > >>> SimpleFeature sf = ... > >>> org.geotools.xml.Configuration kmlconfiguration = new > >>> org.geotools.kml.KMLConfiguration(); > >>> org.geotools.xml.Encoder encoder = new org.geotools.xml.Encoder( > >>> kmlconfiguration ); encoder.encode(sf, KML.kml, System.out); > >>> > >>> ITC, Enschede > >>> Department of Geo Information Processing PO. Box 6 7500 AA > >> Enschede > >>> the Netherlands International Institute for > Geo-Information Science > >>> and Earth Observation (ITC) Chamber of Commerce: 410 27 560 > >>> > >>> E-mail disclaimer > >>> The information in this e-mail, including any attachments, > >> is intended for the addressee only. If you are not the intended > >> recipient, you are hereby notified that any disclosure, copying, > >> distribution or action in relation to the content of this > information > >> is strictly prohibited. If you have received this e-mail > by mistake, > >> please delete the message and any attachment and inform > the sender by > >> return e-mail. ITC accepts no liability for any error or > omission in > >> the message content or for damage of any kind that may arise as a > >> result of e-mail transmission. > >>> > >> > - > >> - > >>> --- This SF.net email is sponsored by the 2008 JavaOne(SM) > >> Conference > >>> Don't miss this year's exciting event. There's still time > >> to save $100. > >>> Use priority code J8TL2D2. > >>> > >> > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.co > >> m > >>> /javaone ___ > >>> Geotools-devel mailing list > >>> Geotools-devel@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel > >>> > >>> > >>> > >> > >> -- > >> Justin Deoliveira > >> The Open Planning Project > >> [EMAIL PROTECTED] > >> > > International Institute for Geo-Information Science and Earth > > Observation (ITC) Chamber of Commerce: 410 27 560 > > > > E-mail disclaimer > > The information in this e-mail, including any attachments, > is intended for the addressee only. If you are not the > intended recipient, you are hereby notified that any > disclosure, copying, distribution or action in relation to > the content of this information is strictly prohibited. If > y
[Geotools-devel] Mvn 2.0.9 transition
Hey all, Has everyone who cares tested their build with the pom.xml from JIRA 1780? http://jira.codehaus.org/browse/GEOT-1780 If no one objects, we'll plan to apply it next week. --adrian - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1801) FilterCapabilities.support(Filter) does not check the expressions used in the filters
FilterCapabilities.support(Filter) does not check the expressions used in the
filters
-
Key: GEOT-1801
URL: http://jira.codehaus.org/browse/GEOT-1801
Project: GeoTools
Issue Type: Bug
Components: core filter
Affects Versions: 2.5-M1, 2.4.2
Reporter: Andrea Aime
Fix For: 2.4.3, 2.5-M2
This may lead to declaring a filter as supported when it internally uses a
function that's not supported. For example, the following test
public void testFunction() throws Exception {
PropertyIsEqualTo equal = ff.equal(ff.property("col"),
ff.function("abs", ff.literal(5)), false);
SQLEncoder encoder = new SQLEncoder();
assertTrue(encoder.getCapabilities().fullySupports(equal));
encoder.encode(equal);
}
breaks when trying to encode the equal filter, whilst in theory it should break
in the assertTrue (the filter is not actually fully supported at all...)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1802) FilterToSql cannot encode a simple expression like "attribute + 5"
FilterToSql cannot encode a simple expression like "attribute + 5" -- Key: GEOT-1802 URL: http://jira.codehaus.org/browse/GEOT-1802 Project: GeoTools Issue Type: Bug Affects Versions: 2.4.3, 2.5-M2 Reporter: Andrea Aime Fix For: 2.4.3, 2.5-M2 The result is going to be "attribute null '5'" instead. And once that is fixed, the result is still "attribute + '5'". When the encoder cannot guess the type it should avoid turning it into a string, no? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] SqlBuilder improvements report
Hi, so I've been working on adding support to SqlBuilder for encoding plain filters and plain expressions. This made me have a look around in the filter encoding stuff... here is some feedback: * SQLEncoderException is deprecated but everything is throwing it anyways, with a reminder to throw FilteToSqlException instead once SQLEncoder is gone. Hmm... why a "deprecate, subclass and replace" approach hasn't been used instead? Changing the exception thrown is going to break the API once more... * there is something strange going on in the filter encoders... they do check if the filter is fully supported before proceeding, but that in turn does not check whether the expressions inside the filter are supported, leading to a situation where one could break encoding by passing a supported filter that uses an unsupported function. I've opened a jira for this: http://jira.codehaus.org/browse/GEOT-1801 * lucky as I am the unit tests I added to check expression encoding uncovered other bugs in FilterToSql: http://jira.codehaus.org/browse/GEOT-1802 Cheers Andrea - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] GML datastore
Hi, Is the GML datastore on trunk still essentially the same code as on 2.2 or has it been upgraded to Justin's new parser? Jesse - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1803) Off by one error in GML constraints checking
Off by one error in GML constraints checking
Key: GEOT-1803
URL: http://jira.codehaus.org/browse/GEOT-1803
Project: GeoTools
Issue Type: Bug
Components: data gml
Affects Versions: 2.2.2
Reporter: Jesse Eichar
Assignee: Jesse Eichar
Priority: Minor
Fix For: 2.2.3
int decimals = val.length() - val.indexOf(".");
int maxDec = Integer.parseInt(constraints[i].getValue());
if (decimals > maxDec) {
throw new SAXException("Too many decimal places");
}
is wrong should be:
int decimals = val.length() - 1 - val.indexOf(".");
int maxDec = Integer.parseInt(constraints[i].getValue());
if (decimals > maxDec) {
throw new SAXException("Too many decimal places");
}
This is lines:
273 in SimpleTypeGT.java
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1804) CoordType doesn't work
CoordType doesn't work
--
Key: GEOT-1804
URL: http://jira.codehaus.org/browse/GEOT-1804
Project: GeoTools
Issue Type: Bug
Components: data gml
Affects Versions: 2.2.2
Reporter: Jesse Eichar
Assignee: Jesse Eichar
Priority: Minor
Fix For: 2.2.3
-140.873489379882842.0534553527832
does not parse correctly because the comparison is wrong:
if (elements[0].getName().equals(value[i].getElement().getType()
.getName())) {
should be:
if
(elements[0].getName().equals(value[i].getElement().getName())) {
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1805) The name of the FeatureType is obtained from the gml Filename not the name defined in the XSD.
The name of the FeatureType is obtained from the gml Filename not the name defined in the XSD. -- Key: GEOT-1805 URL: http://jira.codehaus.org/browse/GEOT-1805 Project: GeoTools Issue Type: Bug Components: data gml Affects Versions: 2.2.2 Reporter: Jesse Eichar Assignee: Jesse Eichar Fix For: 2.2.3 The name of the FeatureType is obtained from the gml Filename not the name defined in the XSD. The XSD should be used to obtain the featuretype name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Geosolutions and geotools
Ciao Adrian, sorry to be back to you with some delay. Please, read below... On Sat, May 3, 2008 at 11:10 AM, Adrian Custer <[EMAIL PROTECTED]> wrote: > Hey Simone, > > A couple of requests with your work: > > 1) Could you please fix the code in geotools which is not in the > geotools namespace? > modules/unsupported/coveragetools/src/main/java/it/geosolutions > I had heard a few weeks back that this was a mistake on your part and > that you planned to fix it right away. For now, I've also added a > special filter in the javadocs to exclude that code but I'd rather fix > that and get it off my mind. > I think daniele already fixed this already, you might want to check with him in case there any any problems though. > 2) Also, could you please explain how imageio-ext can affect the > geotools build? > Is this only for people who have added into their build the modules that > you created which depend on imageio-ext? Is this only for ArcGrid? Is > this only for 2.4.x? Clarification would be appreciated. I was under the > impression that geotools did not yet depend on imageio-ext so none of my > jvm's have that library. > Imageio-ext contains a few things besides the gdal bindings, specifically a few optimized ImageInput(Output)Streams and a few pure java readers. GeoTools uses the optimized I/O streams, moreover the ArcGrid plugin depends on an Imageio-ext plugin which implements a simple ImageReader/Writer for ascii grids in pure java. If native libs are a concern for you, don't worry, geotools as of now does not import any of those from imageio-ext. Simone. > Thanks, > --adrian > > > On Fri, 2008-05-02 at 19:00 +0200, Simone Giannecchini wrote: > > Sorry about the problem, > > in one or two weeks, we should have a first cut of a more stable > > release of imageio-ext since we are going to fuse with another project > > in order to get more plugins; we have to finish some work on JPEG2000 > > first then we'll branch. > > > > More newsd soon. > > > > Simone. > > -- --- Eng. Simone Giannecchini President /CEO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it --- - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1806) WFS Datastore submits a default value on insert for null attributes which are nillable
WFS Datastore submits a default value on insert for null attributes which are nillable -- Key: GEOT-1806 URL: http://jira.codehaus.org/browse/GEOT-1806 Project: GeoTools Issue Type: Bug Components: data wfs Affects Versions: 2.4.2 Reporter: Jean-Pierre Fiset When connecting to a WFS data source and attempting to create a new feature, geotools submits a default value even the new feature has NULL for the associated attribute and that the feature type reports that the attribute is is nillable. The expected behaviour is that the attribute left NULL should be omitted from the WFS-T insert transaction. Step-by-step instructions to reproduce the problem to follow. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] SLD labels, whitespace, and mixed content
Hi, I'm trying to solve the two following issues: http://jira.codehaus.org/browse/GEOS-1661 http://jira.codehaus.org/browse/GEOS-1620 and I have a working patch, but I would love some feedback on the merits of the issues themselves. In SLD the element is allowed mixed syntax, meaning that one can mix test and elements inside of it. This is very useful to build attribute dependent labels without getting stuck in complex OGC function usage. Yet, this falls short when someone is in need of including a whitespace in the concatenation, since the parser behaviour is to collapse it, thus eating whitespaces and newlines. Now, this is the default xml behaviour, and there is a way to override it explicity, using xs:whitespace=preserve in the xml schema. The Label element in SLD is just declared as mixed content: http://www.w3.org/TR/2004/REC-xml11-20040204/#sec-mixed-content meaning you can mix elements and free text... yet that does not tell much about how whitespace should be handled. I guess that it would mean whitespace should be collapsed, but then again this seems like a gross limitation for label usage (see the silly workarounds some people have found to actually put white spaces in their labels). Soo... opinions? Shall we consider the SLD xsd schema broken and keep white spaces as they are for labels? Or shall we let people keep on doing very silly dances to stuck space\newline chars in between their labels? Cheers Andrea - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Mvn 2.0.9 transition
Sounds good; I am going to have to wait until you pull the rug out from under my feet before trying 2.0.9 Jody > Hey all, > > Has everyone who cares tested their build with the pom.xml from JIRA > 1780? > http://jira.codehaus.org/browse/GEOT-1780 > If no one objects, we'll plan to apply it next week. > > --adrian > > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] SqlBuilder improvements report
Andrea Aime wrote: > * there is something strange going on in the filter encoders... >they do check if the filter is fully supported before proceeding, >but that in turn does not check whether the expressions inside the >filter are supported, leading to a situation where >one could break encoding by passing a supported filter that >uses an unsupported function. I've opened a jira for this: >http://jira.codehaus.org/browse/GEOT-1801 > Thanks Andrea; I have had that problem in the back of my mind for a while (one of the motivations for tracking FilterCapabilities - and the function list) at the DataStore level). As for GEOT-1802 the "attrribute null '5' or "attribute + '5'" thing ... what are you trying to describe here? Is it literally... attribute + 5 attribute5 What was the input that generated the encoder mistake? Cheers, Jody - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GML datastore
Jesse Eichar wrote: > Hi, > > Is the GML datastore on trunk still essentially the same code as on > 2.2 or has it been upgraded to Justin's new parser? > Essentially the same code; there is an unsupported/gml3 parser that I think is the start of a datastore based on Justin's parers targeting GML3. I was going to wait until that one worked before worrying about the gml2 case again. Jody - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] SLD labels, whitespace, and mixed content
Hi Andrea; there are new "official" string functions in town - the work Eclesia has been doing on SE1.1 has brought them to light. It looks like this allows for some functions with a variable number of parameters. So when you do boil this down to a single Expression we may have a better function for you to use. As for the meaning of the section I think we would all like to the behave like a mini template; it output exactly what is between the tags substituting tags where needed. Can you confirm for me that other expressions can be used here - or is it just PropertyName? Cheers, Jody Andrea Aime wrote: > Hi, > I'm trying to solve the two > following issues: > http://jira.codehaus.org/browse/GEOS-1661 > http://jira.codehaus.org/browse/GEOS-1620 > > and I have a working patch, but I would love some feedback > on the merits of the issues themselves. > In SLD the element is allowed mixed syntax, meaning > that one can mix test and elements inside of it. This is > very useful to build attribute dependent labels without > getting stuck in complex OGC function usage. > > Yet, this falls short when someone is in need of including > a whitespace in the concatenation, since the parser behaviour > is to collapse it, thus eating whitespaces and newlines. > > Now, this is the default xml behaviour, and there is a way > to override it explicity, using xs:whitespace=preserve in > the xml schema. > > The Label element in SLD is just declared as mixed content: > http://www.w3.org/TR/2004/REC-xml11-20040204/#sec-mixed-content > > meaning you can mix elements and free text... yet that does not > tell much about how whitespace should be handled. I guess > that it would mean whitespace should be collapsed, but then > again this seems like a gross limitation for label usage > (see the silly workarounds some people have found to actually > put white spaces in their labels). > > Soo... opinions? Shall we consider the SLD xsd schema broken > and keep white spaces as they are for labels? Or shall > we let people keep on doing very silly dances to stuck > space\newline chars in between their labels? > > Cheers > Andrea > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] SqlBuilder improvements report
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> * there is something strange going on in the filter encoders...
>>they do check if the filter is fully supported before proceeding,
>>but that in turn does not check whether the expressions inside the
>>filter are supported, leading to a situation where
>>one could break encoding by passing a supported filter that
>>uses an unsupported function. I've opened a jira for this:
>>http://jira.codehaus.org/browse/GEOT-1801
>>
> Thanks Andrea; I have had that problem in the back of my mind for a
> while (one of the motivations for tracking FilterCapabilities - and the
> function list) at the DataStore level).
>
> As for GEOT-1802 the "attrribute null '5' or "attribute + '5'" thing ...
> what are you trying to describe here? Is it literally...
> attribute + 5
> attribute5
>
> What was the input that generated the encoder mistake?
No, I'm not using any parsing, the test code is:
Add a = filterFac.add(filterFac.property("testAttr"), filterFac.literal(5));
encoder.setFeatureType(integerFType);
encoder.encode(a);
assertEquals("testAttr + 5", output.toString());
and it fails with the SqlToFilter as is, the result is
"testAttr + '5'" instead, because the literal encoding
does not get a target class type, and thus it decides to take
whatever is in the literal and treat is as a string.
Which is silly imho.
Cheers
Andrea
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] SqlBuilder improvements report
Andrea Aime wrote:
> Jody Garnett ha scritto:
>> Andrea Aime wrote:
>>> * there is something strange going on in the filter encoders...
>>>they do check if the filter is fully supported before proceeding,
>>>but that in turn does not check whether the expressions inside the
>>>filter are supported, leading to a situation where
>>>one could break encoding by passing a supported filter that
>>>uses an unsupported function. I've opened a jira for this:
>>>http://jira.codehaus.org/browse/GEOT-1801
>>>
>> Thanks Andrea; I have had that problem in the back of my mind for a
>> while (one of the motivations for tracking FilterCapabilities - and
>> the function list) at the DataStore level).
>>
>> As for GEOT-1802 the "attrribute null '5' or "attribute + '5'" thing
>> ... what are you trying to describe here? Is it literally...
>> attribute + 5
>> attribute5
>>
>> What was the input that generated the encoder mistake?
> No, I'm not using any parsing, the test code is:
>
> Add a = filterFac.add(filterFac.property("testAttr"),
> filterFac.literal(5));
> encoder.setFeatureType(integerFType);
> encoder.encode(a);
> assertEquals("testAttr + 5", output.toString());
>
> and it fails with the SqlToFilter as is, the result is
> "testAttr + '5'" instead, because the literal encoding
> does not get a target class type, and thus it decides to take
> whatever is in the literal and treat is as a string.
> Which is silly imho.
Okay I understand; the problem is that the parsers now try and keep
5 as a "5" and put off deciding how to treat that
until the very last moment (expressed by evaulate( obj, target )...
Looking at the code example for GEOT-1802 we probably can do a little
bit better; right now we are throwing away the context information
before writeLiteral(...) is called. That is a bit of a mistake right? We
need to take that into account; we should be checking if target is
Numeric or Boolean
To answer your question: Why weren't we converting the number to the
right class? We did not ask for it to be in the right class ...
Two things:
- Object literal = expression.getValue(); // is WRONG we need
expression.evaulate( null, target );
- Can you check if the target was null?
Jody
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] SLD labels, whitespace, and mixed content
Andrea Aime wrote: > Jody Garnett ha scritto: >> Hi Andrea; there are new "official" string functions in town - the >> work Eclesia has been doing on SE1.1 has brought them to light. It >> looks like this allows for some functions with a variable number of >> parameters. So when you do boil this down to a single Expression we >> may have a better function for you to use. > > I'll need to see some examples. Anyways, the current code is already > parsing the mixed content > >> As for the meaning of the section I think we >> would all like to the behave like a mini template; it output exactly >> what is between the tags substituting tags where >> needed. Can you confirm for me that other expressions can be used >> here - or is it just PropertyName? > No no, whatever expression you want. Good - thanks for the info. > The only issue is that spaces are being eaten. Imho to make it a good > mini template languages we'd have to preserve spaces instead. Agreed; that sounds like a good move all around. Do you *exactly* have to preserve whitespace or can we gobble up all \n\t characters as a single ' '? ie. what is important here... > As an alternative, I can roll in a function that behaves like a real > template language, freemarker. I have an experiment in a geoserver > community module that looks more or less like this: > > > > That really does not look like a reusable style :-) But you are onto something, the use of a CDATA section to preserve a String, could that be used to capture whitespace of the literals? Jody - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] SLD labels, whitespace, and mixed content
Jody Garnett ha scritto: > Hi Andrea; there are new "official" string functions in town - the work > Eclesia has been doing on SE1.1 has brought them to light. It looks like > this allows for some functions with a variable number of parameters. So > when you do boil this down to a single Expression we may have a better > function for you to use. I'll need to see some examples. Anyways, the current code is already parsing the mixed content > As for the meaning of the section I think we would > all like to the behave like a mini template; it output exactly what is > between the tags substituting tags where needed. Can you > confirm for me that other expressions can be used here - or is it just > PropertyName? No no, whatever expression you want. The only issue is that spaces are being eaten. Imho to make it a good mini template languages we'd have to preserve spaces instead. As an alternative, I can roll in a function that behaves like a real template language, freemarker. I have an experiment in a geoserver community module that looks more or less like this: (FID and NAME are attribute names of the current feature) Yet, that would require quite a bit more work since that function requires the support geoserver is providing to wrap gt2 features into a freemarker model. Cheers Andrea - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Mvn 2.0.9 transition
I upgraded the build server... we will see if it screams. Adrian Custer wrote: > Hey all, > > Has everyone who cares tested their build with the pom.xml from JIRA > 1780? > http://jira.codehaus.org/browse/GEOT-1780 > If no one objects, we'll plan to apply it next week. > > --adrian > > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > !DSPAM:4007,48202d7b106372085621377! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] SLD labels, whitespace, and mixed content
Jody Garnett ha scritto: > Andrea Aime wrote: >> Jody Garnett ha scritto: >>> Hi Andrea; there are new "official" string functions in town - the >>> work Eclesia has been doing on SE1.1 has brought them to light. It >>> looks like this allows for some functions with a variable number of >>> parameters. So when you do boil this down to a single Expression we >>> may have a better function for you to use. >> >> I'll need to see some examples. Anyways, the current code is already >> parsing the mixed content >> >>> As for the meaning of the section I think we >>> would all like to the behave like a mini template; it output exactly >>> what is between the tags substituting tags where >>> needed. Can you confirm for me that other expressions can be used >>> here - or is it just PropertyName? >> No no, whatever expression you want. > Good - thanks for the info. >> The only issue is that spaces are being eaten. Imho to make it a good >> mini template languages we'd have to preserve spaces instead. > Agreed; that sounds like a good move all around. Do you *exactly* have > to preserve whitespace or can we gobble up all \n\t characters as a > single ' '? ie. what is important here... One of my issues says people are trying to make up multiline labels, we'll need to preserve newlines in order to have those >> As an alternative, I can roll in a function that behaves like a real >> template language, freemarker. I have an experiment in a geoserver >> community module that looks more or less like this: >> >> >> >> > That really does not look like a reusable style :-) Why not? > But you are onto > something, the use of a CDATA section to preserve a String, could that > be used to capture whitespace of the literals? I tried, it did not work, the parser does not make a difference between cdata sections and mixed content apparently. Cheers Andrea - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Progress extends Future
Jody Garnett a écrit : > Changes for this commit: > - Processors (formally ProcessFinder) is similar to Executors > - ProcessExecutor extends Executor and is similar to ExecutorService > - Process is implemented as we described (ie the same style as > Callable>) > - Progress extends Future (and is returned by a ProcessExecutor for each > submitted Process) Thats sound good :) > I have also implemented: > - ThreadPoolProcessExecutor - implementation of ProcessExecutor I presume that it uses java.util.concurrent.ThreadPoolExecutor under the hood? > - ProcessTask (an implementation of Progress by copying the Java class > FutureTask - this is just for show we will need to implement this > ourself prior to public release) Just for my information: is there any chance to avoid this copying and instead just wrap the standard FutureTask and delegate most methods to the wrapped instance? Martin - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Progress extends Future
Martin Desruisseaux wrote: >> I have also implemented: >> - ThreadPoolProcessExecutor - implementation of ProcessExecutor > I presume that it uses java.util.concurrent.ThreadPoolExecutor under > the hood? It is an extension of that class. > Just for my information: is there any chance to avoid this copying and > instead just wrap the standard FutureTask and delegate most methods to > the wrapped instance? None I am afraid; the FutureTask implementation is actually just a very careful wrapper around a FutureTask.Sync internal class protected using the usual java 5 concurrency tricks (that I wish they would document). So yeah there is some technical debt here; someone will need to implement a ProgressTask of our own. Jody - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1807) Create code that can guess the return type of an expression
Create code that can guess the return type of an expression --- Key: GEOT-1807 URL: http://jira.codehaus.org/browse/GEOT-1807 Project: GeoTools Issue Type: Improvement Components: core filter Affects Versions: 2.5-M0, 2.4.2 Reporter: Andrea Aime The literal/converter approach we're assuming that a target class is more or less always available when it comes to extract a usable value out of a literal. Unfortunately in many cases that is hard, for example 2 + 5 (7 or "25") 2.0 + 5 (7.0, 7 or "2.05"?) 5 + (5 + property) -> how do we use the property type when evaluating what the first 5 is going to be? A TypeVisitor is needed that takes an expression and drills down into it trying to understand what its resulting type will be. The result should be a type and a level of confidence, such as Integer, Assumption Double, Fact In the case 2 + 5 we'd end up with (Integer, Assumption), that is, we assume integer is going to be fine, but we have no actual attribute type telling us so. In the case 5 + (5 + property) we should end up with (Integer, Fact) since we know about the property type -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] arcsde state of play
Yes I am finally working on ArcSDE again ... I have been asked to stop converting ArcSDEDataStore over to using a queue and instead look at a series of problems: - A connection leak from hitting "refresh" in uDig (arcsde connections are opened but not closed). My impression is that the render threads need to wait for ArcSDE to start returning results before "noticing" that they have been stopped, and then closing the ArcSDE connection. - The arcsde problem mentioned previously where an internal object id is accidentally being made available as an attribute; breaking any code that tries to "split" an existing feature into two... As for testing I am still looking at 19 failures for the ArcSDE package, Gabriel / Saul if you have a different number I would be pleased to know. Cheers, Jody - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] arcsde state of play
Jody Garnett wrote: > Yes I am finally working on ArcSDE again ... I have been asked to stop > converting ArcSDEDataStore over to using a queue and instead look at a > series of problems: > - A connection leak from hitting "refresh" in uDig (arcsde connections > are opened but not closed). My impression is that the render threads > need to wait for ArcSDE to start returning results before "noticing" > that they have been stopped, and then closing the ArcSDE connection. > - The arcsde problem mentioned previously where an internal object id is > accidentally being made available as an attribute; breaking any code > that tries to "split" an existing feature into two... > > As for testing I am still looking at 19 failures for the ArcSDE package, > Gabriel / Saul if you have a different number I would be pleased to know. > Fixed GEOT-1735 and am now down to 17 failures. Jody - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Mvn 2.0.9 transition
On Tue, 2008-05-06 at 11:57 -0700, Justin Deoliveira wrote: > I upgraded the build server... we will see if it screams. Hey Justin, upgraded to 2.0.9 or to use Cedric's pom.xml (in the JIRA)? --adrian - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
