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 <[email protected]> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
