got some pain in this process ..
in FilterToSQL
public Object visit(Literal expression, Object context) throws
RuntimeException {
LOGGER.finer("exporting LiteralExpression");
//type to convert the literal to
Class target = (Class)context;
//J
...found that there is a bug in javadoc generation that causes a crash
rather than error message when bad html is found in a javadoc.
This was actually 2 instances of generics being mentioned in the
javadocs without the javadoc being correctly html-ized (ie.
"Collection" rather than "Collection
Support nonBBOX geometry filters
Key: GEOT-1226
URL: http://jira.codehaus.org/browse/GEOT-1226
Project: GeoTools
Issue Type: Sub-task
Reporter: Rob Atkinson
--
This message is automatically g
Implement GeoAPI filters
Key: GEOT-1225
URL: http://jira.codehaus.org/browse/GEOT-1225
Project: GeoTools
Issue Type: Sub-task
Reporter: Rob Atkinson
--
This message is automatically generated by JIRA
Use common connection pooling, allowing simple JDBC standard connections
Key: GEOT-1224
URL: http://jira.codehaus.org/browse/GEOT-1224
Project: GeoTools
Issue Type: Sub
Rob Atkinson wrote:
> I've had quite some pain keeping trunk building over the last few weeks
> - just trying to identify when it was stable enough for my little brain
> to attempt to do a few things.
>
> Nevertheless, I think we should persist, I agree with Andrea its too
> scary to lose the di
I've had quite some pain keeping trunk building over the last few weeks
- just trying to identify when it was stable enough for my little brain
to attempt to do a few things.
Nevertheless, I think we should persist, I agree with Andrea its too
scary to lose the discipline..
And I'd like to com
Okay we are down to the last bit here ... this one is another in the
category of revealed bugs.
This is the second problem found with Factory implementations returning
inappropriate results for getImplementationHints().
Hints remaining = null;
Map implementationHints = factory.getImplementation
So now that both fixes are in ... here is what I should of done differently:
- the moment I could not build (because of the Maven 2.0.5 requirement)
I should of stopped work and sent email to the list
- if I could not find Cory I should of backed out his changes
I would be interested in knowing i
Jody Garnett wrote:
> Some success ... I have *not* hooked up the default Hints for the CRS
> utility class - the moment I do this things are back to normal.
>
> This should set off some alarm bells, basically providing Hints in the
> CRS class was the first time the GeoTools library has been ho
Some success ... I have *not* hooked up the default Hints for the CRS
utility class - the moment I do this things are back to normal.
This should set off some alarm bells, basically providing Hints in the
CRS class was the first time the GeoTools library has been hooked
up as intended (and it di
I am starting to get a few clues - as the build box helpfully shows the
following tests are troubled:
- org.geotools.referencing.CrsTest
- org.geotools.referencing.operation.projection.SouthOrientedTest
You can see this by going to modules/library/referencing:
mvn install -P nojai
The difficulty
Jody Garnett wrote:0
> Today however I am stuck on a JAI error message (the usually RangeSet
> failure that indicates JAI is unhappy as covered by our Developers
> Docs). Problem is I have not changed my development environment at all,
> the test passes in eclipse ... it seems to be that we are
Andrea Aime wrote:
> We can try a few options, before calling the trunk on trunk experiment
> failed and go back to the old way of doing things.
> One would be to build a sort of "hall of shame" with a score that
> goes up for each developer that breaks the build.
> Another is stronger, but I guess
Well I am shamed right now.
But I still need help figuring out where this JAI break occurred from ...
Talking to Justin he has it building better with the "nojai" profile
(just added the docs to the root pom.xml), and is now stuck on some CRS
failure - I am going to follow in his footsteps and h
Justin Deoliveira ha scritto:
> Activating the nojai profile makes it go away. But this leads to more
> problems in the referencing module. The following tests fail:
>
> testEnvelopeTransformation(org.geotools.referencing.CrsTest)
>
> testTransverseMercator(org.geotools.referencing.operation.pr
Jody Garnett wrote:
> I best back out my work from yesterday ... and see if we can isolate
> what caused this JAI problem.
Peculiar indeed...
I've rolled back to r25003 but still get:
modules/library/metadata/target/surefire-reports/org.geotools.factory.GeoToolsTest.txt
Global GeoTools Hints
-
Key: GEOT-1223
URL: http://jira.codehaus.org/browse/GEOT-1223
Project: GeoTools
Issue Type: Improvement
Reporter: Jody Garnett
Currently GeoTools opperates around a number of Singleto
Martin Desruisseaux wrote:
> Jody Garnett a écrit :
>> Martin your example will work for referencing, but it is a lot of
>> work to clean up the rest of the library to that standard. I am not
>> sure we can pull it off right now. How about this ... we recognize
>> that GeoTools right now is "sin
Thanks Justin ...
I best back out my work from yesterday ... and see if we can isolate
what caused this JAI problem.
Jody
Justin Deoliveira wrote:
> Activating the nojai profile makes it go away. But this leads to more
> problems in the referencing module. The following tests fail:
>
> testEnv
Activating the nojai profile makes it go away. But this leads to more
problems in the referencing module. The following tests fail:
testEnvelopeTransformation(org.geotools.referencing.CrsTest)
testTransverseMercator(org.geotools.referencing.operation.projection.SouthOrientedTest)
testKrovak(or
Oh I see - this was simply my misunderstanding :-(
I thought that:
1) Key was a Data Object (and used the className for its comparison)
2) They id would be used to check a system property
3) We could make different Key implementations that performed the
acceptable value check differently
You wil
I can verify the RangeSet problem, on my local box and our build server.
Jody Garnett wrote:
> So here is the deal - yesterday evening I went to build trunk ...
>
> And found that Manven 2.0.5 was required! (Cory has now backed out that
> change)
>
> I however screwed up I committed the my code
Remove FactoryFinder (the initial GeoTools 2.0 FactorySPI lookup)
-
Key: GEOT-1222
URL: http://jira.codehaus.org/browse/GEOT-1222
Project: GeoTools
Issue Type: Improvement
So here is the deal - yesterday evening I went to build trunk ...
And found that Manven 2.0.5 was required! (Cory has now backed out that
change)
I however screwed up I committed the my code in modules/library/
And have since found out that the epsg-wkt plugin is unhappy with my
changes.
>As per the discussions on the OSGeo [SoC] list, we need to come to some
>sort of agreement as to the rankings of the Geotools applications within
>the next day or so. These are:
>
>A) New Transformation Algorithms for GeoTools and uDig
>B) Plugins for multidimensional raster data sources
>C) 3D R
PostgisAutoIncrementFidMapper does not handle "returnFidColumnsAsAttributes"
properly
-
Key: GEOT-1221
URL: http://jira.codehaus.org/browse/GEOT-1221
Project: GeoTool
Ok, I'll apply to trunk today, and wait for the 2.3.1 release to come out
before applying to the 2.3.x branch.
--saul
-Original Message-
From: Andrea Aime [mailto:[EMAIL PROTECTED]
Sent: Wed 4/4/2007 6:20 AM
To: Martin Desruisseaux
Cc: Farber, Saul (ENV); [email protected]
Jody Garnett a écrit :
> Please correct me if I am wrong .. it looks like adding a Hint as a
> value does not work?
I'm not sure what is your intend? Hints.Key instances are used directly as key
in HashMap. The argument given to the constructor is a constraint to apply on
the value provided in:
Jody Garnett a écrit :
> Trying this out as an experiment ... running into a problem with
> GridFormatFinder .. in short I do not see how the Hints
> make it to the constructor based on the following code:
>
>> (..snip...)
>
> Hints are used in the hintsFilter ... but by then the provider object
Jody Garnett a écrit :
> In this case it is a blocker, the factory literally builds a list of
> AttributeTypes and then later creates a FeatureType from them ... it
> really is a builder rather then a factory.
Oups! I see. Then what about renaming "FeatureTypeFactory" as
"FeatureTypeBuilder"? A
Jody Garnett a écrit :
> Martin your example will work for referencing, but it is a lot of work
> to clean up the rest of the library to that standard. I am not sure we
> can pull it off right now. How about this ... we recognize that GeoTools
> right now is "single use" and we gather up the ass
On Wed, 2007-04-04 at 12:00 +0200, Martin Desruisseaux wrote:
> Jody Garnett a écrit :
> > You were thinking of renaming this beast - is now a good time?
>
> org.geotools.referencing.FactoryFinder may be renamed as
> ReferencingFactoryFinder in order to distinguish it from other FactoryFinder.
>
Martin Desruisseaux ha scritto:
> Farber, Saul (ENV) a écrit :
>> Martin, what do you think of these changes? Do you think they can be
>> applied as is to trunk and 2.3.x? Or are there other issues that you think
>> need to be addressed?
>
> I'm all for those changes if they are helpful to Geo
Farber, Saul (ENV) a écrit :
> Martin, what do you think of these changes? Do you think they can be applied
> as is to trunk and 2.3.x? Or are there other issues that you think need to
> be addressed?
I'm all for those changes if they are helpful to Geoservers. I have not applied
them yet onl
Jody Garnett a écrit :
> You were thinking of renaming this beast - is now a good time?
org.geotools.referencing.FactoryFinder may be renamed as
ReferencingFactoryFinder in order to distinguish it from other FactoryFinder.
I'm mostly indifferent on this one.
Martin
36 matches
Mail list logo
