Yes, I can see that you would then lose the tracking of all of the re-factoring changes, I just feel sorry for you having to deal with all of those file moves in SVN. :)
re: XText, I don't know if this is in scope for refactoring, but it would be nice to have an SDK feature sans XText/TMF dependencies. Let me know if you want me to open a bug on that.
On Sep 28, 2011, at 12:56 AM, LETAVERNIER Camille wrote: Hello Miles, We’ve actually planned to move to Git, once the refactoring is done. We don’t want to make the two changes at the same time J By doing so, we should have a clean repository right after the migration. Regarding the X-Text stuff, I guess they can be treated as an extra feature, as they aren’t mandatory for the diagrams to work. Camille De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Miles Parker Envoyé : mardi 27 septembre 2011 22:26 À : Papyrus Project list Objet : Re: [mdt-papyrus.dev] Papyrus refactoring Great. As a consumer, I have had a difficult time grokking what is going on with all of the various dependencies, esp. in say setting up a test runtime or build. In particular, it would be good to have a really clear separation for TMF / XText stuff. Not that that stuff isn't extremely cool, but it does bring in a lot of runtime dependencies as well as potential for some tricky runtime issues WRT to guice, etc. Can I make one big suggestion/plea to take this opportunity to move to git? :D It just makes it sooo much easier to grab a quick fork, play with changes locally, make patches, integrate with other build architectures, etc.. It seems like it would be a shame to spend a lot of time moving things around in SVN when you'll eventually need to move off of SVN anyway. (btw, I've also seen a number of issues with ServiceRegistry. Yep, I think I filed them.) On Sep 27, 2011, at 6:42 AM, LETAVERNIER Camille wrote:
In prevision of the next version of Papyrus (0.9.0, based on Juno), we plan to do a global refactoring of the Papyrus architecture. The base architecture is not clear anymore, and some plug-ins have become really messy. It is hard to distribute Papyrus in distinct features, as most plug-ins are inter-related. Before doing this refactoring, we want to open the discussion to the Mailing List, so that everyone knows what’s going to happen, when, and how. So, here are the main lines : o Identify the different architecture layers and sub-layers o Associate each plug-in to a layer. This may require to split or merge some plug-ins o Map the svn folders to the Papyrus layers (Each folder should represent either a layer or a sub-layer) o Clean the svn, by moving the deprecated plug-ins and code to the deprecated folder o Associate the main layers or sub-layers to a distributable feature These tasks will take time, and each developer will have to be aware of the process. Here are the actual tasks : - Commit your current developments ; it will be harder when the refactoring has started o Add a documentation to each plug-in : we ask all developers to add a document file to their own plug-ins (Bug 359060) o Determine the format of the documentation file (Text file, EMF Model, is there an existing format ?) : This should be done quickly (This week if possible). The format can be improved later on. (Bug 359061) - Identify the architecture layers and sub-layers (Bug 359058) - Associate each plug-in to the corresponding layer, and check the resulting dependencies. o Adjust the plug-ins contents until the dependencies match the architecture - Specify the maximum length of a plug-in file’s qualified name (Plug-in name + path to the file) - Rename the plug-ins or packages which name is longer than the specified max length - Rename the folders on the SVN to match the layers and sublayers (Bug 359063) - Create a feature for each layer - Move the plug-ins to the SVN folder corresponding to their layer - Add the plug-ins to the feature corresponding to their layer The preparation should take between one and two weeks. The actual refactoring will start in two weeks. Some tasks can be done quickly (Reorganization), but there are two other tasks, more complex, which will take more time : the ModelSet re-specification, and the access to the “current” model without calling the active Papyrus Editor. They will be discussed in another e-mail. The global Bugzilla task for the whole refactoring is here : 359057: [Architecture - SVN - Build] The Papyrus architecture should be refactored Do not hesitate to add subtasks for all refactoring-related tasks (Even for local refactorings, which only impact your own plug-ins) _______________________________________________ mdt-papyrus.dev mailing list mdt-papyrus.dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
|