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