Ok, you have a project you've just downloaded, and you know it builds with Maven. There's no documentation to speak of for the project itself, so where to start?
If you were using Ant, you'd probably run ant -projecthelp
, and if that didn't help,
just run "ant" and hope the defualt goal is what you wanted.
A build.properties.sample file may have been provided so you'd copy that and edit it to see if that
helped. Then you'd fix individual problems as they came up.
If everything goes wrong and you can't find the right goal or what property it's expecting, you dig into
build.xml and look at what it is attempting.
The process for Maven should be simpler unless the project is being really unhelpful.
If there is no maven.xml
file, then you know the build hasn't been customised so you can rely on
a few things working.
If you know it is a JAR, maven jar
should do what you expect. If you know it is a web application
then maven war
should produce the expected results, and if there are many subprojects,
maven multiproject
is a good bet. Finally, maven site
(or
maven multiproject:site
) should produce some documentation or at least some statistics.
You shouldn't expect to have to define any properties outside what the project has provided and you have already defined to get Maven running, as only the standard Mavne plugin properties are being used, and you know how they behave.
If there is a maven.xml
file, then the build has been customised. You can still rely on the
above goals doing what they advertise, but they might not be the recommended way of building that
particular project. This is especially true when projects define their own multi-project structure without
using the multiproject plugin to build.
The first step would be to run maven -u
. Similar to ant -projecthelp
, it
will list all of the goals in maven.xml
and any description listed with the goal by the
author. Standard goals like jar
will be omitted as their behaviour is already known.
You may just run "maven" and rely on the default goal being what you wanted.
You may still get some of the ant problems, where the above doesn't help or the properties are required
and not defined. The same process will apply here - you investigate maven.xml
which should be
much shorter as it only contains customisations.
There will always be bad builds under either system, but Maven gives you quite a head start by providing a standard set of build pieces that you can expect to work out of the box.
Having said that, there are still a few areas where a Maven build won't work out of the box. By far the most common occurrence of this is depending on a JAR that is not published to a public place. This might be because of licensing (eg a lot of the standard Sun JARs cannot be redistributed by Maven), or because it is a development build of some library that was being built locally.
If you are downloading the source to a project, it is always worth running maven build:end
once on each project.xml
. This won't do anything except download all the dependencies
the project wants. If some can't be found, then you should track them down while still online, and harass
the authors of the project via their users mailing list (which you should also find in
project.xml
).