Hi , I would also suggest a command line flavour for ArgoUml that can help in a long way to build multiple flavours Argouml(i.e argouml extended to various IDE/platforms).
In short the CLI version of arguml will enable the generation of code from a zargo without loading the UI of Argouml,to do the operation of merging uml models in seperate zargo files(i.e when the logic is developed ) in a daily build etc.. Regards Vinod --- On Wed, 9/24/08, Bogdan Ciprian Pistol <[EMAIL PROTECTED]> wrote: > From: Bogdan Ciprian Pistol <[EMAIL PROTECTED]> > Subject: Re: How can ArgoUML be modified for argoeclipse > To: [email protected] > Date: Wednesday, September 24, 2008, 11:40 AM > I think that the most productive tools for the user would be > generating source code and reverse engineering to/from > Eclipse > projects. One cool feature would be able to quickly > synchronize the > UML model with the source code from the an Eclipse project. > > > Bogdan > > On Tue, Sep 23, 2008 at 1:26 AM, Tom Morris > <[EMAIL PROTECTED]> wrote: > > > >>> 1. The details pane appears as a set of tabs > in one tab. > >> > >> > >> I spent some time looking into this during GSoC > but as you pointed out the > >> DetailsPane contains a lot of logic which made > seperating each of these out > >> into their own Eclipse views a little difficult. > >> > >>> I think DetailsPane has too much > responsibility in ArgoUML. Personally > >>> I think the panels added to DetailsPane should > be responsible for > >>> listening to TargetManager and handling their > own enablement etc > >>> rather than DetailsPane sharing some > responsibility for this. > >>> > >>> If we can move some of the logic out of > DetailsPane could the panels > >>> be added as individual panes in argoeclipse. > >> > >> > >> Yes this would be easy. > > > > This would make things fit much more naturally into > the Eclipse scheme since > > each tab would be a separate view and could be managed > independently. > > Keeping them all docked together at the bottom of the > screen would emulate > > the current behavior, but you could also choose to > arrange them any other > > way you wanted. > > > >> 2. There is only one diagram tab. > >> > >> > >>> > >>> Would this result in the same problem as the > details pane with > >>> argoeclipse only having one diagram tab with > multiple tabs within > >>> that. > >> > >> I depends on how this change is implemented. > >> > >>> If I resolve issue 610 can argoeclipse show > separate diagram tabs at > >>> the same level as other open files in the > project? > >> > >> Do you mean having an editor for each diagram? I > suppose with some changes > >> to ArgoEclipse's editor this would be > possible. We'd have to create an > >> IEditorInput which worked with Diagrams instead of > Projects like they do > >> now. > >> > >> I think something similar to the MultiPartEditor > used in Eclipse PDE's > >> Manifest editor might be more appropriate > >> > (http://www.eclipse.org/articles/Article-Eclipse-and-Maven2/images/pde-update-classpath.png). > > > > I think an (Eclipse) editor per diagram is a more > logical mapping than using > > a MultiPartEditor. MultiPartEditors are usually used > when there a fixed > > number of separate pages, not an arbitrary number of > views. > > > > There's an additional issue lurking just under the > surface here in that > > ArgoUML only allows a single project to be open at a > time, so if you attempt > > to open a second project, you get a very > un-Eclipse-like error telling you > > to close your first project before opening a second. > > > > A related thing that we need to think about is how > ArgoUML projects and > > Eclipse projects relate. For the RCP version of > ArgoEclipse, we could get > > away with using the current file system based view > with the user managing > > the directories for code generation and reverse > engineering, but in an > > Eclipse IDE environment where Argo is just one of many > plugins, developers > > are probably going to want tighter integration between > their UML model and > > their Java/C++/whatever code. In this case, we > probably just want an Argo > > "nature" that can be added to a project > along with the Java nature or > > whatever other natures it has. I haven't thought > through how this would all > > work though. > > > > 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]
