Hi!
I just attached diff-files for 2.4.x and trunk to issue GEOT-1549 (the
problem with altered bbox in visit(GeometryFilter filter) of
org.geotools.filter.visitor.PostPreProcessFilterSplittingVisitor.java).
Maybe someone could review that?
I also had a look into the other problem (GEOT-1550 -
Andrea Aime wrote:
>> Andrea how are you able to build? The build box seems happy, but
>> these tests fail for me ...
> I have no idea, they do just work for me? I'm checking, but
> unfortunately I'm a full build away from starting to work on this since
> otherwise whatever I do with maven downlo
Hi Martin:
> Me too I'm really not sure that it is needed, but I did that mostly in order
> to
> preserve compatibility with the old Logging.redirectToCommonsLogging()
> behavior.
>
> Yes, Logging.getLogging("").setLoggerFactory(xxx) should work. Or you can also
> use the shorthand Logging.ALL.se
Hi Robert,
GML3 is quite different from GML2. The changes on teh geometry elements
that you noted are one of differences. The feature stuff is still pretty
similar. And then there is a wack of more stuff that we don't really use.
So patching the GML2 parsing stuff is one alternative. However a fu
Yeah... these are the files that contain the h2 database. We could
remove them after ever test run...but that would make the tests run
quite slow. And that module has quite a bit of tests.
Does anyone know if svn:ignore handles wild cards? A nice solution could
be to store them under "target". THe
Logger.getLogger(...) --> Logging.getLogger(...) substitution completed on the
2.4 branch as well. Task is now closed (unless there is bug reported - please
let me know).
Martin
-
This SF.net email is sponsored by: Sp
The switch to Logging.getLogger(...) is done on trunk.
The same switch is under way on 2.4 branch.
Please remember to use Logging.getLogger(...) in the future.
Martin
-
This SF.net email is sponsored by: Splunk Inc.
Justin Deoliveira a écrit :
> However, after looking into how other projects with many modules like
> geotools they all use a prefix such as we are doing now. See commons,
> hibernate, spring.
I had a little bit of hesitation too. However removing the prefix from module
name (and configure Maven's
ArcSDEDataStore in conflict with super class over TransactionState
--
Key: GEOT-1582
URL: http://jira.codehaus.org/browse/GEOT-1582
Project: GeoTools
Issue Type: Bug
C
Problem with the Envelope2D
---
Key: GEOT-1581
URL: http://jira.codehaus.org/browse/GEOT-1581
Project: GeoTools
Issue Type: Bug
Components: core geometry
Affects Versions: 2.3.5
Environment: Win
Andrea Aime ha scritto:
> Hmm... we'll try and see, afaik we're using 1.2.14 in GeoServer so we
> have trace method around. I'll let you know as soon as I have enough
> material to do a real test: GeoTools switched and the task to switch
> GeoServer as well... since it seems you're doing the sw
Andrea Aime a écrit :
> can you send the ant task definition to the list so that I can apply the
> same change in GeoServer and see how things are working?
Yes I was planning to attach it to GEOT-1545. Will let you know when I'm done.
Martin
--
Andrea Aime a écrit :
> Hmmm, maybe this one?
> http://ant.apache.org/manual/OptionalTasks/replaceregexp.html
Yes exactly. It should work.
Martin
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping throug
Martin Desruisseaux ha scritto:
> In order to implements Log4JLogger, I upgrated the Log4J dependencies in the
> parent pom.xml from 1.2.6 to 1.2.12. I also upgrated Commons-logging from
> 1.0.4
> to 1.1 for consistency (the later depends on Log4J 1.2.12).
>
> I did this upgrate because Log4JLogg
In order to implements Log4JLogger, I upgrated the Log4J dependencies in the
parent pom.xml from 1.2.6 to 1.2.12. I also upgrated Commons-logging from 1.0.4
to 1.1 for consistency (the later depends on Log4J 1.2.12).
I did this upgrate because Log4JLogger maps Java "finest" level to Log4J "trace"
"mvn install" on trunk lets the following files after the build:
svn status
? modules/unsupported/h2/geotools.2.log.db
? modules/unsupported/h2/geotools.index.db
? modules/unsupported/h2/geotools.771.773.lob.db
? modules/unsupported/h2/geotools.data.db
? modules/unsupporte
Martin Desruisseaux ha scritto:
> Hello Andrea
>> I also noticed that Logging has a getLogger(name) but not a
>> getLogger(name, bundle). It seems there is nothing in GeoTools using
>> the latter, yet I'm wondering if that may need to be provided or
>> not (in fact I've found just one usage of the
Hello,
currently I'm working on a project for a client where we need to work on
GML v3.
In this project, the data are stored in an eXist database. geoTools is
used to create indexes in the database by using GMLFilterDocument.
Currently, the indexes are created only for GML v2 file.
To make geo
Hello Andrea
You comments are always welcome :)
Andrea Aime a écrit :
> I see that in order to redirect a package one has to
> go through Logging.getLogging("my.package.name").setLoggerFactory(xxx).
> This allows, as far as I can tell, to use a different logging subsystem
> for different packages
Hi Martin (hi all),
I was having a look at the work you've committed so far.
Generally speaking seems exactly what we need. I have some
questions and observations thought (as usual :-p).
I see that in order to redirect a package one has to
go through Logging.getLogging("my.package.name").setLogger
Jody Garnett ha scritto:
> Okay I updated the development page to reflect the new location. Thanks
> for keeping the build box going Justin.
>
> I am encountering a build failure on trunk:
>> Running org.geotools.data.DataUtilitiesTest
>> Tests run: 25, Failures: 3, Errors: 0, Skipped: 0, Time el
Okay I updated the development page to reflect the new location. Thanks
for keeping the build box going Justin.
I am encountering a build failure on trunk:
> Running org.geotools.data.DataUtilitiesTest
> Tests run: 25, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 1.364
> sec <<< FAILURE!
Wh
22 matches
Mail list logo
