--- [EMAIL PROTECTED] wrote:
> Morgan Delagrange <[EMAIL PROTECTED]> wrote on
> 28/01/2003 10:11:09 AM:
> 
> > Hey all,
> > 
> > I was investigating the GUMP failure for graph. 
> It
> > looks like GUMP is using the "nsuml1_4" CVS
> module,
> > while Maven builds off of version 0.4.20.  There
> are
> > some differences in package names, etc.  I checked
> the
> > nsuml home page and they say 0.4.20 is "obselete":
> > 
> >   http://nsuml.sourceforge.net
> > 
> > Should graph be using the nsuml1_4 version?  I
> checked
> > it out, and it's not just repackaging; some of the
> new
> > nsuml classes are not interface-compatible with
> the
> > graph code.
> Well, the graph component works as it should at the
> moment. The gump build 
> fails as it's not using the latest and greatest
> graph code.

Where is the latest and greatest graph code?  Is Maven
not using commons-graph anymore?

> If you are up for reworking graph with the latest
> nsuml, go for it!

I've been looking at it, but the lack of
documentation, examples, etc. for NSUML is very
frustrating.  I think I see why the HEAD version is so
hard to work with.  Read this post from the lead NSUML
developer that I found on the argoUML list:

----- Original Message -----
From: "Constantine Plotnikov" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 30, 2002 10:31 AM
Subject: [argouml-dev] On status of NSUML and NSMDF


> Hi!
>
> NSUML and NSMDF are currently in the very deep
hibernation
> with a little hope of unfreezing due lack of demand
backed
> by money and lack of active projects at novosoft
that use
> that set of technologies right now. Yearlier it had
been
> developed because it had been used by novosoft, but
those
> novosoft's projects reached state where only little
maintainance
> is needed. Following it, I had been no more able to
explain
> to management why project should be developed
further, so
> it became victims of cost cutting.
>
> I'm working on other projects at my private time and
> I had no time to support and develop NSMDF on my
own.
>
>  From alternatives available at last time I checked
possibly
> the best choice is MDR from netbeans. If NSMDF
project
> will be unfrozen (there still is a little hope for
it),
> some API compatibility with MDR particulary on event
API
> will be one of goals.
>
> JMI RI from Unisys could be also worthy candidate
for
> evaluation, but it looked a bit overcomplicated.
>
> Constantine

So it looks like NSUML is effectively a dead branch. 
Typical semi-corporate SourceForge project, works
great until the company gets tired of it.  I've been
reading the list, and it sounds like the version
you're using is actually more feature-rich than the
1_3 version, and the NSUML claim that 0.4.20 is
outdated was just wishful thinking on the devlopers'
part.  

Blech, I don't know what the best approach is.  I
think this may actually be one of those instances
where GUMP should not point to the HEAD version, since
it's both incomplete and frozen.  Any GUMP people
about?  I think the REAL solution is to take
Constantine's advice and eventually use an active API.

If no responses are forthcoming here, I'm going to
forward this to the GUMP list and recommend that they
not build NSUML from HEAD.  We'll see what they have
to say.  I'd really like to get graph building in
GUMP; it's currently the only dependency that
preventing the possibility of Maven nightly builds.  I
would love to have GUMP do the work, rather than have
to bootstrap all the time.

- Morgan

=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to