Re: [JPP-Devel] UI direction for native database integration

[Rahkonen Jukka <Jukka.Rahkonen@mm...>]

Hi,

For my mind your ideas about embedded H2 would make OpenJUMP somehow unique as a GIS software (in addition to its inability to reproject data).  So go ahead!

-Jukka-

Christopher wrote:
 

Using H2 as the base storage/retrieval module for OJ is my end goal, and for that H2 embedded is without a doubt the best choice. I think, though, that I will program everything to use automatic mixed mode: the first program to open the database gets it in embedded mode then it opens a server so that other programs can access the database using TCP. The standard use case where embedded mode would be assumed is opening a local, unshared file, which would work as assumed when using automatic mixed mode while still gracefully allowing other use cases.

--Christopher

--- On Thu, 5/28/09, Stefan Steiniger <sstein@...> wrote:

> From: Stefan Steiniger <sstein@...>
> Subject: Re: [JPP-Devel] UI direction for native database integration
> To: "OpenJump develop and use" <jump-pilot-devel@...>
> Date: Thursday, May 28, 2009, 2:17 PM
> well... the original (and existing)
> idea was to use H2 embedded to 
> overcome our memory dependence.
> 
> stefan
> 
> Larry Becker wrote:
> > Another factor to consider is embedded H2 vs server
> H2.  Embedded is 
> > faster so it should probably be used for option 1 and
> default use.  
> > Personally, I'm more excited about the ability to
> collaborate with other 
> > users using server H2.  The connection strings
> control which is used so 
> > there is probably nothing to program.  Just
> include the h2 jar in lib to 
> > get embedded and trust the user to install h2 server.
> >  
> > Larry
> > 
> >  
> > On 5/27/09, *Michaël Michaud* <michael.michaud@...
> 
> > <mailto:michael.michaud@...>>
> wrote:
> > 
> >     Hi,
> > 
> >     I second Paolo in most of his
> comments :
> > 
> >     Option 1 would be great for
> data/project exchange. Including project
> >     information (layer styles) in
> the database would be great also, but it
> >     may be difficult to manage
> style definitions in both xml files and
> >     database. About references to
> external data, I can see pros (more
> >     freedom about how and where to
> store data) and cons (may be difficult to
> >     know what to transfer if you
> want to move the entire project).
> > 
> >     Option 2 : agree with 
> Paolo, just a different UI to access database
> >     table (nice but not as
> important as 1 and 3).
> > 
> >     Option 3 : probably the best
> short term goal. But again agree with
> >     Paolo. Main questions are not
> related to UI but to the datastore access
> >     capabilities, writing access,
> access to huge tables, transaction
> >     management...But I'm not an
> expert in that domain and I'm sure that
> >     Larry's propositions to track
> feature modifications will make some of
> >     these things possible.
> > 
> >     Very exciting propositions
> indeed.
> > 
> >     Michaël
> > 
> > 
> >     Paolo Rizzi a écrit :
> >      > Option 1 is intriguing,
> because it would be a very good mean of
> >      > exchanging geo data, a single
> file with everything inside, very
> >     good!!!
> >      > Maybe an ibrid solution were
> the project is itself store inside
> >     the H2
> >      > database, while each Layer
> can be internal or external would be even
> >      > better. Also you could store
> inside the H2 project both a Layer
> >     data and
> >      > a reference to its original
> provenience, to support some form of
> >      > disconnected editing, but
> this is maybe too sophysticated...
> >      >
> >      > Option number 2 would be just
> a shortcut upon number 3, a
> >     different UI
> >      > to select a database table,
> so it doesn't seems interesting.
> >      >
> >      > Option number 3 is good
> enough, but remember that DataStores are
> >      > read-only, so this would be a
> very good time to extend them to
> >     support
> >      > writing.
> >      > There were a couple of
> threads a few weeks ago about this and about
> >      > tracking modifications inside
> features.
> >      > The main goal was to be able
> to incrementally commit changes to a
> >     DataStore.
> >      > A simpler solution, but good
> enough for a start, would be to only
> >      > support complete Layer write
> inside a DataStore.
> >      > That is, always re-write the
> entire Layer each time, just like
> >     you would
> >      > do with a shape file.
> >      > Problem is with DataStores
> you don't have the entire Layer in memory.
> >      > So, to support this complete
> re-write, you should read the entire
> >     Layer
> >      > in memory, truncate the
> database table and recreate it. But this is
> >      > quite a dangerous solution,
> because if OJ crashes for any reason, you
> >      > loose your database data,
> unless you made good use of RDBMS
> >     transactions.
> >      > Another solution would be to
> create a new table inside the database
> >      > where you can merge the old
> table with the modified features you
> >     have in
> >      > memory, but this would not be
> very different from doing
> >     incremental writes.
> >      > Summing it up, it seems that
> supporting incremental writes for
> >     DataStore
> >      > is indeed needed anyway.
> >      >
> >      > Bye
> >      > Paolo
> >      >
> >      >
> >      >
> >      >> What direction(s) does
> the community want me to go toward with
> >     regards to integrating the H2
> database into OpenJUMP?
> >      >>
> >      >> Here's some initial
> options I've come up with:
> >      >>
> >      >> 1) Project as a
> database:
> >      >> When creating or saving a
> new project, you could select to make
> >     it a database project. Then
> all layers that are created are
> >     automatically saved into the
> database and when external layers are
> >     opened, the option for copying
> them into the database or leaving
> >     them external is given. To
> open a database project, simply open the
> >     associated H2 database.
> >      >> With this option, all
> project data can be stored in one file
> >     that can easily be moved
> around.
> >      >>
> >      >> 2) Database as a file
> folder:
> >      >> This is in the ArcMap
> style where the open file menu and save
> >     layer menus treats the
> database as simply another folder that you
> >     can navigate into and select
> individual files.
> >      >>
> >      >> 3 Database as a Data
> Store Layer:
> >      >> Use that Open Data Store
> and Connection Manager dialogues to
> >     manage opening and saving of
> layers. This would probably be the
> >     simplest to code with the
> least amount of core modification (if
> >     any), but I'm not sure that it
> would be as intuitive and invisible
> >     as it could be.
> >      >>
> >      >> Any comments or other
> suggestions?
> >      >>
> >      >> --Christopher
> >      >>
> >      >>
> >      >>
> >      >>
> >      >>
> > 
>    ------------------------------------------------------------------------------
> >      >> Register Now for
> Creativity and Technology (CaT), June 3rd, NYC. CaT
> >      >> is a gathering of
> tech-side developers & brand creativity
> >     professionals. Meet
> >      >> the minds behind Google
> Creative Lab, Visual Complexity,
> >     Processing, &
> >      >> iPhoneDevCamp as they
> present alongside digital heavyweights
> >     like Barbarian
> >      >> Group, R/GA, & Big
> Spaceship. http://p.sf.net/sfu/creativitycat-com
> >      >>
> _______________________________________________
> >      >> Jump-pilot-devel mailing
> list
> >      >> Jump-pilot-devel@...
> >     <mailto:Jump-pilot-devel@...>
> >      >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >      >>
> >      >
> >      >
> >      >
> > 
>    ------------------------------------------------------------------------------
> >      > Register Now for Creativity
> and Technology (CaT), June 3rd, NYC. CaT
> >      > is a gathering of tech-side
> developers & brand creativity
> >     professionals. Meet
> >      > the minds behind Google
> Creative Lab, Visual Complexity,
> >     Processing, &
> >      > iPhoneDevCamp as they present
> alongside digital heavyweights like
> >     Barbarian
> >      > Group, R/GA, & Big
> Spaceship. http://p.sf.net/sfu/creativitycat-com
> >      >
> _______________________________________________
> >      > Jump-pilot-devel mailing
> list
> >      > Jump-pilot-devel@...
> >     <mailto:Jump-pilot-devel@...>
> >      > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >      >
> >      >
> >      >
> > 
> > 
> > 
>    ------------------------------------------------------------------------------
> >     Register Now for Creativity
> and Technology (CaT), June 3rd, NYC. CaT
> >     is a gathering of tech-side
> developers & brand creativity
> >     professionals. Meet
> >     the minds behind Google
> Creative Lab, Visual Complexity, Processing, &
> >     iPhoneDevCamp as they present
> alongside digital heavyweights like
> >     Barbarian
> >     Group, R/GA, & Big
> Spaceship. http://p.sf.net/sfu/creativitycat-com
> > 
>    _______________________________________________
> >     Jump-pilot-devel mailing list
> >     Jump-pilot-devel@...
> >     <mailto:Jump-pilot-devel@...>
> >     https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> > 
> > 
> > 
> > 
> > -- 
> > Larry Becker
> > Integrated Systems Analysts, Inc.
> > 
> > 
> >
> ------------------------------------------------------------------------
> > 
> >
> ------------------------------------------------------------------------------
> > Register Now for Creativity and Technology (CaT), June
> 3rd, NYC. CaT 
> > is a gathering of tech-side developers & brand
> creativity professionals. Meet
> > the minds behind Google Creative Lab, Visual
> Complexity, Processing, & 
> > iPhoneDevCamp as they present alongside digital
> heavyweights like Barbarian 
> > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> > 
> > 
> >
> ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@...
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd,
> NYC. CaT 
> is a gathering of tech-side developers & brand
> creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity,
> Processing, & 
> iPhoneDevCamp as they present alongside digital
> heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@...
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 


      

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@...
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] [XxxJUMP-users] Re: IllegalArgumentException: No renderer defined

