October 23, 2007
Blog has been moved
This post has been moved to blogspot. No further posts will be made to this location.
Maven: embrace or feel its wrath
One thing that keeps on coming up on the maven mailing list is the question "I don't want to change my project to fit maven, I want to configure maven to fit my project (like with Ant)". I can't blame people since I've been guilty of this as well in the past, but it comes down to the person not understanding the point. The whole point is to standardize on a common structure for building java apps, standard lifecycle, standard way. If you try to get the benefits of using a standard, without actually using a standard, it won't work out well.
Don't get me wrong: I love maven. It's great to use on new projects. It's great to use on existing projects iff you can make the leap of faith that the pain of retrofitting your app will be worth it. If you're just trying it out, you won't already have that faith. I understand that is a problem.
It reminds me of those energy graphs of exothermic reactions where there is an initial "hump" of energy to put in, but after that your net reaction is more energy is removed. That's my mental image of maven: if you can get over the initial hump, then it's so much easier to manage your dependencies. You just have to have that faith.
Posted by jim at October 23, 2007 09:38 AM
Rails is pretty much the same!
That's the problem with using generic frameworks. Sometimes they don't fit your project, and then it becomes very difficult to do something that would normally be very easy to do without a framework. To create a simple analogy, let's say we are building a house. We can either design the house from scratch, or pick an existing model of house, and just build that. If we pick a pre-existing framework, then we don't have much room in terms of changing how the house looks. Any deviation from the plan could result in the house falling down, because it isn't structurally sound. So if you wanted to make the house a foot longer on one side in order to make the master bedroom (and all rooms along that side of the house) one foot longer, you could probably do that, without the house crashing down. Now, if you wanted to extend the house by 6 feet, you might not be able to do this so easily, without having to rethink where support beams go, and what kind of support beams you are using.
So, building on a framework, can help you get a project done quicker if you stick to the way the framework does things. However, once you need to start altering the framework, things can get tricky.
On the other hand, if you don't use a framework, or build your own framework that fits the needs of your project, then you will probably run into fewer situation when you feel like you are doing something in a more difficult way, just because it's the only way to do it within the framework.
If you're looking for an analogy, I think that a better one would be something like:
It's like ikea furniture: it's a lot cheaper and faster then cutting down the trees, milling the wood, and then custom making it. It should Just Work for 99.999% of peoples needs and they are much less likely to screw things up and hurt themselves. All they have to do is figure out how to use that little wrench thingy. The bonus is that once you've put together one piece of ikea furniture, you'll understand it and be able to help assemble your neighbours furniture. For the rare case where you're needs don't line up with ikea, you might have to compromise a little bit.
It also follows that since it's modular, if you find that the ikea furniture is lacking a specific component, you can create one and since it all connects in a common way, other people can use this as well.
Programming is like a box of chocolates...
The point about working for 99.999% of people kind of depends on the framework involved. Most of the frameworks I've seen don't work for 99.999% of projects. And the projects that they do work on, almost always run into some part of the project where the framework just doesn't fit.
As far as Ikea furniture goes, well, most of it doesn't hold together all that well, and you don't get all the variety you want. You can't get victorian decor from Ikea. It looks nice if your whole house is done in Ikea furniture, but once you start buying furniture from other places, you'll see that a lot of the Ikea stuff looks really out of place.
Well... analogies always seem to simplify things to much, so I'm going to throw down my $0.02 with some observations.
1 - I seem to only work on "standard" projects (Java/JEE, oracle, Struts or Spring, etc...). All of these would be more difficult without the frameworks I've used (including Maven).
2 - The people I know who seem very anti-Spring and anti-Maven also seem to be anti-reading, because there are great books on this stuff. Ok, nobody wants to re-invent the wheel, but I'd sure rather have the low-profile 17" tires with aluminum rims rather than a partially broken wagon wheel (D'oh! I used an analogy!).
3 - After using some good frameworks, I'd find it extremely painful to try to "roll my own" framework... also more error prone.
4 - Although there were some definite growing pains with Maven, builds have never been easier. Once you're setup, it's really easy to maintain, and mvnrepository.com becomes your best friend :)
Due to the proliferation of comment spam, Iíve had to close comments on this entry. If you would like to leave comment, please use one of my recent entries. Thank you and sorry for any inconvience caused.