Adrian wrote: "Maven rocks, it gets the job done, it is vastly easier than any alternative, and is comparatively a pure joy."
I guess I was looking for something a little more conrete and specific. "Maven rocks" is an more like a feeling, and I definitely don't feel that Maven rocks. Adrian wrote: "Learning maven is hard because what it is doing is immensely complex not because maven is hard as far a build tools go." I agree that Maven is designed to do complex things. I'm questioning whether GeoTools needs to be complex enough to need this tool. Adrian wrote: " If you want hard, play for ten minutes building any complex C program from source. Autoconf and Automake are very powerful too but it takes a programming god to master them. And after your ten minutes have become two weeks, come back and enjoy maven." That's why I write most of my code in Java and not C/C++. :] Adrian wrote: "The benefits of maven are too many to list." I think this conversation would be more productive if I could actually see a list. From my perspective Maven is a real pain-in-the-rear, and the benefits limited. I think I can put together rough draft of a list based on your message: Maven Benefits: (1) Programmers only have to learn a single build tool. (2) We can run Maven with an external build tool like Hudson. (3) Using Maven allows us to get libraries off the standard repositories. I'd like to play Devil's Advocate for a minute and tackle each one of the benefits listed above: (1) The "programmers will only need to learn one build tool" argument could be made for some other widely accepted build tools as well. You could also argue that a build tool isn't even necessary to compile Java code into a usable form. (2) I don't know much about Hudson, but you can certainly run a tool like Ant externally with something as simple as a batch script. Is Hudson yet another tool we are introducing into the process? (3) I would argue that the best person to maintain the libraries needed for an individual module is the module maintainer, not a build script/tool. I realize that I am likely fighting an uphill battle here. It is very hard to undo something that has been done for so long. Yet I feel at times that the Geotools community lives in a sort of bubble, oblivious to the efforts of others trying to peirce the bubble skin. It is important to remember that every road block raised to contribution keeps more contributors away. At the end of the day, contributors are the life blood of any open source project. Geotools should be looking for ways to make contribution easier, not ways to make it more difficult. There is a delicate balance that must be struck between standards enforcement across a project and appeal to new contributors. If Maven is so critical, and can't be removed from GeoTools management, then I think there should be more support for accepting contributions of code from non maven users. I'd like to see a system where a contributor could do something as simple as submits a zip file a list of dependencies. I maybe be misunderstanding the very nature of the beast that is Geotools. If it is intended to be an all-encompassing umbrella that produces a monolithic JAR, then Maven may be a good tool. If Geotools is supposed to be (in contrast) a collection of independent modules that share common code whenever possible, then I think Maven is a poor choice. If we aren't building a monolithic JAR, then let the individual module maintainers have control over their own build process. I think you could even remove the build process from the equation entirely. Let GeoTools be a repository of source code and executable code, and leave everything in between up to the individual developers. Maybe it would be best to start a discussion on the nature of Geotools as a library. I think my beef with Maven is just a symptom of this larger question. Then again, maybe the nature of Geotools has already been decided, and I'm way late to the conversation. Landon P.S. - I must add there are some things I really like about Maven, like a standard folder structure for repositories. I've already started using a similar structure for my own code. P.S.S. - I wonder if a "looser" system or a system in which module maintainers have more independence over the build process would have prevented a fork like GeoTidy? On Wed, Feb 4, 2009 at 11:23 AM, Adrian Custer <acus...@gmail.com> wrote: > Hey, > > Maven rocks, it gets the job done, it is vastly easier than any > alternative, and is comparatively a pure joy. There is quite simply zero > chance that the use of maven would be changed. > > Learning maven is hard because what it is doing is immensely complex not > because maven is hard as far a build tools go. If you want hard, play > for ten minutes building any complex C program from source. Autoconf and > Automake are very powerful too but it takes a programming god to master > them. And after your ten minutes have become two weeks, come back and > enjoy maven. > > The benefits of maven are too many to list. Having a single build tool > for the whole project makes developers need only learn a single one. > Using maven allows external tools like hudson to run the build. Using > maven allows us to get libraries off the standard repositories. Using > maven... > > cheers, > -adrian > > ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
