As previously stated, the error was an "OutOfMemory" error that was resolved as suggested in the build directions, by setting MAVEN_OPTS. I don't blame maven for the error (well, if it needs it often, perhaps it should be the default), but I do blame maven for not handling it correctly. Unless it was an optional bit, in which case I should be told that an optional bit failed, but it's continuing anyways. But you led me to believe that it continued not by design, but by error.
Not handling build failures is a serious problem. Full stop. Not providing summaries of warnings and errors is just annoying. CVS is a wonderful system for handling version control. In addition to that primary function, it ensures that you have the correct files, keeps logs on activity, and provides access control. I fail to see what the problem with using it, even for storing JARs. HTTP is brittle (as seen previously) and almost wholly unsuited to this task. Now, if you're talking about the dangers of storing multiple copies of dependencies, or other such mix-ups, that's a different issue. One which is unrelated to the use of a CVS repository. Would you be happier if I refreshed my HTTP server from CVS? I'm still not sure what the ASCII portraits (banners?) mean. Is it bigger and therefore more important? Makes it difficult to search a log when T H I N G S A R E W R I T T E N L I K E T H I S. You have my need exactly right with your commons-logging example. Not only is dependency control beyond the scope of maven, maven actively circumvents it. In my opinion, dependency control is a requirement of a complete build solution. As to building from CVS not being a requirement for most, agreed. However, I see no reason why a project devoted to building software should not have a good, informitive, correct, and trouble-free build. If the authors of the tool can't do it, who the heck can? -----Original Message----- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 11:13 PM To: 'Maven Users List' Subject: RE: Building Maven > You have been extremely helpful, which has been the most > promising thing so far. Thank you. On the other hand, it > does seem like maven still needs a heck of a lot of work. Clear information plus thanks should always result in good help :) Remember you are trying to do something (building from CVS) that is not really a "must have" for end users, and that the problems you've had so far are a corrupted download and a possible JVM misconfiguration (below), not stuff Maven can easily work around on its own! Maven needs a heck of a lot of work only to get a heck of a lot better - it works pretty well as it is and has done so for some time IMHO. Still, I'll admit it does have a few warts. > It also seems like maven has a very singular way of working > that doesn't really suit the way I want to work. Is there > interest in broadening the way maven can work (say, > satisfying dependencies with CVS), or should efforts to that > end be devoted to a different project? This would be against the stated goals: http://maven.apache.org/goals.html Maven makes best practices easy, and bad habits decisively harder by design! :) When you say "satisfy dependencies by CVS", do you mean rebuilding dependencies from a clean checkout, kind of like gump? That's probably a feature maven will have in the future. If you mean checking JARs into CVS instead - shame on you for suggesting it ;) > Re: task appearance > Odd, that. Does the annoying ASCII art supercede task labels? There's an awful lot of task labels. I don't think telling me you are up to [exec] would help as much as "I just got that big building plugins banner". > > Re: dependencies > This behavior also suggests that it would be impossible to > "lock down" a potential set of dependencies that a project > can use. Even if you create your own repository and ensure > all projects use only it, compiling any other maven project > would allow compilation of projects that shouldn't be able to > fufill their dependencies. I suppose I could force projects > to set a different local repository, but that seems slippery. I'm not sure what you mean here. You want to ban projects from using commons-logging, for example, so not make it available? That's a bit beyond the scope of a build tool. > <snip> > [exec] +---------------------------------------- > [exec] | Building Maven VDoclet Plug-in > [exec] | Memory: 156M/158M > [exec] +---------------------------------------- > <snip> > [exec] java:compile: > [exec] [echo] Compiling to > C:\blah\jbuild\maven\src\plugins-build\vdoclet/target/classes > [exec] [javac] Compiling 1 source file to > C:\blah\jbuild\maven\src\plugins-build\vdoclet\target\classes > > [exec] BUILD FAILED > [exec] com.werken.werkz.UnattainableGoalException: > Unable to obtain goal [plugin] -- file:/C:/Documents and > Settings/hornc/.maven/plugins/java/:55:48: <ant:javac> Error > starting modern compiler <snip very long error description> > [exec] Unable to obtain goal [plugin] -- > file:/C:/Documents and > Settings/hornc/.maven/plugins/java/:55:48: <ant:javac> Error > starting modern compiler This seems a bit like a local configuration problem. Do you have JAVA_HOME set? What type/version of JVM is it pointing too? It should fail outright here, but the fact that it doesn't isn't the end of the world. You are just missing Vdoclet and a few other plugins, which you can build individually with maven plugin:install Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