[Stefan Steiniger <sstein@ge...>]

Hei again,

Uh... I just mixed you up with a second Nils that wrote me yesterday on 
OJ use. So, you did do something different.

It would be actually wise to post those developing stuff rather to the 
developer list (there may be also more people that could answer - so I cc)

Now my question if I understood right:
a) you used openjump 1.3 and it did not work
b) you used JUMP 1.2 and it did work?

ok.. if so, then the reason is probably(?!) that we did some changes to 
the rendering framework in OJ 1.2/1.3 to allow it to work with custom 
renderers. For instance the raster image plugin from Pirol defines such 
a custom renderer (for example see: org.openjump.core.rasterimage).

Not sure, but maybe this page gives some more infos(?):

http://www.openjump.org/wiki/show/Notes+On+OpenJUMP%27s+Rendering+System

Do you think you will find the time to get it to run with OJ 1.3?

Anyway, thank you for informing us that this examples doesn't work in OJ 
  1.3 (I was believing that).

Can you also tell what you are actually trying to do (i.e. use it for 
web stuff or embedding it in a different software)?

thank you,
stefan

PS: there have been commits on 18 Dec. 2007 that may be related (see our 
change log file in the svn - or direct link from the openjump wiki 
frontpage)

2007-12-18 Paul Austin <paul.austin@...
   *  Migrated the Layer and WMSLayer to use the new RendererFactory 
