Hi Johannes, this is very useful, could you put maybe onto the Fiji wiki that when searching for "Maven" this would shop up? I guess I will know if I really got it once I try to make a new src-plugins plugin ...
It definitely made into my "GIT & Maven HowTo" directory ... Thanks a lot, Steffi On Jul 10, 2012, at 13:50 , Johannes Schindelin wrote: > Hi Curtis, > > On Tue, 10 Jul 2012, Curtis Rueden wrote: > >> On Tue, Jul 10, 2012 at 11:21 AM, Johannes Schindelin > < >> [email protected]> wrote: >>> I will make a branch with a simple pom and will be on Skype later. >>> Fair ennough? >> >> I have done this for imglib2-algorithms-legacy and pushed to master. > > Darn, you beat me to it! ;-) > > But that gives me more time to explain what it takes to make a new Maven > project. > > All it really takes is a pom.xml file and a certain directory structure. > Technically, you can override the default directory layout in the pom.xml, > but why do so? It only breaks expectations and is more hassle than it is > worth, really. > > So the directory structure is: you put your .java files under > src/main/java/ and the other files you need to be included into > src/main/resources/. Should you want to apply the best practices called > "regression tests" or even "test-driven development": your tests' .java > files go to src/test/java/ and the non-.java files you might require > unsurprisingly into src/test/resources/. > > So what does a pom.xml look like? This is a very simple example: > > <?xml version="1.0" encoding="UTF-8"?> > <project xmlns="http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd";> > <modelVersion>4.0.0</modelVersion> > > <groupId>sc.fiji</groupId> > <artifactId>my-uber-library</artifactId> > <version>2.0.0-SNAPSHOT</version> > </project> > > The first 6 lines are of course just a way to say "Hi, Maven? How are you > today? This is what I would like you to do:". > > The only relevant parts are the groupId, which by convention is something > like the inverted domain name (similar to the Java package convention), > the name of the artifact to build (it will be put into target/, under the > name <artifactId>-<version>.jar). And of course the version. > > Now, why did I bother so much with Mavenization of Fiji? The real reason > is that Maven is not only a build tool but first and foremost a dependency > management tool. Maven has so-called Maven repositories where it stores > compiled artifacts. ImageJ2's Maven repository lives here: > http://maven.imagej.net:8081/ (most functions can be accessed via > http://maven.imagej.net/ just as well). It is like Fiji's precompiled/ > directory, but done right. > > Next, for Maven to know what you are looking for, you typically have to > add the dependencies into the pom.xml file. For example, every ImageJ 1.x > plugin will depend on ImageJ 1.x. So let's add that (before the final > </project> line): > > <dependencies> > <dependency> > <groupId>net.imagej</groupId> > <artifactId>ij</artifactId> > <version>1.45b</version> > </dependency> > </dependencies> > > As you can see, dependencies are referenced under the same groupId, > artifactId and version triplet (also known as GAV parameters) that you had > to declare for the current project. > > For Maven to find the dependencies, it has to know about the location of > the repositories. As you know, we are strong proponents of collaboration > within the scientific community, so we started the scijava effort last > hackathon in December. To this end, Curtis began the scijava "super POM" > which is supposed to declare repositories we use (and other metadata as > well, such as current artifact versions we provide). To benefit from this > in your project, add this to your pom.xml: > > <parent> > <groupId>org.scijava</groupId> > <artifactId>pom-scijava</artifactId> > <version>1.15</version> > </parent> > > <!-- NB: for project parent --> > <repositories> > <repository> > <id>imagej.releases</id> > > <url>http://maven.imagej.net/content/repositories/releases</url> > </repository> > <repository> > <id>imagej.snapshots</id> > > <url>http://maven.imagej.net/content/repositories/snapshots</url> > </repository> > </repositories> > > You will see that there are two different repository types: releases and > snapshots. The snapshot versions are "in-progress" versions. If you > declare a dependency with a "-SNAPSHOT" suffix in the version, Maven will > look once a day for new artifacts of the same versions; otherwise, Maven > will look whether it has that version already and not bother > re-downloading. > > So what if you have multiple .jar files you want to build in the same > project? Then these need to live in their own subdirectories and there > needs to be a common parent POM, a so-called "aggregator" POM. For an > example, look at Fiji's src-plugins/pom.xml. Basically, it is adding the > <packaging>pom</packaging> entry as well as a couple of subdirectory names > to the <modules> section. > > There are many more things you can do with Maven, but chances are you will > not need them. > > The simplicity of the pom.xml you need comes from the fact that Maven > defines implicit defaults. It calls that "convention over configuration". > But since we are not converting projects (or at least since we are > flexible enough to adapt), I would strongly recommend staying with the > defaults as much as possible. It also makes your project more accessible, > something that I think we excel at. > > Now, in the context of scijava, you will most likely never write a pom.xml > from scratch. You will rather more likely edit an existing one, possibly > after having copied it. > > Ciao, > Dscho _______________________________________________ ImageJ-devel mailing list [email protected] http://imagej.net/mailman/listinfo/imagej-devel
