I wasn't implying that Maven COULDN'T do anything.... I was just laying out what I would want to see from a maven build.
>> So, if you are saying we can't have an assembly config then gimme a break. What I mean is that if I can't check it out and build without having to perform some developer level/local config then forget it. >> I don't think this is necessary. We can look into adding the build number to the META-INF. But, this should be possible. Versions are important. The more clear we can be with our version number the better. I'd like it in the filename, because it helps people, including us. One of the reasons Java sucks these days is the lack of good version control of JAR files. The best we can do is put the version number in the name of the JAR file to help people know which version they're using. It also helps us on support lists... recall the days when people couldn't tell which version they were using because they copied it from somewhere else. META-INF is a good second best... but I hear this Maven thing is supposed to be good, so I'd expect it to be able to fill this simple requirement. I'm already not impressed with the excuses. I laid out what I think are fairly simple requirements that any build system should support. >> Getting up and going in my IDE I honestly don't want to mix the needs of the development tool with the build tool. The build is a separate entity. Furthermore, let's not mix the problems of other projects (which may very well be solved by Maven). iBATIS does not have the problem you describe. It's a well structured and organized directory. /devlib /lib /src /test...... there's no magic to it. I understand what you're saying, but iBATIS simply doesn't have the problem. >> I think you need to take your blood pressure medicine. Let's not get too immature about it. I'm being open minded and fair. I asked for very simple things that are achieved with a 260 line Ant file with 14 well described tasks. I've yet to see: 1) A major problem or flaw pointed out with the iBATIS Ant build. I don't care about the general case of Maven vs. Ant and Project X -- what's wrong with the *iBATIS* build? 2) A major advantage to using Maven for iBATIS (other than the potentially easier one-time setup of the IDE -- neat, but one-time IDE config vs. daily build maintenance...) 3) Confirmation that Maven can meet some very simple requirements I laid out. Instead I hear excuses and borderline personal attacks (which I know Brandon doesn't really mean, but it's still a shitty way to debate). Come on guys. You're doing a piss poor job of making your case for Maven with that approach. Don't argue. Look at what the current build does. Do it with Maven cleanly, and while meeting all of those simple requirements -- and you've won your case. Clinton On Wed, May 7, 2008 at 8:21 AM, Brandon Goodin <[EMAIL PROTECTED]> wrote: > Thanks for sharing your passions. My thoughts are below... > > #1... > > A. one "click" has never been a problem for maven. There seems to be a lot > of insinuation that maven requires a lot of config files. I'm not sure where > you are getting this. The only thing that we might need to do is break out > the assembly config. But, that is because it is about packaging artifacts > all together and not about building the individual jars. So, if you are > saying we can't have an assembly config then gimme a break. Your request is > denied because it requires something that is not possible and is not > possible for a rational and organized reason. > > B. offline build... never been an issue for maven. So long as you have the > needed jars locally. But this is true of any codebase. > > C. Are you referring to the final zipe file structure or the source tree. > If you are referring to the source tree. You will be denied on that one as > well because maven doesn't have dependencies in the local source tree. If > you are talking about the final packaged output... we already demonstrated > that with the current ibatis maven build. > > D. HTML Test Reports - Been possible for a long time > > E. Coverage Reports - Been possible for a long time > > F. Exploded Distributions - Not sure of what you are referring to here. If > you are referring to seeing the final product of the zip file before it is > zipped then that is just a matter of copying all the sources to a folder in > the assembly config. We demonstrated that with the current maven build in > ibatis. > > G. Zipped Distro - No problem > > H. I don't think this is necessary. We can look into adding the build > number to the META-INF. But, this should be possible. > > #2 - Getting up and going in my IDE is a snap because of current IDE > integration. Less than a minute. With Ant. I always have to checkout the > project figure out what the heck people are doing in their ant script > because EVERYONE does something different. Ramp up time sucks. I always > enjoy how people will blend build artifacts with static artifacts. Can't > simply delete the output folder. You always have to make sure you use their > custom wacky ant scripts and hope you don't call the wrong task. > > #3 - See #2 > > > "I'm for simplicity over all else. No Ant isn't the best example of a > build tool in history. But it's simple and it works." I am too. That is why > i use maven :D I got tired of trying to figure out everyone's wacky Ant > scripts. > > I think you need to take your blood pressure medicine. ;-) Maven is an > acceptable build system. Instead of coming out with aggressive posturing, > give your fellow developers the benefit of the doubt. Do you think we would > use it if we thought it was a horrid pile of crap? Everything comes with > it's strengths and weaknesses. I'll take the lack of a build number on the > zip and jar any day over the amount of effort i expel trying to figure out > ant scripts. > > Brandon > > > On Wed, May 7, 2008 at 8:36 AM, Clinton Begin <[EMAIL PROTECTED]> > wrote: > > > I currently hate Maven with a grand passion. But, I'm open minded and > > am willing to be educated as to why people like it. I will make the same > > offer I made before: > > > > Three requirements: > > > > #1 Create a maven build system for iBATIS that achieves the exact same > > output, which includes: > > - one "click" build -- I'm not exaggerating here, SVN checkout, run > > ant or script...done. NOTHING else.. no config files, no nothing. > > - offline build -- no network connection required (perhaps after one > build if it needs to grab dependencies initially) > > > - echo arbitrary information to the command line, such as classpath > > in use and current version being built > > - all dependencies must be versioned and organized into developer > > dependencies (/devlib) and runtime/deploy dependencies (/lib) > > - HTML test reports > > - HTML coverage reports > > - exploded distribution > > - zipped distr > > - version number stamped on ibatis JAR file(s) as well as the zip > > distro > > - all achieved by Ant today. > > > > #2 Show that it's simpler than Ant in at least one way. For example: > > - less XML configuration > > - fewer requirements > > - smaller overall source base size > > - more/better compatibility with tools/frameworks/IDEs > > - the current Ant build is 258 lines and integrates and runs from > > any IDE > > > > #3 Show that it does something Ant doesn't. For example: > > - Signs, MD5, and Uploads to Apache dist (with no additional > > dependencies or configuration) > > - .... > > > > I don't think these are unreasonable requirements. In fact if even one > > is missed, it would make me wonder why the hell we'd even bother. > > > > I'm for simplicity over all else. No Ant isn't the best example of a > > build tool in history. But it's simple and it works. > > > > 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 > > > > > > > > > > > >
