Got it working on my machine :) Checked into cvs, uploaded the jar dep to gump.covalent and the next run should pick it up..
Mvgr, Martin On Tue, 2003-01-28 at 18:01, Morgan Delagrange wrote: > Hey all, > > Below is a discussion from the Commons list. > Commons-graph is the sole project with a dependency on > nsuml. It appears that the HEAD version of nsuml is > an incomplete refactoring of the project that does not > compile with commons-graph. It also appears that > nsUML development is dying or dead. > > Since version 1_4 of graph is poor and development is > frozen, it would seem that the best course of action > would be to stop building HEAD and use the 0.4.20 > release JAR instead. I wouldn't suggest departing > from continuous integration unless a project was > really and truly dead, but I believe that is the case > here. > > Comments? If this seems like the right thing to do, > what's the best way to do it? A project definition > that grabs a JAR from somewhere on the internet? > Placing the JAR inside the commons-graph repo? > > - Morgan > > --- Morgan Delagrange <[EMAIL PROTECTED]> wrote: > > --- [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 > > > > > ===== > 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]> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
