I agree with Andrea. You can do a quick feasability study of changing the package names to eu.udig but I want you to focus on the persistance task and not get distracted. You are tackling a rather giant amount of work as it is :).
I took a look at the proposal. What is the ability to control the loading of layer with CDO? I recently tried to fix a bug that is simply impossible to accomplish with the current implementation and if we change the persistence mechanism I would like to be sure we can fix that issue as well. Essentially the problem was that during the creation of a layer events were raised that triggered resources in the catalog to be loaded when they should not have been. I would like to be able to have good hooks into the loading process so we can control it well. Also is it worth having such a complex solution? I know lots of people are extremely intimidated by the EMF model and would like a simpler solution. Are there any alternatives? I am not saying we should not go with CDO as I am comfortable with EMF, I just want to make sure we look at other potential alternatives as well. Jesse On Fri, Aug 5, 2011 at 12:36 AM, Kenneth Gulbrandsoy < [email protected]> wrote: > Hi list! > > I have now updated the RFC > proposal<http://udig.refractions.net/confluence/display/UDIG/Next+generation+resource+persistence+in+uDig> > to > reflect my posts, IRC chats and comments from the list, and I think it is > good enough to be voted upon by the PMC and committers. So far, I have > received positive feedback from Andrea (moodiva), Jody and Jesse. > > Since this RFC propose major (and overdue) changes to how uDig persist > model resources, all uDig projects from version 1.2.2 and backwards will be > broken. To remedy this, an uDig project import method is proposed, allowing > old projects to be (automatically) converted and imported into the new > persistence framework. > > *Be aware that if the RFC is approved, all community plug-ins will be > affected because*: > > - uDig model will be refactored to *eu.udig.* *which breaks any > existing dependencies on model objects > - Plug-ins depending on non-standard EMF behavior of current models > will be broken after the change > > As a result, all maintainers of community plug-ins are encouraged to read > this RFC and give their feedback (and vote, even if they are not a PMC > member or committer). This will help the PMC to make the best possible > decision. > > Cheers, > Kenneth > > 2011/8/4 Kenneth Gulbrandsoy <[email protected]> > >> Hi folks! >> >> I'm back on a decent internet connection, and have some e-mail reading and >> writing to do. Anyways, see comments below. >> >> 2011/7/28 Jody Garnett <[email protected]> >> >>> I am looking forward to the updated proposal. >>> >>> >>>> I'm willing to do much of this work after my summer vacation, >>>>> hopefully with the support of the PMCs and Jesse in particular. >>>>> >>>> >>>> Kill maim destroy. We might have to rename this to uDig 2.0 because it >>>> will break extensions but I think this is a long overdue. >>>> >>> >>> You could also rename the packages to eu.udig and make moovida happy (and >>> me happy as well for consistency). >>> >> >> Do you mean the *.project *.printing model packages? I think that is an >> excellent idea. >> >> >>> More seriously if we are going to take on a whack of instability I would >>> like to keep the window short; I don't think we can be quick enough to set >>> this up as a code sprint topic for foss4g. >>> >> >> I agree. A code sprint would be really nice. I'm plan to attend the sprint >> on IRC (if all goes to plan, I will attend foss4g next year). >> >> >>> However I would like to be organised; be able to pass on a warning to my >>> project managers and generally co-ordinate resources to make this efficient. >>> >> >> Sure. Any preferences on how to do this? I will read up on how the code >> sprint is organized. Where can I start writing up a code sprint topic for >> foss4g? >> >> >>> >>> Jody >>> >>> _______________________________________________ >>> User-friendly Desktop Internet GIS (uDig) >>> http://udig.refractions.net >>> http://lists.refractions.net/mailman/listinfo/udig-devel >>> >>> >> Kenneth >> >> > > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel > >
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
