Well, thought I might just add some thoughts in the debate on Maven that started a couple of days back. Didn't want to add to that blog's long list of comments as it already is a long list and honestly, took me sometime to read all the valuable experiences of others.
I must at least quantify where and what I do: I am a Development Manager. I look at development processes, and toolsuite is part of my constant concern as it impacts how my teams get their work done. There was a kung-fu movie (StormRiders) that has some nice wisdom:
Cloud: Which is better, martial arts or a good sword?
Cloud's father: A good sword can help a novice and make a expert really powerful. But the most important is who is using the sword.
That's the subtitle, yurks! Let me paraphrase it using my Cantonese:
Cloud: Which is more important? Martial Arts or a good sword?
Cloud's father: A good sword can make someone without martial arts mighty, and also can make a master conquer the world. But most important is the character of the person who uses the sword. Remember, there is no enemies to kindness.
And that's perhaps my starting point.
There were a few things that drawn my attention to Maven2. And yes, the push factor is the documentation (more of that later). The most important part was a clear definition of a project structure. It is not entirely easy at first I must admit coming from the pure ant environment. Took some time to familarize with it. And I have also similar problem with "moving" or "shifting" artifacts. One way to control this is really to host an internal repository and we control what is really needed (together with fixing the version of the dependencies). This is a fact of life - there are many "untested" or "ill-tested" artifacts. The original developers might not have meant to do a bad job, it is just a reality that we have to live with (even with commercial products!). Rather than whinning and crying, I control this chaos.
Oh, I forgot to mention - why is it important for me to have a clear project directory structure. Of course, to be honest, I could define one and the rest of my teams follow it. But think: Is this what you want your guys to learn? i.e. YOUR structure, and YOUR way of organization? Well, what I want is this: I want to enhance their productivity. If I can follow some open way of structure, and there is wide adoption (i.e. other companies are also adopting - which is of course a dream), then it will be easier for my team to move onto another job or role in another company. Or for other skilled engineer to join my team too - it works both ways. Let's be honest: this is NOT their first company or team, and won't be the last. If I enhance their role and skill, I think I am on a better bet to retain good skilled teams.
Furthermore, I often think when running multiple projects with my teams, it is really best to have a "common" structure, so that when a "new" team member is dropped into the project, productivity will not be affected too adversely - it is a reality of life, at times we do need some help from other teams.
So, there is a plus if we have a proper project directory structure. i.e. where we place our codes, where we place the configuration files, the web stuffs, etc.
Maven provides that. I do not have experience with Ivy (yet). But I think I will take a look at it soon from all those good words that were said, not to forget a few others in the blog mentioned above.
All said, I admit the documentation of Maven was more of a hinderance to me than of a help. In fact, at times I do better without it! Why is it so? well.... blame it on us! I thought it is supposed to be an open source project, isn't it? And one with a good intention. Those who complained about the documentation (like me), are NOT the ones writing the documentation. If we want it to be better, well... roll-up your sleeves and help out by contributing to the quality and detail of the documentation. In fact, there are so many "experts" who have used Maven and complained about the quality of the documentation, yet I don't see them on the list of contributors. Is Howard on the list? Is Jay on the list? Is Jon on the list? Is Gabriel on the list? Carols who is from the maven team commented "documentation could be better way" in the long series of comments. Notice there is no ivory tower talk - he is already contributing to the project. I think his credential blows the rest away (and mine too when I say the documentation is a hinderance because I have not helped in the documentation either, so shame on me). It is because of this, that's why I kept much of my silence. If it is not good (enough), most likely it is because we are not contributing to its success when we see the problem. Just admit it.
The point is simple: This is an open source project. Complains will go that far. The better thing to do is to help out when you see the problem. Of course, as end users of a product, we can fly to another product which gives us better stuff (that's seems to be a prevalent behavior when you read those comments)... but honestly, I think that is a ... not so good attitude to life in general. When we take something, it is always good to give back something too.
So, what is said in the StormRiders quotes above is true: But most important is the character of the person who uses the sword. Remember, there is no enemies to kindness.
No comments:
Post a Comment