>> A serial number generator for builds does not easily exist for maven. We had talked about using the svn repo revision number.
SVN repo number would be great. It's a little long because it's Apache's global repos, but it would be more useful than the somewhat meaningless build number we have now. This would be an improvement. The caveat would be that a build would always have to be done against an unmodified working copy with means one of two things: svn status must return no changes before the distro build, or the distro build always has to checkout a clean copy from SVN. >> We tried finding a way to add a date to our deployment zip file. Unfortunately maven did not provide an easy way to access a current date anywhere. No need for the date on the zip file, just the Major.minor.bug-build numbers. >> There have been issues with the coverage tools combining with the unit test tools. If we ran the unit tests, coverage tests, and also generated reports, the tests would wind up running 3 times. Ewww.... I'm sure there must be a way around that. Sounds like something the rest of the world would complain about too. Clinton On Tue, May 6, 2008 at 10:35 PM, Nathan Maves <[EMAIL PROTECTED]> wrote: > Brandon reply below..... > > I am completely for using Maven 2 and conforming our source tree to it. > There were three issues, iirc, that (if they have not been fixed by the > maven crew) will require a bit of compromise or plugin writing. > > #1 A serial number generator for builds does not easily exist for maven. > We had talked about using the svn repo revision number. > #2 We tried finding a way to add a date to our deployment zip file. > Unfortunately maven did not provide an easy way to access a current date > anywhere. > #3 There have been issues with the coverage tools combining with the unit > test tools. If we ran the unit tests, coverage tests, and also generated > reports, the tests would wind up running 3 times. > > That being said, I think we should tackle these issues and make Maven our > build tool. Maven has excellent IDE integration now (IDEA and Netbeans are > both good). It makes it a snap to setup projects and get running. > Additionally, the Apache nerds have some maven processes that can help us to > more easily release software in accordance with Apache requirements. > > Brandon > > On Tue, May 6, 2008 at 10:34 PM, Nathan Maves <[EMAIL PROTECTED]> > wrote: > > > The ideas/requests/demands just keep coming... > > > > With a clean slate for IB3 I want to propose a few things. I have been > > using Maven2 for a while now and even use it in my day to day development. > > My first suggestion is to lay out the new source tree to map to the maven2 > > style of convention over configuration. Even if we choose not to use Maven > > as the build/deployment process it is the most logical and thought out > > hierarchy that I have seen. > > > > On the topic of Maven2 I would like to nominate is as the > > build/deployment process. Maven2 offers so many pre-built plugins for many > > useful things from coverage reports to unit test results. If there is > > something that Maven2 does not have I am sure we could write a quick plugin > > to get it done. I have also been using a new CI tool with Maven2 ( > > https://hudson.dev.java.net/ ). Insanely easy to install and > > configure. Just reads your pom file from maven and away you go. Like most > > it can poll the svn repo for changes and make snapshots as we commit. > > > > Let me know what you guys think > > > > Nathan > > >
