[OSGeo-Discuss] Common Maven Repository

[Landon Blake]

I've messed around with Maven a little bit, and I'm afraid I'll mess
around with it some more if I get more involved in GeoTools.

I must say that I find the tool might be overkill for all but the most
complex projects. I believe Ant is a much better tool for simple
projects.

This is just my humble opinion. I worry sometimes about setting the bar
too high for entry level programmers.

Landon

-----Original Message-----
From: discuss-bounces at lists.osgeo.org
[mailto:discuss-bounces at lists.osgeo.org] On Behalf Of Jody Garnett
Sent: Friday, July 18, 2008 2:02 PM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Common Maven Repository

Frank Warmerdam wrote:
> Perhaps you could provide some more general information on what role 
> Maven plays, and what sort of resources and complexity would be 
> involved in OSGeo doing what you suggest.
Maven is a build tool that takes a different approach than Ant (or 
Make). Rather than document a series of steps saying how to "build" or 
"compile" it provides a description of the project (saying the java 
source code is here, the documentation is here, the developer email 
address is this etc...) in the form a "pom" file (for project object
model).

Maven then makes uses of a whole bunch of scripts (downloadable from the

web at runtime) to perform tasks based on the description; tasks like 
compiling, building javadocs, running tests, creating a jar and so on. 
It can even make a website publishing all the reports...

Here are some reports for gt-main:
-
http://maven.geotools.fr/reports/modules/library/main/project-reports.ht
ml

One of the most important things a pom file says is what other projects 
the code needs; these are provided in the form of dependencies...here is

part of the GeoTools pom.xml:
>       <dependency>
>         <groupId>com.vividsolutions</groupId>
>         <artifactId>jts</artifactId>
>         <version>1.9</version>
>       </dependency>
This block of xml says that geotools needs JTS version 1.9 in order to 
compile and run. When building maven will download JTS from a remote 
repository (the website Paul would like to set up) and store the result 
in a local repository on the users hard drive.

Here are the dependencies for gt-main:
-
http://maven.geotools.fr/reports/modules/library/main/dependencies.html

So a maven repository is a like an FTP site for downloading artifacts 
combined with a bunch of pom.xml xml files document what versions are 
available and how the artifacts fit together.

There are websites devoted to finding this stuff out:
- http://maven.ozacc.com/
- http://mvnrepository.com/
These websites let you search repositories for published java projects 
and provide you the xml fragment needed to depend on them.

Here is a repository we maintain for GeoTools development, we have a 
mirror in france:
- http://lists.refractions.net/m2/
- http://maven.geotools.fr/repository/
> Generally speaking, I think we would be ok with doing this if it was 
> useful for the various Java projects but someone would need to step 
> forward to do the work.
This would be very useful.
>   Such a service would be setup and administered by SAC - the OSGeo 
> System Administration Committee.
We have set ours up as a webdav folder; maven has the ability to 
"deploy" jars from the various development teams to a webdav folder. It 
can also deploy artifacts via various other protocols - here is a list:
- http://maven.apache.org/wagon/

There are several tools you can use to manage a repository - here is a
list:
- http://maven.apache.org/repository-management.html

We have so far not needed to use a tool; a simple webdav folder has been

sufficient.
Jody
_______________________________________________
Discuss mailing list
Discuss at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


Warning:
Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately.