Hi Tom,
As with most open source projects, developers priorities tend towards
scratching their own itches first. I agree though that keeping up with the
latest UML spec is probably the highest priority.

Is there a way that a single module could be used both as an ArgoEclipse
plugin, and an ArgoUML module?

Cheers,

Mark




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=2699116

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]]

Reply via email to