implementation

2007-12-18 Paul Austin <paul.austin@...
   * Added a new RendererFactory implementation which accepts the 
LayerViewPanel
     as an argument.


nilsw wrote:
> Hi Stefan,
> 
> I was trying to load and display a shapefile, according to this
> example:
> 
> http://groups.google.com/group/openjump-users/msg/9af5e7ac58ef9a71
> 
> The stack trace is (w/o awt stuff):
> 
> java.lang.IllegalArgumentException: No renderer defined for layerable:
> Layer Name
> 	at
> com.vividsolutions.jump.workbench.ui.renderer.RenderingManager.createRenderer
> (RenderingManager.java:285)
> 	at
> com.vividsolutions.jump.workbench.ui.renderer.RenderingManager.render
> (RenderingManager.java:193)
> 	at
> com.vividsolutions.jump.workbench.ui.renderer.RenderingManager.render
> (RenderingManager.java:187)
> 	at com.vividsolutions.jump.workbench.ui.LayerViewPanel.layerChanged
> (LayerViewPanel.java:388)
> 	at com.vividsolutions.jump.workbench.model.LayerManager$3.run
> (LayerManager.java:433)
> 
> In the meantime, I managed to run this using the 1.2 version from the
> vividsolutions website, works perfectly.
> 
> Thanks for looking into this!
> 
> Best
> Nils
> 
> On May 29, 6:26 pm, Stefan Steiniger <sst...@...> wrote:
>> Hei Nils,
>>
>> can you describe what you exactly did (i.e. the steps, what was you goal?).
>>
>> and can you also post the full stack trace/error message?
>>
>> what is in the shape file (datatype?)
>>
>> stefan
>>
>> nilsw schrieb:
>>
>>> Hi all,
>>> I'm getting an
>>> java.lang.IllegalArgumentException: No renderer defined for layerable:
>>> Layer Name
>>> when trying to render a shapefile using
>>> Layer layer = view.getLayerManager().addLayer("Category Name", "Layer
>>> Name", features);
>>> This code is taken from an earlier post in this group, so I assume it
>>> did work some time ago. I tried both openjump 1.3 and 1.2, with the
>>> same result.
>>> Your help would be much appreciated!
>>> Best,
>>> Nils
> 
> 

Re: [JPP-Devel] H2/OpenJUMP integration week 1

[Stefan Steiniger <sstein@ge...>]

Hei Christopher,

so all the best for the wedding ceremony/party etc. No problem with 
taking more time off. As you know OJ already you do not need to get 
introduced and we save lots of time.

on the different Data store/access frameworks stuff: If you feel you 
have made you mental map about those things, please write them down. 
Even it is takes a lot of time, it will be of benefit to all core 
developers since the people who programmed and designed those have 
either left (Jon Aquino) or are rather consultants (Martin Davis) to the 
project. So, having a documentation (that may even take 2 weeks todo) is 
to us as important as having a second access method to H2 or so.

until next week
stefan

Christopher wrote:
> 
> This week, I finalized the direction of the project and began coding the first stage: a simple read only plugin for the H2 database modeled along the lines of the current postgis plugin. Next week, I will finish that plugin then begin work on adding read/write capability to OpenJUMP's DataStore framework. The biggest problem I had this week was keeping JUMP's DataStore, JUMP's DataSource, and Java's DataSource frameworks all separate in my head. A second problem was that I was strapped for manhours this week due to my big wedding happening tomorrow (my wife and I were legally married in a small ceramony last November before my dad died of Multiple Sclerosis this spring, now we're having the big party with all the relatives and associated stress ;)
> 
> My wiki page (hosted in the OpenJUMP wiki) is very rudimentary right now, but will be expanded as new problems, choices, and solutions appear.
> 
> --Christopher DeMars
> 
> 
>       
> 
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@...
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 
> 

Re: [JPP-Devel] UI direction for native database integration

[Christopher <infinityedge@ya...>]

Using H2 as the base storage/retrieval module for OJ is my end goal, and for that H2 embedded is without a doubt the best choice. I think, though, that I will program everything to use automatic mixed mode: the first program to open the database gets it in embedded mode then it opens a server so that other programs can access the database using TCP. The standard use case where embedded mode would be assumed is opening a local, unshared file, which would work as assumed when using automatic mixed mode while still gracefully allowing other use cases.

--Christopher

--- On Thu, 5/28/09, Stefan Steiniger <sstein@...> wrote:

> From: Stefan Steiniger <sstein@...>
> Subject: Re: [JPP-Devel] UI direction for native database integration
> To: "OpenJump develop and use" <jump-pilot-devel@...>
> Date: Thursday, May 28, 2009, 2:17 PM
> well... the original (and existing)
> idea was to use H2 embedded to 
> overcome our memory dependence.
> 
> stefan
> 
> Larry Becker wrote:
> > Another factor to consider is embedded H2 vs server
> H2.  Embedded is 
> > faster so it should probably be used for option 1 and
> default use.  
> > Personally, I'm more excited about the ability to
> collaborate with other 
> > users using server H2.  The connection strings
> control which is used so 
> > there is probably nothing to program.  Just
> include the h2 jar in lib to 
> > get embedded and trust the user to install h2 server.
> >  
> > Larry
> > 
> >  
> > On 5/27/09, *Michaël Michaud* <michael.michaud@...
> 
> > <mailto:michael.michaud@...>>
> wrote:
> > 
> >     Hi,
> > 
> >     I second Paolo in most of his
> comments :
> > 
> >     Option 1 would be great for
> data/project exchange. Including project
> >     information (layer styles) in
> the database would be great also, but it
> >     may be difficult to manage
> style definitions in both xml files and
> >     database. About references to
> external data, I can see pros (more
> >     freedom about how and where to
> store data) and cons (may be difficult to
> >     know what to transfer if you
> want to move the entire project).
> > 
> >     Option 2 : agree with 
> Paolo, just a different UI to access database
> >     table (nice but not as
> important as 1 and 3).
> > 
> >     Option 3 : probably the best
> short term goal. But again agree with
> >     Paolo. Main questions are not
> related to UI but to the datastore access
> >     capabilities, writing access,
> access to huge tables, transaction
> >     management...But I'm not an
> expert in that domain and I'm sure that
> >     Larry's propositions to track
> feature modifications will make some of
> >     these things possible.
> > 
> >     Very exciting propositions
> indeed.
> > 
> >     Michaël
> > 
> > 
> >     Paolo Rizzi a écrit :
> >      > Option 1 is intriguing,
> because it would be a very good mean of
> >      > exchanging geo data, a single
> file with everything inside, very
> >     good!!!
> >      > Maybe an ibrid solution were
> the project is itself store inside
> >     the H2
> >      > database, while each Layer
> can be internal or external would be even
> >      > better. Also you could store
> inside the H2 project both a Layer
> >     data and
> >      > a reference to its original
> provenience, to support some form of
> >      > disconnected editing, but
> this is maybe too sophysticated...
> >      >
> >      > Option number 2 would be just
> a shortcut upon number 3, a
> >     different UI
> >      > to select a database table,
> so it doesn't seems interesting.
> >      >
> >      > Option number 3 is good
> enough, but remember that DataStores are
> >      > read-only, so this would be a
> very good time to extend them to
> >     support
> >      > writing.
> >      > There were a couple of
> threads a few weeks ago about this and about
> >      > tracking modifications inside
> features.
> >      > The main goal was to be able
> to incrementally commit changes to a
> >     DataStore.
> >      > A simpler solution, but good
> enough for a start, would be to only
> >      > support complete Layer write
> inside a DataStore.
> >      > That is, always re-write the
> entire Layer each time, just like
> >     you would
> >      > do with a shape file.
> >      > Problem is with DataStores
> you don't have the entire Layer in memory.
> >      > So, to support this complete
> re-write, you should read the entire
> >     Layer
> >      > in memory, truncate the
> database table and recreate it. But this is
> >      > quite a dangerous solution,
> because if OJ crashes for any reason, you
> >      > loose your database data,
> unless you made good use of RDBMS
> >     transactions.
> >      > Another solution would be to
> create a new table inside the database
> >      > where you can merge the old
> table with the modified features you
> >     have in
> >      > memory, but this would not be
> very different from doing
> >     incremental writes.
> >      > Summing it up, it seems that
> supporting incremental writes for
> >     DataStore
> >      > is indeed needed anyway.
> >      >
> >      > Bye
> >      > Paolo
> >      >
> >      >
> >      >
> >      >> What direction(s) does
> the community want me to go toward with
> >     regards to integrating the H2
> database into OpenJUMP?
> >      >>
> >      >> Here's some initial
> options I've come up with:
> >      >>
> >      >> 1) Project as a
> database:
> >      >> When creating or saving a
> new project, you could select to make
> >     it a database project. Then
> all layers that are created are
> >     automatically saved into the
> database and when external layers are
> >     opened, the option for copying
> them into the database or leaving
> >     them external is given. To
> open a database project, simply open the
> >     associated H2 database.
> >      >> With this option, all
> project data can be stored in one file
> >     that can easily be moved
> around.
> >      >>
> >      >> 2) Database as a file
> folder:
> >      >> This is in the ArcMap
> style where the open file menu and save
> >     layer menus treats the
> database as simply another folder that you
> >     can navigate into and select
> individual files.
> >      >>
> >      >> 3 Database as a Data
> Store Layer:
> >      >> Use that Open Data Store
> and Connection Manager dialogues to
> >     manage opening and saving of
> layers. This would probably be the
> >     simplest to code with the
> least amount of core modification (if
> >     any), but I'm not sure that it
> would be as intuitive and invisible
> >     as it could be.
> >      >>
> >      >> Any comments or other
> suggestions?
> >      >>
> >      >> --Christopher
> >      >>
> >      >>
> >      >>
> >      >>
> >      >>
> > 
>    ------------------------------------------------------------------------------
> >      >> Register Now for
> Creativity and Technology (CaT), June 3rd, NYC. CaT
> >      >> is a gathering of
> tech-side developers & brand creativity
> >     professionals. Meet
> >      >> the minds behind Google
> Creative Lab, Visual Complexity,
> >     Processing, &
> >      >> iPhoneDevCamp as they
> present alongside digital heavyweights
> >     like Barbarian
> >      >> Group, R/GA, & Big
> Spaceship. http://p.sf.net/sfu/creativitycat-com
> >      >>
> _______________________________________________
> >      >> Jump-pilot-devel mailing
> list
> >      >> Jump-pilot-devel@...
> >     <mailto:Jump-pilot-devel@...>
> >      >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >      >>
> >      >
> >      >
> >      >
> > 
>    ------------------------------------------------------------------------------
> >      > Register Now for Creativity
> and Technology (CaT), June 3rd, NYC. CaT
> >      > is a gathering of tech-side
> developers & brand creativity
> >     professionals. Meet
> >      > the minds behind Google
> Creative Lab, Visual Complexity,
> >     Processing, &
> >      > iPhoneDevCamp as they present
> alongside digital heavyweights like
> >     Barbarian
> >      > Group, R/GA, & Big
> Spaceship. http://p.sf.net/sfu/creativitycat-com
> >      >
> _______________________________________________
> >      > Jump-pilot-devel mailing
> list
> >      > Jump-pilot-devel@...
> >     <mailto:Jump-pilot-devel@...>
> >      > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >      >
> >      >
> >      >
> > 
> > 
> > 
>    ------------------------------------------------------------------------------
> >     Register Now for Creativity
> and Technology (CaT), June 3rd, NYC. CaT
> >     is a gathering of tech-side
> developers & brand creativity
> >     professionals. Meet
> >     the minds behind Google
> Creative Lab, Visual Complexity, Processing, &
> >     iPhoneDevCamp as they present
> alongside digital heavyweights like
> >     Barbarian
> >     Group, R/GA, & Big
> Spaceship. http://p.sf.net/sfu/creativitycat-com
> > 
>    _______________________________________________
> >     Jump-pilot-devel mailing list
> >     Jump-pilot-devel@...
> >     <mailto:Jump-pilot-devel@...>
> >     https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> > 
> > 
> > 
> > 
> > -- 
> > Larry Becker
> > Integrated Systems Analysts, Inc.
> > 
> > 
> >
> ------------------------------------------------------------------------
> > 
> >
> ------------------------------------------------------------------------------
> > Register Now for Creativity and Technology (CaT), June
> 3rd, NYC. CaT 
> > is a gathering of tech-side developers & brand
> creativity professionals. Meet
> > the minds behind Google Creative Lab, Visual
> Complexity, Processing, & 
> > iPhoneDevCamp as they present alongside digital
> heavyweights like Barbarian 
> > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> > 
> > 
> >
> ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@...
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd,
> NYC. CaT 
> is a gathering of tech-side developers & brand
> creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity,
> Processing, & 
> iPhoneDevCamp as they present alongside digital
> heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@...
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 


      

[JPP-Devel] H2/OpenJUMP integration week 1

[Christopher <infinityedge@ya...>]

This week, I finalized the direction of the project and began coding the first stage: a simple read only plugin for the H2 database modeled along the lines of the current postgis plugin. Next week, I will finish that plugin then begin work on adding read/write capability to OpenJUMP's DataStore framework. The biggest problem I had this week was keeping JUMP's DataStore, JUMP's DataSource, and Java's DataSource frameworks all separate in my head. A second problem was that I was strapped for manhours this week due to my big wedding happening tomorrow (my wife and I were legally married in a small ceramony last November before my dad died of Multiple Sclerosis this spring, now we're having the big party with all the relatives and associated stress ;)

My wiki page (hosted in the OpenJUMP wiki) is very rudimentary right now, but will be expanded as new problems, choices, and solutions appear.

--Christopher DeMars