Update: I'm doing some work to split this blog post into some more fine grained posts in a series. Please, bear with me if these changes are giving you lots of noise in your feed-reader.
I used to work as a consultant. My job was to improve our clients' ways of software development. Among the most important things I tried to teach them were:
o Good code style and object orientation
o Practical use of good open source tools (don't re-invent the wheel)
o Automating tests of their software, and continuous integration
o Splitting code into modules, dependency-relationships and versions
The last point is perhaps the trickiest. It's hard to understand why it's needed in an isolated project, it is hard to explain how it should be done, and most importantly, there is no de-facto way or standard for managing modules, their relationships, versions and scope.
This is why me and my consultant buddies embraced Maven many years ago. After years of pushing and evangelizing at our clients', presentations at javaBin and JavaZone, Maven has at least become the way for managing and building Norwegian Java projects. There are still old Ant projects around, but I haven't heard of any new ones being started without Maven, or any old projects where a Ant/Maven migration path hasn't been thought of.
Here at IP Labs we still have an Ant build for our main project, and it works. (We have also started using Maven for a bunch of ad-hoc projects). There is a small, co-located and tightly communicating Java team that all use Eclipse with identical setup. In order to build our product, you check it out of Subversion and run "ant build-all", and that runs pretty similar to your average "mvn install": compiling, running tests and building binaries.
So here's the million dollar question: When our build system works perfectly fine, why should we go to the trouble of converting to Maven?
And instead of answering with some fluffy modular design theory, let me get hands-on, and give some real practical reasons in these following blog-posts:
I used to work as a consultant. My job was to improve our clients' ways of software development. Among the most important things I tried to teach them were:
o Good code style and object orientation
o Practical use of good open source tools (don't re-invent the wheel)
o Automating tests of their software, and continuous integration
o Splitting code into modules, dependency-relationships and versions
The last point is perhaps the trickiest. It's hard to understand why it's needed in an isolated project, it is hard to explain how it should be done, and most importantly, there is no de-facto way or standard for managing modules, their relationships, versions and scope.
This is why me and my consultant buddies embraced Maven many years ago. After years of pushing and evangelizing at our clients', presentations at javaBin and JavaZone, Maven has at least become the way for managing and building Norwegian Java projects. There are still old Ant projects around, but I haven't heard of any new ones being started without Maven, or any old projects where a Ant/Maven migration path hasn't been thought of.
Here at IP Labs we still have an Ant build for our main project, and it works. (We have also started using Maven for a bunch of ad-hoc projects). There is a small, co-located and tightly communicating Java team that all use Eclipse with identical setup. In order to build our product, you check it out of Subversion and run "ant build-all", and that runs pretty similar to your average "mvn install": compiling, running tests and building binaries.
So here's the million dollar question: When our build system works perfectly fine, why should we go to the trouble of converting to Maven?
And instead of answering with some fluffy modular design theory, let me get hands-on, and give some real practical reasons in these following blog-posts:
- Reason 1: Get your libs-folder out of SVN
- Reason 2: Clean up your JAR-files
- Reason 3: Don't build everything all the time
Totally agreed with that; same thoughts here: http://cristivulpe.blogspot.com/2009/07/why-should-we-use-maven.html.
ReplyDeleteI even started to use maven for any small project where I need a single 3rd party. Used with a reasonable repository manager like archiva boots the speed of builds if larger teams use it.