Add ability to do safe conversions
--
Key: GEOT-2593
URL: http://jira.codehaus.org/browse/GEOT-2593
Project: GeoTools
Issue Type: Improvement
Components: core main
Affects Versions: 2.6-M1, 2.5.6
Ben Caradoc-Davies ha scritto:
> 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 i
Justin Deoliveira wrote:
> 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 thi
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
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
+1 from me. Nice work.
--
Ben Caradoc-Davies
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
--
_
Thanks Justin.
+1 from me
Michael
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
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 j
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 documen
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
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 tes
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
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 Roldan wrote:
> sure, thanks.
>
> Gabriel
> Gabriel Roldan wro
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 Roldan wrote:
> Hi PMC,
>
> This is to inform I'm about to create a new project under the
> plugin/arc
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)
>
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] | | \- net.java.dev.jsr-275:jsr-275:jar:1.0-
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?
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
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
containers
+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
http://
Mysql jdbc-ng version should provide a default port value
-
Key: GEOT-2592
URL: http://jira.codehaus.org/browse/GEOT-2592
Project: GeoTools
Issue Type: Improvement
Components:
Add a method isThreadSafe to AbstractGridCoverage2DReader
-
Key: GEOT-2591
URL: http://jira.codehaus.org/browse/GEOT-2591
Project: GeoTools
Issue Type: Improvement
Components:
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 jdbc-n
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
Assig
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 ot
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: I
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 Versi
Hi Andrea,
On Thu, Jul 2, 2009 at 4:16 PM, Andrea Aime 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 prepared on ima
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 log
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
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 li
Okay fixing as late as possible in DataUtiltiies.urlToFile method
worked like a charm.
It is now safe to run mac system update.
Jody
On Thu, Jul 2, 2009 at 3:41 PM, Jody Garnett wrote:
> File.toURI().toURL() is definitely broken in the latest mac release.
> "Fortuantly" it is broken in the same w
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 s
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
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 atta
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 environ
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.fi
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 b
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 h
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
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
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 ve
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 te
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
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 ca
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
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
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
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
Ciao Michael,
can you jump on irc, I'd like to ask you a few things about the disk
based tile cache.
Simone.
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 058498
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 settings
+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
http://simboss.blogspot
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 facto
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 the
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 movin
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 cor
57 matches
Mail list logo
