(Note: Not a BSF committer, just a generic Jakarta committer; not a maven committer either, just wanting to try and show why people might think otherwise)
On 9/25/05, Alan Gutierrez <[EMAIL PROTECTED]> wrote: > Once a project goes to Maven, there is an enormous barrier to > entry for those developers, like myself, who are not going to > put up with it. I don't need a PMD report every time I change a > line of code. When I check a project out and see it uses Ant, I wave my hands in despair. Yet another custom piece of hackery to wade through before I understand what is going on. Okay, bombastically said, but it's a serious point, Maven equals standardisation equals easy-to-understand. I'm assuming you were taking poetic licence, but you don't get a PMD report every time you change code. When compiling, all Maven does is force your unit tests to run every time instead of allowing you to compile separately. The speed is definitely a problem, least it is on my antique 400mhz Powerbook. My P4 2.x ghz server flies along, so I'm guessing it's something that gets a lot better with raw power. > I hereby volunteer to check in the dependencies into Subversion, > or write Ant scripts that will put the dependencies via http > from the source of your choosing. www.ibiblio.org/maven :) With ability to add others. And local caching in the .maven/repository directory to speed up the builds. Always surprises me that there's not a dominant Ant.maven project out there which steals the best Maven ideas (standard commands, managed dependencies) without having to embrace the mistake of merging the site with the development reports. Ivy does look like it handles one part of the Maven idea though, so there's hope. > It should take a day to write. If you must go with Maven, please > accept my offer as an alternative. Just as a counterpoint, it would take less than 30 minutes to Mavenise BSF (though not talking about the site). That's probably a bit pessimistic too, you just need to write 3 project.xml files, one at the top level, one in taglib and one in bsf-3. > I simply do not understand why people put up with Maven, why > everyone thinks it is such a great idea. For open-source projects, I think the popular selling point was the magic website that miraculously appeared and promised to be better than the current site. Thus Hani's biling that the Maven cookie cutter site was showing everywhere. That's not why it's good though, just an early piece of successful marketing. The site's look and feel is still not bad, it's saved a lot of time from being wasted on the project sites and brings the lowest level of graphical design up a few notches. The information architecture of the site is bad, I hate the hidden Project Reports and Project Info bits, but with an hours work you can find a minimalism (http://www.osjava.org/simple-jndi/ though I still think I should kill the source cross references). The real first selling point was not having the dependencies in your source control system. There were a number of projects to solve that one in Jakarta, Maven was just the one that stayed active and became prevaylent. This seems to be one of those K&R vs BSD braces issues; people either hate having jars in their CVS, or love it. The good reasons are: 1) Standard. We use Maven at my place of employment to keep the build system very easy to understand. Developer's don't need to know Ant and write their own build scripts, they just copy a template project.xml, fill in the gaps and start building. 2) Simplicity for the IDE users; they run 'maven eclipse' (for example) and are ready to run with all the dependencies setup. 3) Dependencies. Maven effectively gave us a Java CPAN when everyone else was talking about it and failing to deliver. Adding javadoc and src.jars is planned I think (unsure). 4) Very good way to discover new projects. Jalopy, PMD, Checkstyle etc. Least it was early on, stability means that there are less new plugins in the default installs now. > It's turning Java land into binary-only land. Only if you believe Ant is the one true build system. People using make to compile Java probably claimed the same thing of Ant. > This is not a rant. I'm sincerely concerned that Maven will be > a productivity drag and retard participation. It's definitely slower to build than Ant, though I assume the unit tests should, on a well tested project, be an order of magnitude larger in time than the build system and so the speed difference in starting Maven and Ant should be much less noticeable. No argument on retarding participation; the blog entries you quote show that there are definitely people with very strong anti-Maven views. I'd draw an analogy to Java IDEs in the late 90s, most of us despised them. I doubt Maven will be the Eclipse of the build tools, but in 5 years or whatever I'd hope that people aren't still rolling custom build scripts all the time. > * Developer must have Maven installed, cannot simply type "ant". Circular argument though. Developer has to have Ant installed to type ant. Admittedly Ant is more common, but there'll be a good %age of people for whom it's not more common (for example I'd guess I use Ant on about 2% of the code I have checked out, often because the project has been inactive for years, I doubt people at my place of work have it installed). > * Maven has an enormous set of dependencies itself. Yep. > http://www.custommonkey.org/words/jeff/2005/02/23/1109162220000.html No clue what this is on about, Maven is as easy to install as Ant, Tomcat or Java. Download a tar.gz, unpack it on your filesystem, set MAVEN_HOME, add to PATH. Interestingly I feel like I'm in the Ant situation here, I'm guessing that the author was using jpackage or rpm's or something, a concept I never really get because it's so much pain to go through when installing a binary by hand is so easy. Actually, I bet he's trying to install using some kind of build from source system (Gentoo etc). I imagine Ant is more painful then too (the whole bootstrap issue), but have definitely felt the Maven build itself was complicated. I'm guessing that Eclipse has a lot of dependencies, the point seems moot to me. The majority of people don't build their development tools from source. ----- Hopefully I've not been too overly amused with myself above, and have managed to make some points without being rude. Namely: * Custom Ant scripts are more painful than a project.xml * Maven sites still need time on the information architecture; something that the ease of creating them seems to stop happening. * There are positives to using Maven. Really you're not arguing against being able to build BSF with Maven, but as to which system is considered the official build. There's also the build.xml that Maven can generate for Ant users, but I've no clue if that's desirable or not. Logically you would think that it should be much like Ivy. Slightly off-topic, if applying Maven to an Ant project, I would recommend trying to simplify your build system/code structure, don't hack Maven to fit the system you had in place for the Ant project. If you can't be standard-ish, stay in Ant - it's the right place for lots of customery. Sorry I'ved rambled so much, Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
