Re: maven.
Re: maven.
- Subject: Re: maven.
- From: Henrique Prange <email@hidden>
- Date: Fri, 03 Apr 2009 21:13:05 -0300
Hi Chuck,
Chuck Hill wrote:
You should really start reading the book Maven: Definitive Guide [1].
It's free and contains most information you need to understand the
basics about Maven in one place. And you don't have to read the entire
book to understand most of the Maven concepts.
The fact that I need to read even part of a book alarms me.
C'mon, don't be lazy. :p I suggested the book because it has a
comprehensive collection of information about Maven in one place. I
think it is better than run through a lot of disconnected articles.
I really don't know what it is about maven, but it's like someone
tried to come up with the most complex solution to these problems
they could. Every sentence just introduces some new
layer -- it's like a build system composed of Matryoshka. I have the
distinct impression that one could solve 75% of this problem with 10%
of the complexity.
If you don't have to write any Maven plug-in, the complexity is almost
imperceptible. In fact, everything will be much more simple.
Much more simple than what?
Much simple than it seems in the article Mike pointed out.
Simpler than not using Maven?
Depends.
Simpler than the few Ant files that I now have?
For me, certainly. For most people, probably. For you and your team, not
at all. :)
Your projects will have the same behavior when you have the same kind
of configuration (most cases).
I have that now, other than external dependancy management. I handle
that with a framework of jars unit to each application, versioned with
the application.
Cool. You have made your own proprietary solution. You solved your
problem and it is enough for you. That is great. You are not in the kind
of situation I suggest to use Maven. You already have what you desire.
Now I would like to ask... How much time you spent until reach the level
of control you have today? How simple do you think it is for other
people to develop exactly in the same way you do? How much time is
required to add a new developer to your team? What if this developer
uses Linux instead of Mac and he is not inside your company?
And this configuration can be inherited. You have to write less
configuration and the declarative way of writing Maven configuration
is much more informative.
That works with Ant too. Each new project (app or framework) is:
<project name="ProjectName" default="build" basedir=".">
<import file="../Ant/common.xml"/>
</project>
I know you can try and occasionally solve most problems with Ant. That
is not the problem. Nobody said "you can with Maven, but you can't with
Ant". But Maven has defined concepts you have to elaborate by yourself
with Ant. It has advantages and drawbacks as any tool.
In Ant you say "how to make the project produce things". In Maven you
say "what the project is". Maven takes care of do what it have to do,
in most cases.
Or is it that you rely on someone else already having done the "how to
make the project produce things" and simply accept that you will follow
their way?
Sure. If the solution is good, what is the problem of reusing it?
I think Maven's trying to solve 100% of the problem and they get
where they are. All I really want is my ant build file to build or
download dependencies first. I would say I basically want Ivy,
except that kind of pisses me off, too.
As you said, if you only want the dependency management stuff, you
don't need Maven. You want Ivy or Maven Ant Tasks [2].
The Maven dependency management mechanism really shines. But Maven
goes beyond that.
Ivy is like a couple of Maven guys split off to write a different
solution to 98% of the problem instead of 100%.
If you keep studying Maven, you'll realize Ivy solves 10% of the
problem. :)
But what IS the problem?
How to handle the development lifecycle of interdependent projects. From
the inception to the continuous process of release and maintenance. How
you build, package, test, deploy, release, produce documentation,
produce reports and metrics and etc. In a way that not only you, the guy
that made the scripts, knows how to handle. In a way that can be clear
for other people too. In a way that other people can easily use and
contribute. In a way that a simple change in the environment doesn't
bring everything down.
Maven users always say things like "Study it
and you will learn how great it really is". But I have not yet heard
concrete reasons, beyond dependency management, why this is so. Show me
the money.
I heard the same arguments about Test Driven Development every day. But
I can't imagine how to develop software without a test first.
I started using Maven 3 years ago to manage WebObjects projects on my
company. We invested money and time along these years to improve the way
we develop software. Before this investment, every release was a pain.
We were not able to follow our schedules. Development was a mess. It was
very difficult to introduce new members in the middle of a project. It
was hard to define the quality of the code produced. Resuming, we wast a
lot of time.
We started to seek a way to reduce the waste of time. Maven solved all
the problems? No. We have also started to use other tools and concepts,
like Eclipse, Jira, Confluence, Hudson, Selenium, Scrum, TDD and go on.
Today Maven help us to perform lot of tasks we didn't have idea about
how to accomplish in the past. Is it perfect? Not at all. But it is a
invaluable piece on our environment.
I think this is the problem with Java vs Ruby people. The Rails
community is happy to put out a framework that is simple and narrowly
focused. It seems to me that the Java community isn't happy unless
every level of the framework is a dependency-injected pluggable
framework for building frameworks. Where's my simple dependency
manager? Where's my ant task that just lets me say:
<dependencies>
<dependency name="log4j" version="1.2.14" source="someMavenRepo"
dest="Libraries"/>
<dependency name="MyCustomFramework" version="latest"
source="myRepo" dest="${wo.local.frameworks}"/>
</dependencies>
Well, using Maven Ant Tasks you will have to add something like that
to your build.xml.
<artifact:dependencies pathId="dependency.classpath">
<dependency groupId="log4j" artifactId="log4j" version="1.2.14"/>
<dependency groupId="your.company" artifactId="MyCustomFramework"
version="1.0-SNAPSHOT"/>
</artifact:dependencies>
It is similar. The repository configuration goes in a separate section.
Each project has their particularities. Those tools normally try to
provide a solution that is not restricted to toy problems. In most
cases, some kind of complexity must be added to increase the reuse.
IMHO, that is why Eclipse is cool, Maven is cool, Ant is cool and
other Java tools and frameworks are cool.
I am not sure that I would agree that any of them are cool. Free and
widely used, yes. But cool? Ant is horrid. Most Java tools and
frameworks are too. Eclipse... free, powerful, widely used? Yes. But
it has grown into something of a juggernaut.
IMHO, they are cool in the sense they help people to solve problems
better than without using those tools.
Because if you can't solve your specific problem with the provided
solution, you just have to make few changes to achieve your goal. And
the base solution can evolve, making your own little modification even
better over time (of course, by means of API changes and other things
that makes us feel really sad).
And you can always produce your own solution. I choose Maven in the
past exactly because I don't want to create proprietary solutions that
only members of my team can understand. When I say proprietary
solution I mean name standards, layout structure, configuration and etc.
Why? Show me the money.
1) I don't like to reinvent the wheel. I don't like to waste my time
thinking about problems that other people have already solved in a way
that satisfy me.
2) In our profession I believe that if I can make people lives easier to
work with me, is a plus. Even people I haven't met.
Ant does everything else I care about. I hate ant, don't get me
wrong, but it's pretty straightforward. I understand Maven is trying
to do a lot more, and that's super great and all, but I don't WANT that.
So, you will probably be frustrated using it. I choose Maven because
of the concepts behind the tool. Not because of the tool itself. I
wanted the discipline and the restrictions imposed by the Maven
lifecycle. Most of Maven restrictions I found made me improve the
software development process on my company.
That sounds to me like "I chose it for love of technology, not technical
reasons."
I think it is exactly the opposite. When I said concepts behind the tool
I mean the technical reasons. The ideas behind the technology. The rules
to manage the software development process.
I eschew complexity in favor of "the simplest thing that can
work". I love simplicity, not technology. The technology that I use, I
use because it is the simplest way to achieve the result that I want.
Me too.
I'm not selling Maven. What I say on this list is based only on my own
experience. Maven makes my life easier and the development process more
reliable on the companies I work.
So if you want to "show me the money", that is the path.
It would be a pleasure to write a real case about the subject for you.
Until I have the time, everything I can say is go to WOWODC and you'll
see. ;)
Cheers,
Henrique
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >maven. (From: Mike Schrag <email@hidden>) |
| | >Re: maven. (From: Henrique Prange <email@hidden>) |
| | >Re: maven. (From: Chuck Hill <email@hidden>) |