You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maven.apache.org by jv...@apache.org on 2014/02/22 19:54:25 UTC
svn commit: r1570880 - in /maven/site/trunk: ./ content/apt/background/
content/markdown/background/
Author: jvanzyl
Date: Sat Feb 22 18:54:25 2014
New Revision: 1570880
URL: http://svn.apache.org/r1570880
Log:
Start converting documents I plan to work on to Markdown with an aim to using front-matter a la Jekyll
Added:
maven/site/trunk/content/markdown/background/
- copied from r1570705, maven/site/trunk/content/apt/background/
maven/site/trunk/content/markdown/background/history-of-maven.md
- copied, changed from r1570705, maven/site/trunk/content/apt/background/history-of-maven.apt
maven/site/trunk/content/markdown/background/philosophy-of-maven.md
- copied, changed from r1570705, maven/site/trunk/content/apt/background/philosophy-of-maven.apt
Removed:
maven/site/trunk/content/apt/background/
maven/site/trunk/content/markdown/background/history-of-maven.apt
maven/site/trunk/content/markdown/background/philosophy-of-maven.apt
Modified:
maven/site/trunk/pom.xml
Copied: maven/site/trunk/content/markdown/background/history-of-maven.md (from r1570705, maven/site/trunk/content/apt/background/history-of-maven.apt)
URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/background/history-of-maven.md?p2=maven/site/trunk/content/markdown/background/history-of-maven.md&p1=maven/site/trunk/content/apt/background/history-of-maven.apt&r1=1570705&r2=1570880&rev=1570880&view=diff
==============================================================================
--- maven/site/trunk/content/apt/background/history-of-maven.apt (original)
+++ maven/site/trunk/content/markdown/background/history-of-maven.md Sat Feb 22 18:54:25 2014
@@ -1,102 +1,92 @@
- ------
- History of Maven
- ------
+ # History of Maven
+
+<!--
+ Allow front-matter here eventually. Just copy Jekyll
Jason van Zyl
- ------
12 October 2005
- ------
+-->
+
+## History of Maven by Jason van Zyl
-History of Maven by Jason van Zyl
+Maven began its life in the [Jakarta][1] [Alexandria][2] project. The Alexandria project is now defunct but was the breeding ground for not only Maven, but for the [Gump][3] and [Forrest][4] projects as well. The first import of prototype sources happened in
+[August 2001][5]. As of the date of this document (October 2005) Maven was [removed][6] from Alexandria about 3 years, 7 months ago 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 [Turbine][7] project.
- Maven began its life in the {{{http://jakarta.apache.org}Jakarta}} {{{ http://jakarta.apache.org/alexandria/legacy/}Alexandria}}
- project. The Alexandria project is now defunct but was the breeding ground for not only Maven, but for the
- {{{http://gump.apache.org}Gump}} and {{{http://forrest.apache.org}Forrest}} projects as well.
-~~ From the old {{{http://cvs.apache.org/viewcvs.cgi/jakarta-alexandria/proposal/maven/?hideattic=0}CVS}} archive
- The first import of prototype sources happened in
- {{{http://mail-archives.apache.org/mod_mbox/jakarta-alexandria-dev/200108.mbox/%3c20010827163505.53005.qmail@icarus.apache.org%3e}August 2001}}.
- As of the date of this document (October 2005) Maven was
- {{{http://mail-archives.apache.org/mod_mbox/jakarta-alexandria-dev/200202.mbox/%3c20020202153719.50163.qmail@icarus.apache.org%3e}removed}}
- from Alexandria about 3 years, 7 months ago 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://turbine.apache.org/}Turbine}} project.
-
- 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 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.>
-
- 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:
-
- * <<A model for a project>> so you could look in one place for everything that pertained to the project
-
- * <<A standard directory structure>> so you didn't have to go fishing around for libraries, sources and documentation
-
- []
-
- So started using a model with a simple XML representation and picked what I thought were some decent standards for
- a directory structure and that's how it started. I was still using Ant under the covers but I had some standard targets
- 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 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 continuously 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. 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 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 declarative 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 reuse and ease of maintenance, or try to analyze 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 declarative 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 analysis 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
- ~~ maven top-level project
- ~~ use of jelly
- ~~ move toward 1.0
- ~~ development of m2
- ~~ present day
+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 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.
+
+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:
+
+- A model for a project so you could look in one place for everything that pertained to the project
+- A standard directory structure so you didn't have to go fishing around for libraries, sources and documentation
+
+So started using a model with a simple XML representation and picked what I thought were some decent standards for
+a directory structure and that's how it started. I was still using Ant under the covers but I had some standard targets
+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 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 continuously integrate anything it could
+get its hands on. My goals were different and I wanted to make an
+[opinionated][8] 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. 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 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 declarative 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 reuse and ease of maintenance, or try to analyze 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 declarative 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 analysis 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 [Ibiblio][9] 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
+
+[1]: http://jakarta.apache.org
+[2]: http://jakarta.apache.org/alexandria/legacy/
+[3]: http://gump.apache.org
+[4]: http://forrest.apache.org
+[5]: http://mail-archives.apache.org/mod_mbox/jakarta-alexandria-dev/200108.mbox/%3c20010827163505.53005.qmail@icarus.apache.org%3e
+[6]: http://mail-archives.apache.org/mod_mbox/jakarta-alexandria-dev/200202.mbox/%3c20020202153719.50163.qmail@icarus.apache.org%3e
+[7]: http://turbine.apache.org/
+[8]: http://www.oreillynet.com/pub/a/network/2005/08/30/ruby-rails-david-heinemeier-hansson.html
+[9]: http://www.ibiblio.org
\ No newline at end of file
Copied: maven/site/trunk/content/markdown/background/philosophy-of-maven.md (from r1570705, maven/site/trunk/content/apt/background/philosophy-of-maven.apt)
URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/background/philosophy-of-maven.md?p2=maven/site/trunk/content/markdown/background/philosophy-of-maven.md&p1=maven/site/trunk/content/apt/background/philosophy-of-maven.apt&r1=1570705&r2=1570880&rev=1570880&view=diff
==============================================================================
--- maven/site/trunk/content/apt/background/philosophy-of-maven.apt (original)
+++ maven/site/trunk/content/markdown/background/philosophy-of-maven.md Sat Feb 22 18:54:25 2014
@@ -1,36 +1,34 @@
- ------
- Philosophy of Maven
- ------
+# Philosophy of Maven
+
+<!--
+ Allow front-matter here eventually. Just copy Jekyll
Jason van Zyl
- ------
12 October 2005
- ------
-
-Philosophy of Maven
+-->
- Maven is generally considered by many to be a build tool. Many people who come to Maven initially are familiar
- with Ant so it's a natural association but Maven is not just a build tool, and not just a replacement for Ant.
- Maven is an entirely different creature from Ant. Ant is simply a toolbox whereas Maven is about the
- application of patterns in order to achieve an infrastructure which displays the characteristics of
- visibility, reusability, maintainability, and comprehensibility.
+Maven is generally considered by many to be a build tool. Many people who come to Maven initially are familiar
+with Ant so it's a natural association but Maven is not just a build tool, and not just a replacement for Ant.
+Maven is an entirely different creature from Ant. Ant is simply a toolbox whereas Maven is about the
+application of patterns in order to achieve an infrastructure which displays the characteristics of
+visibility, reusability, maintainability, and comprehensibility.
- Without these characteristics it is highly improbable that multiple individuals will work productively together
- on a project. Without visibility it is unlikely an individual will know what another has accomplished and as such
- there is a very good chance useful code will not be reused. When code is not reused it is very hard to create
- a maintainable system. When everyone is constantly rooting around trying to figure out where all these different
- bits and pieces are that make up your project there is very little chance anyone is going to comprehend the
- project as a whole. As a result you end up with the silo effect, a decay of shared knowledge along with
- the commensurate degree of frustration among team members. A natural effect when processes don't work
- in the same way for everyone.
+Without these characteristics it is highly improbable that multiple individuals will work productively together
+on a project. Without visibility it is unlikely an individual will know what another has accomplished and as such
+there is a very good chance useful code will not be reused. When code is not reused it is very hard to create
+a maintainable system. When everyone is constantly rooting around trying to figure out where all these different
+bits and pieces are that make up your project there is very little chance anyone is going to comprehend the
+project as a whole. As a result you end up with the silo effect, a decay of shared knowledge along with
+the commensurate degree of frustration among team members. A natural effect when processes don't work
+in the same way for everyone.
- Maven was born of the very practical desire to make several projects at Apache work in the same way. So that developers
- could freely move between these projects, knowing clearly how they all worked by understanding how one of them
- worked. If a developer spent time understanding how one project built it was intended that they would not have
- to go through this process again when they moved on to the next project. The same idea extends to testing,
- generating documentation, generating metrics and reports, testing and deploying. All projects share
- enough of the same characteristics, an understanding of which Maven tries to harness in its general approach
- to project management. On a very high level all projects need to be built, tested, packaged, documented
- and deployed. Of course there is infinite variation in each of the above mentioned steps, but this variation
- still occurs within the confines of a well defined path and it is this path that Maven attempts to present to
- everyone in a clear way. The easiest way to make a path clear is to provide people with a set of patterns that
- can be shared by anyone involved in a project.
+Maven was born of the very practical desire to make several projects at Apache work in the same way. So that developers
+could freely move between these projects, knowing clearly how they all worked by understanding how one of them
+worked. If a developer spent time understanding how one project built it was intended that they would not have
+to go through this process again when they moved on to the next project. The same idea extends to testing,
+generating documentation, generating metrics and reports, testing and deploying. All projects share
+enough of the same characteristics, an understanding of which Maven tries to harness in its general approach
+to project management. On a very high level all projects need to be built, tested, packaged, documented
+and deployed. Of course there is infinite variation in each of the above mentioned steps, but this variation
+still occurs within the confines of a well defined path and it is this path that Maven attempts to present to
+everyone in a clear way. The easiest way to make a path clear is to provide people with a set of patterns that
+can be shared by anyone involved in a project.
Modified: maven/site/trunk/pom.xml
URL: http://svn.apache.org/viewvc/maven/site/trunk/pom.xml?rev=1570880&r1=1570879&r2=1570880&view=diff
==============================================================================
--- maven/site/trunk/pom.xml (original)
+++ maven/site/trunk/pom.xml Sat Feb 22 18:54:25 2014
@@ -58,11 +58,12 @@
</distributionManagement>
<properties>
- <current20xVersion>2.0.11</current20xVersion>
- <currentStableVersion>3.1.1</currentStableVersion>
+ <currentStableVersion>3.2.1</currentStableVersion>
+ <currentStableReleaseDate>21 February 2014</currentStableReleaseDate>
+ <current32xVersion>3.2.1</current32xVersion>
<current31xVersion>3.1.1</current31xVersion>
<current30xVersion>3.0.5</current30xVersion>
- <currentStableReleaseDate>4 October 2013</currentStableReleaseDate>
+ <current20xVersion>2.0.11</current20xVersion>
<currentAntTasksVersion>2.1.3</currentAntTasksVersion>
<currentAntTasksReleaseDate>17 Apr 2011</currentAntTasksReleaseDate>
<versions2x>2.2.1,2.2.0,2.1.0,2.0.11,2.0.10,2.0.9,2.0.8,2.0.7,2.0.6,2.0.5,2.0.4,2.0.3,2.0.2,2.0.1,2.0</versions2x>