Hi Bob! > This page splits out work on property panels as if they are a part of > working on a diagram. That is not really the case. We could have > someone work on panels for just those elements on a class diagram but > the user can still load some XMI that contain other elements that will > fail if they select them in the explorer and they display in an > incomplete property panel. > > I'd suggest the blocks in that wiki for Class Diagram Implementation, > Use Case Diagram Implementation are reorgansied to contain also other > relevant subsystem as main blaock such as Property Panels and > Explorer. I don't think we can release any single diagram until those > are working. > > I'm happy to edit the wiki if this is agreeable but didn't want to go > to the effort unless others follow my logic.
You are absolutely right, put the explorer, persistence, property panels and whatever is needed to the appropriate sections. We can later restructure it again as soon as the dependencies get clearer. Thanks for clarifying. > Could we instead split a second explorer implementation following UML2 > design with ArgoUML loading one or the other depending on the UML > implementation? (hopefully there will still be some common logic we > can keep in just one place). I don't know if this is needed, and how much work it would be to let only one explorer instance handle both UML1.x and UML2.x elements, so I can't say anything here (yet). I have not found in Bogdan's reports that the explorer needed a significant change, he only wrote that he needed to change the core ArgoUML because he had not the time to use mementos but wanted to demonstrate undo/redo. > If we can first get the explorer into its own eclipse subproject we > can have only the eUML launcher include the replacement at startup and > current standard Argo load the existing explorer. If I understand correctly this also supports further modularization, am I right? It seems to be one possible approach. > Christian (penyaskito) and myself are concentrating at the moment on > revisiting the XML property panel module from his last GSOC in order > to get that in a state for release. > > The module is driven from an XML file that is derived from the UML1.4 > metamodel. The intention is then to drive that same module from an XML > derived from the UML2.x metamodel. > > This allows us to contribute towards UML2.x without actually getting > directly involved in the eUML subsystem. I agree. Christian (Penyaskito) already told me about it. Great! Can you add this to the wiki then? > For this reason I'd appreciate it if people kept enhancements to our > current property panels to a minimum. Please wait on the replacement > panels (or contribute you work there) or you will be giving us more > work to do to complete the replacement. OK. > My intention after this was to work on visualizing templates in > FigClass. I think thats long overdue but if others think I would do > better to contribute elsewhere then please suggest. It is really a missing feature, even for UML 1.4, and as a CG/RE module developer (for Java), I appreciate that work. > I see Tom has made some recent commits to eUML, that is good to see. I > wonder if Bogdan still intends to contribute. It is those two devs > with most experience in this area. Yes I wish he could review our ideas/plans. > What are your plans Thomas? I wanted to concentrate on UML2 only in the core project, and then only on the Java module. (I'll try at least.) > > The first one: How will the legacy UML 1.4 projects be handled? > > I think if we can make it a little easier by doing a "hard cut" > > (and maintain two ArgoUML separated streamlines for a while: > > UML1.4 and UML 2.x). Because I don't know how much it takes to > > create a migration tool. The worst would be to make ArgoUML > > deal with both UML1.4 and UML2 models... > > What do you mean by separate stream? Two branches with regular releases: the 0.28 (UML1.4) based stable trunk with maintainance releases, and the eUML based developer releases. In the eUML branch I'd be willing to radically tear down all bridges to UML 1.4 (maybe an project upgrade to UML2 feature only) and break everything in a first step, then build up feature by feature again, but I know that this is probably not what others think. > I think the best would be to make ArgoUML deal with both UML1.4 and > UML2 but I don't know for how long this will be practically possible. Uhm... :-) Maybe that's the better approach. I only thought: the more it hurts, the more effort is taken to make it work again (quick but painful). :D > I don't see why we can't have a release that can still do all of > UML1.4 and can also do just class diagrams in UML2 with extra diagrams > being added over time. Yes, probably. I don't know. Bogdans suggestion for a GSoC participant was: "The student should implement the model subsystem's interfaces, but this should be done incrementally. Incrementally means that you will implement what is needed in the model subsystem for a specific functionality." But maybe for us as the team another approach is more appropriate. > How about this - ArgoUML moves to release 1.0 then every subsequent > release is 1.x until we have the final UML2 diagram and go to release > 2.0 The 1.0 release for me would be your 2.0 release. So I'd move to 0.30 first. (For others 1.0 might stand for full RCP support and eclipse integration.) Thomas -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1498928 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
