GeoTools 1 was using Ant if my memory serves me right. Ant could has been
considered an alternative to Maven. But the fact that Maven injects some
standardization (standard directories, standard build phase) was considered a
good point since it brings a bit of uniformity.
But above all, the major benefit of Maven (as I see it) is it management of
dependencies. When building, all projects dependencies are automatically
downloaded from the net. I'm not aware of an other build tools doing that. Last
time I looked, Ant-based projects were used to put their dependencies on their
CVS or SVN, which I would not recommand for a project having as large
dependencies as GeoTools.
Sunburned Surveyor a écrit :
> (1) The "programmers will only need to learn one build tool" argument
> could be made for some other widely accepted build tools as well. You
> could also argue that a build tool isn't even necessary to compile
> Java code into a usable form.
If we compare Maven with Ant, the advantage of Maven is that users know that we
will find standard build phases: "compile", "install", "test", "deploy",
"javadoc" etc. There is no such standards in Ant. So new developpers in a
Maven-based project don't need to learn how to run the test suite, while new
developer in a Ant-based project need to read the project documentation in
order
to know which Ant target he should invoke.
> (2) I don't know much about Hudson, but you can certainly run a tool
> like Ant externally with something as simple as a batch script. Is
> Hudson yet another tool we are introducing into the process?
Maven is well integrated in Hudson (by the way, Maven is well integrated in
Netbeans too - Netbeans can opens Maven projects directly, you don't even need
to run "mvn eclipse:eclipse" as for Eclipse). Hudson supports scripts as well,
but if every modules were doing their build differently, we would probably have
to specify a lot of special cases to Hudson, which make the job harder.
> It is important to remember that every road block raised to contribution
> keeps more contributors away. At the end of the day, contributors are
> the life blood of any open source project. Geotools should be looking
> for ways to make contribution easier, not ways to make it more
> difficult. There is a delicate balance that must be struck between
> standards enforcement across a project and appeal to new contributors.
I agree with that, but I think that getting ride of Maven would make
contribution to GeoTools harder, not easier. I realize that Maven is an
additional complexity for new contributors unfamiliar with this tools. But on
the other hands it also make life much easier for those who are familiar with
this tools. So no matter what we do (use Maven or not), there is gain and lost
for new contributors, depending if they are familiar with Maven or not.
We can not said the same for other tools like Ant, because Ant doesn't propose
as much standards (standard directories, standard build phase, standard
deployment repositories, etc.). Imagine two scenarios:
* A new developper familiar with Ant arrives on a Ant-based project.
* A new developper familiar with Maven arrives on a Maven-based project.
The developper familiar with Maven would still have less to learn than the
developper familiar with Ant, because of the standards. Part of our interest to
Maven is in that point.
> P.S.S. - I wonder if a "looser" system or a system in which module
> maintainers have more independence over the build process would have
> prevented a fork like GeoTidy?
No. The geotidy project started because of disagreement about what code we put
in the modules, not how we build them. Furthermore I sincerly hope that this
"fork" is only temporary. In my mind, despite the difficulty to maintain the
build, Maven is absolutly not in question in the geotools / geotidy affair.
However if we want to look at the tools side, a distributed versionning system
may be something to explore. But this is an other topic unrelated to Maven.
Martin
------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
