On Tue, Aug 13, 2013 at 1:32 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Tue, Aug 13, 2013 at 3:51 AM, Justin Deoliveira
> <jdeol...@opengeo.org>wrote:
>
>>
>>
>>
>> On Mon, Aug 12, 2013 at 11:35 AM, Andrea Aime <
>> andrea.a...@geo-solutions.it> wrote:
>>
>>> On Mon, Aug 12, 2013 at 5:37 PM, Justin Deoliveira <jdeol...@opengeo.org
>>> > wrote:
>>>
>>>> The changes live in my forked copy of the main repository.
>>>>
>>>> https://bitbucket.org/jdeolive/sqlite-jdbc/
>>>>
>>>> The customizations are mostly to the make files to pull in spatialite
>>>> and link against proj and geos. They also contain some code changes that
>>>> enable an option to trigger the spatialite initialization.
>>>>
>>>
>>> Ah ok, so the driver jar really embeds native libraries for all the
>>> platforms, and you modified it so that the .so/.dll now embed not only
>>> libsqlite and the JNI wrappers around it, but also spatialite, GEOS and
>>> proj?
>>>
>>
>> Mostly correct. The built library contains a full static build of sqlite
>> and spatialite amalgamated. The resulting binary is linked dynamically to
>> proj and geos. So you need to have proj and geos installed on the system.
>> The reason we amalgamate the spatialite build rather than dynamically link
>> to it is to avoid conflicts between the sqlite already installed on the
>> system and the one bundled internally by xerial.
>>
>> Thinking about the whole mess it would probably just be easier to strip
>> out the internal sqlite used by the xerial driver and completely rely on
>> dynamic linking.
>>
>
> That sounds like an interesting approach. Of course, it would not work
> with applets, but for desktop and server applications it seems like an
> option.
> So the driver would just ship with the .so/.dll containing the JNI
> bindings?
>
Yeah, that is the idea.
Taking this idea to the other end of the spectrum would be to ship with a
library that is 100% statically linked, containing all of sqlite,
spatialite, proj and geos. I had one of our devops guys work on this a
while back to see if it was even feasible. IT worked like a charm on linux
and osx but he couldn't make it work on windows. It also made the resulting
artifact fairly large.
> As a related notice, I just read yesterday about a new JDBC driver for
> sqlite using Bridj, that would not even require the JNI library... but I
> cannot find the links anymore...
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
