commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morgan Delagrange <>
Subject Re: [Graph] nsuml changes?
Date Tue, 28 Jan 2003 08:33:50 GMT
--- wrote:
> Morgan Delagrange <> 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":
> > 
> >
> > 
> > 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" <>
To: <>
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
> with a little hope of unfreezing due lack of demand
> by money and lack of active projects at novosoft
that use
> that set of technologies right now. Yearlier it had
> developed because it had been used by novosoft, but
> novosoft's projects reached state where only little
> is needed. Following it, I had been no more able to
> 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
>  From alternatives available at last time I checked
> the best choice is MDR from netbeans. If NSMDF
> will be unfrozen (there still is a little hope for
> some API compatibility with MDR particulary on event
> will be one of goals.
> JMI RI from Unisys could be also worthy candidate
> 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'

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

Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message