OK - I'm cool about this, just a bug in the implementation not handling
nulls -
even though its possible that nulls should never be used, the
implementation is still happy to get the value from the expression, so
it should be expected to behave better I think.
- I've submitted the patch.
Rob
Andrea Aime a écrit :
> That fix may work for the moment, but only because we're lucky... they
> added a way to include the version number in the project name, so we
> just have to hope we'll never have gt2 and geoserver with the same
> version number.
Filled a new JIRA issue for maven-eclipse-p
Hi David,
As the developer I assume you are referring to the datastore developer?
The "extraData" parameter is something that is more intended to be used
internally by the filter encoder. As the data store developer you will
likely never be just encoding a literal in isolation ( i could be wrong
)
Jody Garnett a écrit :
> The following will let us explore the problem (when you get a moment):
> - a static final boolean in CRS - if you change it to "true"
> GeoTools.getDefaultHints() will be used rather then "null"
I would prefer to investigate why CRS is unhappy with
GeoTools.getDefaultH
Martin Desruisseaux ha scritto:
> Ideally I would like to get ride of "gt2-" prefix in module name (in order to
> match directory name, which allow us to get a bunch of properties to work
> with
> Maven default) but keep the "gt2-" prefix in JAR name. We were able to do
> that
> but get troub
Cory Horner a écrit :
> In order to accomplish this, I added two profiles (ugh... too many now)
> site.fr and site.rr, which contributes either the geotools.fr or
> refractions.net site url, respectively.
There is probably too much profile now. Maybe there is some way to specify the
deployment
Andrea Aime a écrit :
> Shouldn't we use the trick of renaming the class, then creating an empty
> subclass with the old name, and marking it as deprecate for a release
> cycle?
Yes exactly. If the renaming was not done that way, we should add back a
deprecated FactoryFinder class.
Mart
Andrea Aime a écrit :
> Afaik the current defaults are so high to allow merged javadoc generation
Then we should set this value to 1024M only when maven is run with the
"maven.site.build" profile, and use the 128M value otherwise.
Martin
-
org.geotools.xml.Schemas::getMinOccurs and getMaxOccurs fails when asked for a
property defined in a super type
---
Key: GEOT-1232
URL: http://jira.codehau
I ran into the same problem when handling a geometry literal. How is a
developer supposed to know that the call to accept needs to include an
extraData parameter of Geometry.class in this case?
Farber, Saul (ENV) wrote:
> Rob,
>
> Yeah, cory's right. The 'extraData' object in the FilterVisitor
Justin Deoliveira ha scritto:
> Hi all,
>
> Currently the root pom on trunk uses a max heap size of 1024M, and 2.3.x
> uses 512M. I am having problems with our build server running out of
> memory with these max heap sizes specified.
>
> I would like to set a lower value in the pom, like around 1
Hi,
today I wake up finding Geoserver trunk did not compile due to
a change in referencing factory finder class name.
Now, I like the name change, as I despise having multiple classes with
the same name in the same code base, but at the same time, that class
was around since 2.0, so straight ren
12 matches
Mail list logo
