Another to probably mention is that we probably don't want to move all
of the modules over just yet. For instance mysql and sqlserver don't use
spatial indexing as of yet, so until they do they probably are not ready
for prime time, so we could just keep them in unsupported for the time
being.
Good point about unsupported/jdbc - we do not want to change the
module name. We should leave the implementations that are not ready
yet where they are.
Slightly off topic (I saw Andrea mention this on the user emaillist).
One of the tasks associated with moving a module to supported is
running
Please, reopne the ticket, I will see what I can do to make use of one
of the standard jars on the jsr-275 website.
Simone.
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
Justin Deoliveira ha scritto:
I have been working through some jdbc-ng issues lately in an effort move
it to supported. There are currently two critical bugs outstanding:
http://jira.codehaus.org/browse/GEOT-2488
Has a patch, but it needs work.
Oh, if my understanding of that is correct,
Jody Garnett ha scritto:
Good point about unsupported/jdbc - we do not want to change the
module name. We should leave the implementations that are not ready
yet where they are.
Slightly off topic (I saw Andrea mention this on the user emaillist).
One of the tasks associated with moving a
Justin Deoliveira ha scritto:
Another to probably mention is that we probably don't want to move all
of the modules over just yet. For instance mysql and sqlserver don't use
spatial indexing as of yet, so until they do they probably are not ready
for prime time, so we could just keep them
Michael Bedward ha scritto:
Hello,
Any objections if the work mentioned below is merged into trunk ? The
only change affecting other modules is that Process.execute now throws
an exception.
None from me. When I get some breathing room I'll be proposing a much
bigger change in the factories
+1
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob:+39 333 8128928
http://www.geo-solutions.it
Andrea,
I can confirm that changing the maven-eclipse-plugin
buildOutputDirectory to bin (GEOT-2576) breaks app-schema unit tests
because it prevents both main and test SPI resources from being
available at unit test run time in Eclipse (they run fine in maven).
With the default maven
Ben Caradoc-Davies ha scritto:
Andrea,
I can confirm that changing the maven-eclipse-plugin
buildOutputDirectory to bin (GEOT-2576) breaks app-schema unit tests
because it prevents both main and test SPI resources from being
available at unit test run time in Eclipse (they run fine in
Ben Caradoc-Davies ha scritto:
Andrea,
I can confirm that changing the maven-eclipse-plugin
buildOutputDirectory to bin (GEOT-2576) breaks app-schema unit tests
because it prevents both main and test SPI resources from being
available at unit test run time in Eclipse (they run fine in
Andrea Aime wrote:
Did you spot what exactly is not working, which spi resource is not
being properly read?
org.geotools.data.DataAccessFactory
org.geotools.filter.FunctionExpression
which both have main versions and test versions. The test ones cannot go
in main because they reference test
Andrea Aime wrote:
Btw, I was trying to look into this one and noticed that
app-schema is not included in the build when specifying -Dall,
meaning the main Hudson won't pick it up.
It this by choice?
Yes, it has never been proposed for inclusion. On my rather long list of
things to do. I
Ben Caradoc-Davies ha scritto:
Andrea Aime wrote:
Did you spot what exactly is not working, which spi resource is not
being properly read?
org.geotools.data.DataAccessFactory
org.geotools.filter.FunctionExpression
which both have main versions and test versions. The test ones cannot go
Ben Caradoc-Davies ha scritto:
Andrea Aime wrote:
Btw, I was trying to look into this one and noticed that
app-schema is not included in the build when specifying -Dall,
meaning the main Hudson won't pick it up.
It this by choice?
Yes, it has never been proposed for inclusion. On my rather
Andrea Aime ha scritto:
Ben Caradoc-Davies ha scritto:
Andrea Aime wrote:
Did you spot what exactly is not working, which spi resource is not
being properly read?
org.geotools.data.DataAccessFactory
org.geotools.filter.FunctionExpression
which both have main versions and test versions. The
Andrea Aime wrote:
Ben Caradoc-Davies ha scritto:
Andrea Aime wrote:
Did you spot what exactly is not working, which spi resource is not
being properly read?
org.geotools.data.DataAccessFactory
org.geotools.filter.FunctionExpression
which both have main versions and test versions. The test
Justin Deoliveira ha scritto:
3) revert back to the old way :)
Seems like 1) move the new eclipse config to a profile seems the nicest
way. It gives developers the choice of how to set up their eclipse
environment.
I guess we can just revert to the old way for the time being.
Getting the
Andrea Aime wrote:
Justin Deoliveira ha scritto:
3) revert back to the old way :)
Seems like 1) move the new eclipse config to a profile seems the
nicest way. It gives developers the choice of how to set up their
eclipse environment.
I guess we can just revert to the old way for the
Hi all,
due to the issue raised by Ben I reverted the eclipse changes to
the pom.
If you are not affected and you still want to have eclipse build
in the bin directory you can use:
mvn eclipse:eclipse -DoutputDirectory=bin
I'll be looking up to ways to patch the eclipse plugin so that
we don't
Andrea Aime wrote:
Andrea Aime ha scritto:
Ben Caradoc-Davies ha scritto:
Andrea Aime wrote:
Did you spot what exactly is not working, which spi resource is not
being properly read?
org.geotools.data.DataAccessFactory
org.geotools.filter.FunctionExpression
which both have main versions
Justin Deoliveira ha scritto:
Andrea Aime wrote:
Andrea Aime ha scritto:
Ben Caradoc-Davies ha scritto:
Andrea Aime wrote:
Did you spot what exactly is not working, which spi resource is not
being properly read?
org.geotools.data.DataAccessFactory
org.geotools.filter.FunctionExpression
Works for me
Justin Deoliveira writes:
Andrea Aime wrote:
Justin Deoliveira ha scritto:
3) revert back to the old way :)
Seems like 1) move the new eclipse config to a profile seems the
nicest way. It gives developers the choice of how to set up their
eclipse environment.
I guess
Hallo,
A few weeks ago I posted a patch for the DefaultMapLayer which fixed a
NullPointerException if the FeatureSource.getBounds returned null. This patch
were commited on trunk (Revision 32475 commited by jive) but not on the 2.5.x
branch. Could somebody apply the getBounds patch (.. see
Simone Giannecchini wrote:
Please, reopne the ticket, I will see what I can do to make use of one
of the standard jars on the jsr-275 website.
I have reopened it.
We should be able to set the new artifact version in dependency
management. The problem is that 1.0.0 pom appears to redirect to
Here it is:
It was actually already started, I just had to tweak it a bit.
http://docs.codehaus.org/display/GEOTOOLS/Next+Generation+JDBC+DataStore
It is more or less ready for voting, which I think at this point is just
a formality.
In terms of things to do:
* Updating user guide
Done, if
Hi Justin:
Only small stupid feedback; in your proposal page the final directory
structure has an unsupported/jdbc directory.
- is this needed anymore? If jdbc-core is being folded into library/
jdbc?
- or is it used to hold onto the jdbc-ng modules that are not ready
yet? (if so could you
Hi Andrea,
On Thu, Jul 2, 2009 at 4:16 PM, Andrea Aime aa...@opengeo.org wrote:
Daniele Romagnoli ha scritto:
Hi list,
I would like to add a new gt-jp2kakadu unsupported module on geotools to
allow access JP2K data using the Kakadu driver via the
imageio-ext-kakadu plugin we have
very very long processing time in detail level
--
Key: GEOT-2588
URL: http://jira.codehaus.org/browse/GEOT-2588
Project: GeoTools
Issue Type: Bug
Components: core render
Affects
Daniele Romagnoli ha scritto:
Hi list,
I would like to add a new gt-jp2kakadu unsupported module on geotools to
allow access JP2K data using the Kakadu driver via the
imageio-ext-kakadu plugin we have prepared on imageio-ext. (An incoming
1.0.3 release)
The underlying data access logics
Just tested it. Beautiful :)
Michael
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Hi list,
I would like to add a new gt-jp2kakadu unsupported module on geotools to
allow access JP2K data using the Kakadu driver via the imageio-ext-kakadu
plugin we have prepared on imageio-ext. (An incoming 1.0.3 release)
The underlying data access logics will be based on some of the key objects
Port imageio.ext.version property to root's pom as already done on trunk.
-
Key: GEOT-2587
URL: http://jira.codehaus.org/browse/GEOT-2587
Project: GeoTools
Issue Type:
Justin Deoliveira ha scritto:
I would say, move the current jdbc to unsupported/jdbc-legacy?
Otherwise we end up with two gt-jdbc jars and break up the
binary distribution, which is a flat list of jars
(the the second going in will overwrite the first).
Alternatively, we need some other
Have postgis-ng schema default to public
--
Key: GEOT-2589
URL: http://jira.codehaus.org/browse/GEOT-2589
Project: GeoTools
Issue Type: Improvement
Reporter: Andrea Aime
Have Oracle-NG uppercase the schema name by default
---
Key: GEOT-2590
URL: http://jira.codehaus.org/browse/GEOT-2590
Project: GeoTools
Issue Type: Improvement
Components: data
Add a method isThreadSafe to AbstractGridCoverage2DReader
-
Key: GEOT-2591
URL: http://jira.codehaus.org/browse/GEOT-2591
Project: GeoTools
Issue Type: Improvement
+1 as long as it's out of the build.
Simone.
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob:+39 333 8128928
Hi PMC,
This is to inform I'm about to create a new project under the
plugin/arcsde umbrella.
I am developing JNDI support for the ArcSDE module.
But as ArcSDE is not jdbc related, there's no JNDI ObjectFactory that
can deal with it (as opposed to javax.sql.DataSource for which J2EE
Andrea Aime wrote:
Justin Deoliveira ha scritto:
I have been working through some jdbc-ng issues lately in an effort
move it to supported. There are currently two critical bugs outstanding:
http://jira.codehaus.org/browse/GEOT-2488
Has a patch, but it needs work.
Oh, if my understanding
I found GeoServer trunk does not work on Tomcat but does on Jetty.
Reason being there are two jsr-275 jars on geoserver/WEB-INF/lib:
jsr-275-0.9.1.jar and jsr-275-1.0-beta-2.jar.
So it will work or not depending on which one is first picked up by the
classloader.
Any clue on how to solve it?
mvn dependency:tree gave me the answer:
[INFO] | \- org.geotools:gt-metadata:jar:2.6-SNAPSHOT:compile
[INFO] | +- java3d:vecmath:jar:1.3.1:compile
[INFO] | +- org.opengis:geoapi:jar:2.3-SNAPSHOT:compile (version
managed from 2.3-M1)
[INFO] | | \-
sure, thanks.
Gabriel
Gabriel Roldan wrote:
mvn dependency:tree gave me the answer:
[INFO] | \- org.geotools:gt-metadata:jar:2.6-SNAPSHOT:compile
[INFO] | +- java3d:vecmath:jar:1.3.1:compile
[INFO] | +- org.opengis:geoapi:jar:2.3-SNAPSHOT:compile (version
managed from 2.3-M1)
That seems fine; if I understand things correctly you are looking to
share the arcsde connections between the datastore and grid coverage
using JNDI?
Jody
On Fri, Jul 3, 2009 at 2:35 AM, Gabriel Roldangrol...@opengeo.org wrote:
Hi PMC,
This is to inform I'm about to create a new project under
Better yet can we just accept the transitive dependency from GeoAPI?
On the GeoAPI list we have been looking at the newer version of
JSR-275 - but I have not paid close attention to it yet.
Jody
On Fri, Jul 3, 2009 at 6:10 AM, Gabriel Roldangrol...@opengeo.org wrote:
sure, thanks.
Gabriel
Justin Deoliveira wrote:
Andrea Aime wrote:
I can see two paths:
- move back the eclipse output trick in a profile
- have the tests that need to register factories avoid using META-INF
and roll a custom factory iterator instead. As far as I can see
only three modules make use of test
Andrea Aime wrote:
I can see two paths:
- move back the eclipse output trick in a profile
I think this is the cleanest approach for now. How about -Peclipse-bin?
I would be equally happy with leaving bin as the default and having a
profile to turn it off (-Peclipse-shared).
- have the tests
Andrea Aime wrote:
Third option, take the latest eclipse stable release, patch it so
that it generate separate output folders, roll our own eclipse-gt
plugin variant until the official eclipse plugin gets its acts
togheter.
I'll try to give a shot at this option during the weekend.
How do
Andrea Aime wrote:
I guess we can just revert to the old way for the time being.
Getting the output in bin is a matter of using:
mvn eclipse:eclipse -DoutputDirectory=bin
not significantly longer than enabling a profile.
Is this ok for everybody?
I am also happy with that. Please document it
This is the problem I reported with GEOT-2586. Simone reverted it in
r33436 eight hours ago. Please try again.
Gabriel Roldan wrote:
I found GeoServer trunk does not work on Tomcat but does on Jetty.
Reason being there are two jsr-275 jars on geoserver/WEB-INF/lib:
jsr-275-0.9.1.jar and
Thanks Justin.
+1 from me
Michael
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
+1 from me. Nice work.
--
Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
--
Ben Caradoc-Davies wrote:
[Eclipse bin output]
Justin, you know Andrea is our resident speed demon; do you really think
you would be able to deprive him of his new toy? ;-)
Which reminds me:
Andrea, you will no doubt recall the many discussions in which we have
protested your concern with
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Was bin intentionally kept out of target so that it is not susceptible
to being wiped out in a mvn clean? I can see pros and cons both ways I
suppose.
[...]
Wondering if it's possible to automate the bin folders cleaning
somehow with maven
54 matches
Mail list logo
