Hi, I appreciate your efforts but there isn't much of a point using maven unless freenet-ext is built with it too. That is the bulk of the work. As you said, simply making a pom.xml for only fred is trivial if you know maven.
Do you have an example output of sonar to show us? Some of us are lazy and can't be bothered installing extra software avd figuring out how to run it, whereas I guess you already have such output and can upload it quite easily. Also, for the "download everything it needs", how secure is this? Do you have official documentation that says everything is signed / checksummed? X On 17/04/11 23:06, freenet.10.technomation at recursor.net wrote: > Hey Y'all, > > I have fred-staging building with Maven for your review. I've pushed it to: > > https://github.com/SebastianWeetabix/fred-maven > > > > To build you need Maven (http://maven.apache.org/), and for the real value > add, Sonar (http://www.sonarsource.org/). > > Kick off Sonar and make sure it's ready - http://localhost:9000/ > > If you have Maven 3, build using: > > mvn clean install sonar:sonar > > > If you have Maven 2 use the mvn2-pom.xml: > > mvn -f mvn2-pom.xml clean install sonar:sonar > > > First time, Maven will download everything it needs, which may take a while, > and then compile and analyze *fred*. Once it is done, you will have a > freenet snapshot .jar in _target_, and a detail analysis of the codebase at > http://localhost:9000/ > > > > Caveats - there are a handful of minor issues. > * As I'm not building *contrib*, I've had to drop a copy of > _freenet-ext.jar* in _lib_ for the time being. Ultimately, it would be being > build locally and installed to your local repo. > > * Artifacts from *contrib* left in *fred* - In src the org.* and net.* > package trees are not included in the distributed freenet.jar, but because > they're in the project, Maven keeps then in the built .jar. I'm guessing > that these trees should actually be in contrib(?). They are need to compile > the freenet.* tree. > > * Some tests have been left out: They kick off some process in testing > that does not exit cleanly, and the hanging process locks temp files that > lock the _sonar:sonar_ target. No biggy, this is one of those code quality > things that Sonar should show up :) > > > > Summing up, implementing a Maven build was not very difficult, provides a > straightforward mechanism to build, and to do thorough code analysis that > should help identify redundant and suspect code, and provide focus on > increasing code quality and a clean overall design. > > > > Enjoy! > > > SW > > > > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://freenetproject.org/cgi-bin/mailman/listinfo/devl -- GPG: 4096R/5FBBDBCE
