On Wed, Jan 19, 2011 at 12:49 PM, Mark Fortner <[email protected]> wrote:
> Is there a way that a single module could be used both as an ArgoEclipse > plugin, and an ArgoUML module? Yes. That's what this was intended to convey - "code generation or reverse engineering [plugins] have Eclipse extension points defined and the existing plugins work in both modes" That means the Java, C++, Python, etc modules all work in ArgoEclipse (and have for 3+ years since Bogdan did the implementation as part of his Google Summer of Code project). If you had, say, a diagram layout plugin, we'd need to define a diagram layout extension point (ie API), add support for the extension point to ArgoEclipse, implement the extension point in your plugin (turning it into an Eclipse extension as well as ArgoUML module). This work is straightforward and almost trivial for a simple API like the code generation API. Tom > > On Tue, Jan 18, 2011 at 11:09 PM, Tom Morris <[email protected]> wrote: >> >> 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://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2699033 >> >> 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]] > > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2699127 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]]
