[Geoserver-devel] 2.1.x road map, hibernate catalog, and resource publishing split

GeoServer GeoServer Developer
1

Hi all,

Looking at the road map for 2.1 (trunk) there are currently two major developments on the horizon:

* resource publishing split
* hibernate catalog

Resource-publishing has been going on in a branch i have been maintaining locally, and the hibernate catalog has been going on in a community module.

I am getting to the point where I would like to start committing my work (resource pub) directly to trunk. If anything because the longer I wait the greater the risk of my branch becoming out of date becomes.

However the changes are not trivial as you can imagine. They cut across the configuration and catalog sub systems which will unfortunately conflict with the hibernate catalog work. If I were to commit now it would undoubtedly push back the hibernate catalog work because it would require a major resynchronization.

There is also the question of resourcing and timeline. Currently there has been no date set for when the hibernate catalog is to come home. And there is still work required to factor out a lot of the duplication that has been done to get around changing anything in the core.

How how do we proceed? The smoothest path I see to bringing both efforts home would be to bring the hibernate catalog work home first. But to do this we address the outstanding issues. And by "issues" i mean the things I brought up with I did my initial review:

   * Use a single set of java beans
   * Refactor commonalities from HibernateCatalog and CatalogImpl into a base class to avoid duplication

With that in place it would make my job a lot of easier. I can reupdate my local branch and make the required changes to the catalog (hibernate and memory) without having to worry about alienating other catalog implementations.

Thoughts?

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

2

Hi Justin,

This is mostly what I would love to resolve in a roadmap discussion-
what is landing on trunk when.

If we cannot nail the hibernate catalog down to a set date (say this
year) you should probably go ahead with the resource publishing split.

Do we have any idea of Geo-Solutions availability in December?

Jody

On Wed, Dec 2, 2009 at 9:33 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

Looking at the road map for 2.1 (trunk) there are currently two major
developments on the horizon:

* resource publishing split
* hibernate catalog

Resource-publishing has been going on in a branch i have been
maintaining locally, and the hibernate catalog has been going on in a
community module.

I am getting to the point where I would like to start committing my work
(resource pub) directly to trunk. If anything because the longer I wait
the greater the risk of my branch becoming out of date becomes.

However the changes are not trivial as you can imagine. They cut across
the configuration and catalog sub systems which will unfortunately
conflict with the hibernate catalog work. If I were to commit now it
would undoubtedly push back the hibernate catalog work because it would
require a major resynchronization.

There is also the question of resourcing and timeline. Currently there
has been no date set for when the hibernate catalog is to come home. And
there is still work required to factor out a lot of the duplication that
has been done to get around changing anything in the core.

How how do we proceed? The smoothest path I see to bringing both efforts
home would be to bring the hibernate catalog work home first. But to do
this we address the outstanding issues. And by "issues" i mean the
things I brought up with I did my initial review:

* Use a single set of java beans
* Refactor commonalities from HibernateCatalog and CatalogImpl into a
base class to avoid duplication

With that in place it would make my job a lot of easier. I can reupdate
my local branch and make the required changes to the catalog (hibernate
and memory) without having to worry about alienating other catalog
implementations.

Thoughts?

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

Ciao Justin,
as discussed during our last chat, I think it is time to
re-synchronize about this topic.
I am suggesting this timing:

http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=12&day=4&hour=14&min=0&sec=0&p1=179&p2=215

Of course everyone is more than welcome to participate, and anyway we
will send out the logs after the discussion.

Ciao,
Simone
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - 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://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

-------------------------------------------------------

On Tue, Dec 1, 2009 at 11:33 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

Looking at the road map for 2.1 (trunk) there are currently two major
developments on the horizon:

* resource publishing split
* hibernate catalog

Resource-publishing has been going on in a branch i have been
maintaining locally, and the hibernate catalog has been going on in a
community module.

I am getting to the point where I would like to start committing my work
(resource pub) directly to trunk. If anything because the longer I wait
the greater the risk of my branch becoming out of date becomes.

However the changes are not trivial as you can imagine. They cut across
the configuration and catalog sub systems which will unfortunately
conflict with the hibernate catalog work. If I were to commit now it
would undoubtedly push back the hibernate catalog work because it would
require a major resynchronization.

There is also the question of resourcing and timeline. Currently there
has been no date set for when the hibernate catalog is to come home. And
there is still work required to factor out a lot of the duplication that
has been done to get around changing anything in the core.

How how do we proceed? The smoothest path I see to bringing both efforts
home would be to bring the hibernate catalog work home first. But to do
this we address the outstanding issues. And by "issues" i mean the
things I brought up with I did my initial review:

* Use a single set of java beans
* Refactor commonalities from HibernateCatalog and CatalogImpl into a
base class to avoid duplication

With that in place it would make my job a lot of easier. I can reupdate
my local branch and make the required changes to the catalog (hibernate
and memory) without having to worry about alienating other catalog
implementations.

