> 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
