It looks like I'm loosing this battle. :]

Thank you for giving me the opportunity to present my ideas.

Landon

On Wed, Feb 4, 2009 at 12:56 PM, Martin Desruisseaux
<martin.desruisse...@geomatys.fr> wrote:
> 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

Reply via email to