Thoughts?

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

That is out of my time range, can you update the roadmap page for 2.1
when you are done? While I have volunteered to update the roadmap (so
Mark can make a release) I do not want to sift through logs with the
possibility of misunderstanding your decisions.

Jody

On Fri, Dec 4, 2009 at 5:47 AM, Simone Giannecchini
<simone.giannecchini@anonymised.com> wrote:

Ciao Justin,
as discussed during our last chat, I think it is time to
re-synchronize about this topic.
I am suggesting this timing:

http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=12&day=4&hour=14&min=0&sec=0&p1=179&p2=215

Of course everyone is more than welcome to participate, and anyway we
will send out the logs after the discussion.

Ciao,
Simone
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - 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://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

-------------------------------------------------------

On Tue, Dec 1, 2009 at 11:33 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

Looking at the road map for 2.1 (trunk) there are currently two major
developments on the horizon:

* resource publishing split
* hibernate catalog

Resource-publishing has been going on in a branch i have been
maintaining locally, and the hibernate catalog has been going on in a
community module.

I am getting to the point where I would like to start committing my work
(resource pub) directly to trunk. If anything because the longer I wait
the greater the risk of my branch becoming out of date becomes.

However the changes are not trivial as you can imagine. They cut across
the configuration and catalog sub systems which will unfortunately
conflict with the hibernate catalog work. If I were to commit now it
would undoubtedly push back the hibernate catalog work because it would
require a major resynchronization.

There is also the question of resourcing and timeline. Currently there
has been no date set for when the hibernate catalog is to come home. And
there is still work required to factor out a lot of the duplication that
has been done to get around changing anything in the core.

How how do we proceed? The smoothest path I see to bringing both efforts
home would be to bring the hibernate catalog work home first. But to do
this we address the outstanding issues. And by "issues" i mean the
things I brought up with I did my initial review:

* Use a single set of java beans
* Refactor commonalities from HibernateCatalog and CatalogImpl into a
base class to avoid duplication

With that in place it would make my job a lot of easier. I can reupdate
my local branch and make the required changes to the catalog (hibernate
and memory) without having to worry about alienating other catalog
implementations.

Thoughts?

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

5

Hi all,

after the IRC chat we had (whoever needs the logs can ask me), I put down the
proposals in a couple of wiki pages:

   Catalog+DAO refactoring
      http://geoserver.org/pages/viewpage.action?pageId=22708796

This one is direclty addressing the issue Justin raised:

> * Refactor commonalities from HibernateCatalog and CatalogImpl into a
> base class to avoid duplication

   Resource *Info beans refactoring
      http://geoserver.org/display/GEOS/Resource+*Info+beans+refactoring

This second one will help in having xxxInfo beans that abstract from their
referred data and from the context in general.

Please let me know what you think about it.

   Ciao,
   Emanuele

Alle 19:47:34 di giovedì 3 dicembre 2009, Simone Giannecchini ha scritto:

Ciao Justin,
as discussed during our last chat, I think it is time to
re-synchronize about this topic.
I am suggesting this timing:

http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=1
2&day=4&hour=14&min=0&sec=0&p1=179&p2=215

Of course everyone is more than welcome to participate, and anyway we
will send out the logs after the discussion.

Ciao,
Simone
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - 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://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

-------------------------------------------------------

On Tue, Dec 1, 2009 at 11:33 PM, Justin Deoliveira <jdeolive@anonymised.com>

wrote:

> Hi all,
>
> Looking at the road map for 2.1 (trunk) there are currently two major
> developments on the horizon:
>
> * resource publishing split
> * hibernate catalog
>
> Resource-publishing has been going on in a branch i have been
> maintaining locally, and the hibernate catalog has been going on in a
> community module.
>
> I am getting to the point where I would like to start committing my work
> (resource pub) directly to trunk. If anything because the longer I wait
> the greater the risk of my branch becoming out of date becomes.
>
> However the changes are not trivial as you can imagine. They cut across
> the configuration and catalog sub systems which will unfortunately
> conflict with the hibernate catalog work. If I were to commit now it
> would undoubtedly push back the hibernate catalog work because it would
> require a major resynchronization.
>
> There is also the question of resourcing and timeline. Currently there
> has been no date set for when the hibernate catalog is to come home. And
> there is still work required to factor out a lot of the duplication that
> has been done to get around changing anything in the core.
>
> How how do we proceed? The smoothest path I see to bringing both efforts
> home would be to bring the hibernate catalog work home first. But to do
> this we address the outstanding issues. And by "issues" i mean the
> things I brought up with I did my initial review:
>
> * Use a single set of java beans
> * Refactor commonalities from HibernateCatalog and CatalogImpl into a
> base class to avoid duplication
>
> With that in place it would make my job a lot of easier. I can reupdate
> my local branch and make the required changes to the catalog (hibernate
> and memory) without having to worry about alienating other catalog
> implementations.
>
> Thoughts?
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.