Apache
/
maven
mirror of https://github.com/apache/maven.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

o adding more historyy 

git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@328242 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Jason van Zyl 2005-10-25 02:46:45 +00:00
parent 79c7ddaae6
commit ddd19344e3
1 changed files with 46 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
maven-site/src/site/apt/background/history-of-maven.apt
View File

@ -16,25 +16,23 @@ History of Maven by Jason van Zyl
making Maven about 4 years old! Maven spent about 5 months as part of the Alexandria before moving on to its next home
in the {{{http://jakarta.apache.org/turbine}Turbine}} project.
Though Maven started in Alexandria the testbed for its use was the Turbine project. Turbine was in the process of
Though Maven started in Alexandria the test bed for its use was the Turbine project. Turbine was in the process of
decoupling its persistence layer, services layer and web layer into separate builds and I got very tired of having
to maintain several different builds which were essentially the same. There was no way to easy template Ant builds
in those days and every ant build appeared to be different and I found this incredibly frustrating and futile. I figured
who really cares how the build works so long as it works and is easy to use. The infrastructure of a project is
incredibly important but the value of a project lies in the application being developed. As such the build is
generally neglected and tends to fall apart in times of great need like when you need to prepare a release or when
more then a couple people diddle with it. In Jakarta land four years ago it was rare that a Ant build worked out of
the box. Mind you many Turbine developers suffered as I tried to get Maven working which is something I regret, but
I figure how do new projects start and survive if someone doesn's suffer. I figured it was for their own good
and after much gnashing of teeth I think Maven has finally come of age. It reminds me of one of my favourite quotes
from Ralph Johnson and Don Roberts in Patterns for Evolving Frameworks:
generally neglected and tends to fall apart when you need it to work most like when you need to prepare a release or when
more then a couple of people are working on the project. In Jakarta land four years ago it was rare that a Ant build
worked out of the box. Mind you many Turbine developers suffered as I tried to get Maven working which is something I regret,
but I figure how do new projects start and survive if someone doesn's suffer. I figured it was for their own good
(I've been known to have an opinion or two) and after much gnashing of teeth I think Maven has finally come of age.
It reminds me of one of my favourite quotes from Ralph Johnson and Don Roberts in Patterns for Evolving Frameworks:
+-----+
People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction
on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a
resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.
+-----+
<People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction
on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a
resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.>
I didn't really know what the final result would look like I just knew there had to be a better way.
But to start with I know I wanted:
@ -50,20 +48,47 @@ you look at, the more general your framework will be.
that could be used in each of the Turbine builds and that made me happy.
As noted above one of the projects in Alexandria at the time was Gump. Sam Ruby tried to convince me that using
the Gump model would be a good idea so I took a look. After taking a look the descriptors I noted that Gump
pretty much allowed any project to do whatever it wanted in terms of directory structure and use of JARs in CVS
the Gump model would be a good idea so I took a look. After taking a look at the descriptors I noted that Gump
pretty much allowed any project to do whatever it wanted in terms of directory structure, use of JARs in CVS,
multiple artifacts per project, documentation splayed everywhere, and several other things that made no sense to me
as Gump was not trying to standardize anything at the time but trying to continously integrate anything it could
get its hands on. My goals were different and I wanted to make an
{{{http://www.oreillynet.com/pub/a/network/2005/08/30/ruby-rails-david-heinemeier-hansson.html}opinionated}} piece
of software and I preferred the notion of convention over configuration. I wanted a project's infrastructure to
look the same and work the same so I continued to pursue my own model for a project and decided to disagree with
Gump's particular tact at project modelling which I thought was too flexible.
Gump's particular tact at project modelling which I thought was too flexible. I wanted to save people time by being
able to find things in the same place. Again the value in a project is the final result: how it is constructed
and built predictable and easy. I fully admit some warts in Maven 1.x sometimes made things harder but that is
par for the course with first generation tools.
The next thing I noticed were all the JARs that we were storing in CVS. We had many copies of Xerces laying around
which is a waste of space but more important was that every time the version of Xerces changed I had to update the
copies of Xerces in each of the projects. This is when I decided to employ standard Java-like inheritance in the
model used and find a way to create a repository for things you need to build. So I hacked in some inheritance
goop and now it was time for the repository.
The next thing I noticed were all the JARs that we were depending on were stored in CVS. We had many copies
of Xerces laying around which is a waste of space, every time the version of Xerces changed
I had to update the copies of Xerces in each of the projects, but more importantly without some declarative statement of
your dependencies there is no way you could perform any analysis. People tend to miss the point entirely regarding
a declaritive dependency use. People say it's so easy just to store their dependencies in an SCM but try decomposing
your big crappy build into components to encourage resuse and ease of maintenace, or try to analyse what you might
need at runtime between all your different apps with commons dependencies in the graph and you're shit out of luck.
The true power of declaritive dependencies lies not in the fact that you can save a few bytes of disk space, though
it can really add up if you're not careful, but in the analsys that can be performed. Once you have a decent graph
all sorts of things are possible. Back to history: so now that declarative dependencies existed it needed to
be easier ...
This is when I decided to employ standard Java-like inheritance in the model used and find a way to create a repository
for things you need to build. So I hacked in some inheritance goop and now it was time for the repository. I asked
around Apache to see if it would be possible to host a repository and soon found out that it was not possible to
host non-Apache-like artifacts. So LGPL and GPL artifacts were out which didn't really make for a useful repository.
After a little hunting I found {{{http://www.ibiblio.org}Ibiblio}} which is a vast archive of all sorts of neat
stuff including tons of free software. One of the mandates of Ibiblio is to aid in the dispersal of free software.
Sounded perfect to me so I got in contact with John Reuning at Ibiblio and the rest is history. Working with the
folks at Ibiblio has been a pleasure, the admins there are an amazingly helpful and talented bunch. They let us
store whatever free software we want, provide great stats, and will let us host any software we want. Ibiblio
is very cool.
Many people had some problems with Maven 1.x but it generally worked and all tools in their first generation
suffer from many short comings and the only way to overcome that is to forge ahead and try to create something
better the next time around. With all the feed back the Maven developers have received from 1.x users
and during the betas of 2.0 we think we've finally got something to build on. The first version of Maven
was written by myself with lots of help from Bob McWhirter
~~ jar jar
~~ ibiblio reasons