I'll do the class moves today in time for the first build containing sequence2 which is due tomorrow.
I've updated the release plan to indicate the correct release date for seq2 (and also removed xml property panels for this release). If anyone else has anything in the release schedule the think needs adjusting then please do so. Is there anything not going to make it in time? Are there any other major new features to note? Linus - a reminder for you to take a look at issue 5553. Please make sure that the new build does create a new style sequence diagram before making it publicly available. Bob. 2008/12/18 Bob Tarling <[email protected]>: > Yes, the proppanel stuff is minimal. I'd be happy to have those in the > main package for the module it makes sense to also have the module > registration there. > > I'd suggest that, for the time being, the one notation class that is > currently in the sequence2 module is moved to core ArgoUML with the > other UML1.4 notations. If nobody objects I'll go ahead and do that. > > I don't think a notation belongs to any one diagram type even if it is > only used by that diagram. I think all the notations for UML1.4 belong > in one place for reuse by what ever needs it. > > For example if the sequence diagram module was rewritten once more > using eclipse graph elements then it would want access to the same > notations. > > It would be nice to see the UML1.4 notation moving to its own module > or maybe within Model/MDR. > >> As I've said many times, the OSGi/Eclipse plugin model is the one that >> ArgoUML should migrate to. > > I don't think we have any expertise on this but I think we're all > agreed that using common standards can only help us. > > I'll do what I suggested previously for the wiki and create a proposal > page then I'll create a placeholder for this proposal. > > These are the major links I've found regarding this > > http://www.eclipse.org/equinox/ > http://www.osgi.org/Specifications/HomePage > > Regards > > Bob. > > 2008/12/17 Tom Morris <[email protected]>: >> Thanks for the summary and the additional detail. That helps >> understand the proposal. >> >> I think the crosscutting issue is something that you are going to have >> no matter what organization you pick. It's just the nature of the >> beast. I don't see a reason that the package structure needs to >> mirror the structure of what's being extended. >> >> I think there are too many packages in both the old and the new >> structure. I can't really see having a package for 1 or 2 classes. >> >> Here's what I'd suggest - just two packages (actually I think this is >> the same or similar to what Linus suggested too): >> >> org. >> argouml. >> sequence2. // module registration (4), prop panel & >> factory(1), notation(2) >> diagram // The actual diagram implementation graph >> model, diagram Figs etc (3 & 5) >> >> Any reverse engineering stuff is probably only going to be a class or >> two, so it can go in the top level package as well. If it looks like >> there are going to be a dozen or more critic classes, they can go in >> their own package org.argouml.sequence2.critics. >> >>>> If the modules and subsystems match, should we redefine the subsystems to >>>> improve on the understanding of the system? >>> >>> I'm not sure what you mean by "If the modules and subsystems match". >>> There are no new subsystem here so that requires no new change to >>> subsystem descriptions. >>> >>> Maybe what needs clarifying is my view of modules as components. I >>> think in the past it has been assumed that a module would be a >>> subsystem. However seq2 proves that a module actually needs to extend >>> and integrate to various subsystems of the main application. >> >> Yes, modules definitely need to extend multiple subsystems, but I >> think we need to think in terms of making the modularity more fine >> grained in general. There's no reason that seq2 critics need to go >> into the seq2 module. They could be in a module of their own or there >> could be a set in the seq2 module and then someone else could come >> along a provide an "enhanced critics" module which provided additional >> seq2 critics as well as additional use case or core critics. >> >> For reference, in Eclipse terms, units of redistributable code are >> called "plugins". Plugins map 1:1 with Eclipse projects. Plugins can >> be grouped into "features" which are chunks of functionality that make >> sense from a user's point of view. Plugins can provide "extension >> points" which are well defined interfaces for plugging things >> together. Plugins can also provide "extensions" to the extension >> points defined in other plugins (thus introducing a dependency). Each >> plugin can provide multiple extensions and multiple extension points, >> so there's a many to many mapping, but no cycles are allowed in the >> dependency graph. >> >> As I've said many times, the OSGi/Eclipse plugin model is the one that >> ArgoUML should migrate to. >> >> Tom >> >> ------------------------------------------------------ >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=985890 >> >> To unsubscribe from this discussion, e-mail: >> [[email protected]]. >> > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=987419 To unsubscribe from this discussion, e-mail: [[email protected]].
