Re: maven.
Re: maven.
- Subject: Re: maven.
- From: Chuck Hill <email@hidden>
- Date: Mon, 6 Apr 2009 11:53:15 -0700
On Apr 3, 2009, at 5:13 PM, Henrique Prange wrote:
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?
A few days, less time than I _guess_ it would take me with Maven.
How simple do you think it is for other people to develop exactly in
the same way you do?
So far it has been pretty simple.
How much time is required to add a new developer to your team?
98%+ of the time is learning the domain and architecture. The build
infrastructure? Maybe half a day to get everything installed, built,
and configured.
What if this developer uses Linux instead of Mac and he is not
inside your company?
My current project is 100% remote / distributed and no problem
bringing on new people. As long as Eclipse/WOLips runs on Linux as
it does on OS X, I don't see what different that might make. I don't
use hard coded paths...
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?
One problem that I would expect is that you can only be all things to
all people by addressing the lowest common denominator. So anything
unique in how I want to have things work is either fighting against
the Maven way or writing my own extensions to Maven or giving up and
accepting something less than perfect.
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.
Interdependent? You mean circular dependancies? Or just a dependancy
tree without cycles?
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.
A simple change like someone deleting something from their Maven
repository that you were depending on? That is not a theoretical
question, I ran into that exact problem trying to build an Open Source
project that used Maven. I had a lot of fun tracking that down and
working around it.
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 confess, I usually write the tests after. If you can effectively
develop that way (and I can), I don't see that it makes a lot of
different when the tests are written. If you are having a hard time
working out the appropriate design or API, writing the tests first can
help clarify things.
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.
Maven helps you meet schedules? I am finding that hard to believe.
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.
That is a lot of changed tools and processes. It is hard to identify
which tool is responsible for what change.
Out of steam.
Chuck
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
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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>) |
| | >Re: maven. (From: Henrique Prange <email@hidden>) |