Hello all! Looking at this from the ArgoUML subsystem perspective, I wish that the level 2) and 3) integrations would be something for the GUI subsystem only. We are currently far from there.
Perhaps we should attempt to do what we have done for the Model subsystem. I.e. work more with the GUI façade/interface to the point where it is possible to unplug our own and plug in something else. To some extent the interface could perhaps be specified by the panelbeater project. Then the panelbeater project would connect into Eclipse on level 2) and/or 3) and we don't have to bother. The panelbeater project (http://panelbeater.tigris.org/) doesn't seem very active so that is probably not the path forward anyway. Alas, whatever path we choose it is a lot of work to get there. On the question you are asking Tom, I am undecided. The whole world is competing to be as Eclipse-compliant as possible. Four years ago it was Netbeans. What will it be in another four years? Where do we want to be then? Flying with Eclipse or struggling with our own. Bob wanted the argouml-emf project that would be a Model implementation that uses emf instead of MDR. I created that project but then I made it private not to confuse the picture. That is another level of integration. I haven't understood how it would work, i.e. if it would require level 2 or level 3 in your description or if it is possible to run stand-alone like MDR. /Linus > -----Original Message----- > From: Tom Morris [mailto:[EMAIL PROTECTED] > Sent: den 19 maj 2006 08:54 > To: [email protected] > Subject: [argouml-dev] Eclipse integration levels for ArgoUML > > I've been doing some background investigation into how we might integrate > with Eclipse and want to outline some possible approaches and solicit > feedback from others. We've got several project proposals related to this > as part of the Google Summer of Code, so work could start relatively > quickly > if one of them is accepted. Even if none of those applications are > accepted, I'll probably start doing some more substantial work over the > summer. > > There are a several levels of integration that we could pursue: > > 1. Basic integration - No graphical integration. ArgoUML and Eclipse run > in > their own main windows. Simple communication and control possible to do > things like tell ArgoUML to open a new project from Eclipse (e.g. in > response to a double click) or have ArgoUML tell Eclipse to refresh a > project or run a build action when a project is saved by ArgoUML or it > does > code generation. This was the level that MagicDraw provided up until it's > recent version 11 release. You can see descriptions of the previous and > current levels of integration in these two manuals > http://www.magicdraw.com/files/manuals/10.5/MagicDraw%20Integrations%20Use > rG > uide.pdf > http://www.magicdraw.com/files/manuals/11.0/MagicDraw%20Integrations%20Use > rG > uide.pdf > > 2. Basic GUI integration - ArgoUML main diagram window and property panel > displayed unchanged (as Swing objects) within Eclipse SWT panes. Perhaps > rework of explorer pane functionality to fit with Eclipse view. Perhaps a > critics pane. Use of Eclipse menu bar for all menu functions. Swing/SWT > hybrids in Eclipse don't work on Apple Macs today, but they are supposed > to > be fixing that. The visual style of the Swing and SWT panes will be > noticeably different, but it allows a large amount of existing code to be > reused. The is basically the approach that Genuitec took when they forked > the ArgoUML base for their Eclipse plug-in. > > 3. Eclipse/RCP framework for ArgoUML infrastructure - At this level we > would > get out of the infrastructure business and focus on doing the components > where we add real value and use existing Eclipse plugging for everything > else. We would integrate with the Eclipse command and undo facilities. > Existing ArgoUML plugging would migrate to using the Eclipse plug-in > mechanisms. The standalone ArgoUML application would become an RCP > application. Naturally this would probably make integration with other > environments such as NetBeans more difficult and would couple our fortunes > to those of Eclipse. > > Of course any of these levels could be implemented in a phased fashion and > we could move from one to the other over time. Also, somewhat orthogonal > but related to this is that we could use Eclipse components for specific > tasks such as using their UML 2.1 support even in our current standalone > configuration. > > I've got my own ideas of what we should do, but I'm interested in hearing > what others think (including any on the list who submitted one of the > Google > Summer of Code applications in this area). > > Tom > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
