I don't think anything has changed since this was discussed a year ago. Some ArgoUML developers are opposed to Eclipse, others are opposed to change of any form, and I'm opposed to continually reinventing the wheel when there's not enough manpower to do even the most basic stuff like track UML versions in a timely fashion.
On Tue, Jan 18, 2011 at 12:56 PM, Mark Fortner <[email protected]> wrote: > I think there are a couple of points that Andreas is making: > > He doesn't use Eclipse, so if ArgoEclipse is merely a plugin for an IDE he > doesn't use, then it will probably have limited use for him. ArgoEclipse is available both as standalone RCP version and as an Eclipse plugin. The standalone version does have a stripped down Eclipse framework at its core, but functionally and cosmetically it looks the same as ArgoUML. The first versions of this were made available years ago. If Andreas has actually tried it, he hasn't said so publicly. > The same could > be said of most non-Eclipse users. Although I use Spring Tool Suite (a sort > of kitchen-sink Eclipse distribution), I haven't quite figured out whether > the extra overhead of adding yet another plugin to IDE is worth any > performance degradation. There's a performance 'degradation' when you start an ArgoUML process alongside your Eclipse process. The performance impact of a properly designed Eclipse plugin that isn't being used is limited to reading a small XML file at startup. It should be less than the overhead of an additional process. > There doesn't seem be a roadmap that indicates when (or if) ArgoEclipse will > become the default distribution for ArgoUML. If this is going to happen > this year, then Bob's statement about not "reinventing the wheel" probably > holds. If it's going to be some indefinite time in the future, then it's > probably worth looking at some short-term solution. Especially if there's a > way of generating Eclipse update site XML from it. Without anyone working on it, it'll probably never happen. Of all the Eclipse wheels to reinvent though, I've got to say an app/plugin market seems a strange one to make the top priority. What about context sensitive help or everyone's favorite, Undo? > Under the rubric of "getting our ducks in order", it would also be useful if > there was some discussion about the ArgoEclipse, in particular: I'm not sure who the "our" is in this context, but I'm happy to give you my opinions (inline below). > Eclipse has a yearly release train, how will keeping up with that schedule > effect the work that currently gets done? It has no impact. The ArgoEclipse plugin maintains compatibility with at least a couple of previous versions, so there's never a dependency on the latest and great. Eclipse is very good about maintaining backward compatibility, so old plugins work on new releases. > Will ArgoUML be distributed as a plugin, as a separate Eclipse distro, or > both? Both, although it's not really a "distribution" in the IDE sense that you're probably thinking of. > How will the Eclipse RCP framework change ArgoUML's current module > framework? Presumably, there would need to be some work either to bridge > the two, or refactor all existing plugins to fit the Eclipse RCP API. "All" is a pretty small list, almost entirely focused on code generation or reverse engineering. Those two groups have Eclipse extension points defined and the existing plugins work in both modes (but don't require the heavyweight startup time initialization that ArgoUML style plugins do). > What specific steps do plugin developers need to take in order to turn their > existing plugins into Eclipse plugins? Are there any plans to document this > in the wiki? If it's not already covered in the ArgoEclipse wiki, I'll be happy to add it, as well as assist any developers who need help in doing the conversion or coach them on how to define new extension points for things that aren't covered (one of the things that Eclipse is much more discipline about is dependency management and preventing code from arbitrarily reaching into non-public APIs, so there needs to be an API defined, unlike ArgoUML where anything is fair game). > Are there any plans to post a roadmap for some of the upcoming releases? > This would help set some expectations, and keep everyone focused in the > same general direction. My personal roadmap is to either make a decision to recruit seriously for ArgoEclipse or abandon it. The ArgoUML team is focused on other priorities, so any assistance needs to come from outside. Meanwhile the Papyrus team in France is plugging away on building a full fledged UML tool that will be bundled with the Eclipse. When they finish, that will make the whole idea of ArgoEclipse much less interesting to potential users. > Regardless of the approach we end up using to making modules "discoverable", > the main thing we're all trying to achieve is improved ease of use and > improved ease of development. That's not my impression of what developers' top priorities are, but I could just be out of touch. Tom ------------------------------------------------------ http://argoeclipse.tigris.org/ds/viewMessage.do?dsForumId=5521&dsMessageId=2699034 To unsubscribe from this discussion, e-mail: [[email protected]].
