General
Source Code Integration w/ Eclipse
Multiproject support
WTP support
You must have some unit tests for your project, otherwise JUnit is ignored.
The dependencies defined in the POM don't need to be jars strictly. They can be projects in the eclipse workspace. If a dependency is an eclipse project a property needs to be added to that dependency to indicate so.
<dependency>
<groupId>group</groupId>
<artifactId>artifact</artifactId>
<version>version</version>
<properties>
<eclipse.dependency>true</eclipse.dependency>
</properties>
</dependency>
This indicates that the dependency is another project in the workspace. Note that the name of the referenced project is the artifactId.
The inverse also works. If you have included extra jars that shouldn't be in the eclipse classpath then you can set eclipse.dependency=false
Frequently you will want to include for compiled jars the source .java files to help with debugging.
The plugin is able to download sources archive at ${groupId}/java-sources/${artifactId}-${version}-sources.jar from the repository. This behavior can be disabled by configuring the maven.eclipse.src.download property. As an example, the source archive for the dependency MAVEN_REPO/eclipse/jars/eclipse-ui-3.0.0.jar will be mapped to MAVEN_REPO/eclipse/java-sources/eclipse-ui-3.0.0-sources.jar
For backward compatibility the plugin still accepts source archives located at MAVEN_REPO/${groupId}/src/${artifactId}-${version}.${maven.eclipse.src.extension} but it won't download them from the repository.
When Eclipse is not generating source code for you there is a conflict between Maven generating the source code and then Eclipse treating it as compiled code. Typically when generating code using Maven the code ends up in the target/classes directory. This is fine as long as Maven is doing the build. However, if Eclipse is then setup to do the build, when Eclipse performs a clean build all the generated code in target/classes will be removed.
The alternatives typically are to place the generated code in the /src/java directory and allow Maven and Eclipse to treat it the same. However, this leads to a tendency to check generated code into source control, which typically is not appropriate for generated code. Alternatively, it can be placed in some sort of /src/generated or target/generated directory. In Maven2, generated code lives in target/generated-sources, in a manner similiar to generated xdoc's live in target/generated-xdocs. Within the target/generated-sources would be each type of generated code.
By default, the plugin will load as seperate source folders any directory found in ${maven.build.dir}/generated-sources. So, if you generate your mock objects into ${maven.build.dir}/generated-sources/mocks and your wsdl classes into ${maven.build.dir}/generated-sources/wsdl then each of these directories will be mounted as source folders. Note: You must have already created these directories, otherwise the plugin won't know to add them as source folders. Before running maven eclipse just ensure you have already generated all of your source code.
For example, if you used the XDoclet Plugin for Maven to generate Hibernate mapping files, they would be placed in /target/generated-sources/xdoclet/. While, if you used the Hibernate Plugin for Maven to generate the SQL scripts for generating a database then that would be placed in /target/generated-sources/schema/.
Settings in project.properties:
maven.xdoclet.hibernatedoclet.destDir=${maven.build.dir}/generated-sources/xdoclet
maven.hibernate.output.dir=${maven.build.dir}/generated-sources/schema
If you use Eclipse, you may already have encountered the Infamous Layout Issue: Eclipse doesn't handle (yet ?) overlapping projects. Thus if you work in a multiproject context with a classical non flat layout, Eclipse integration becomes quite problematic. You surely don't want to use one big Eclipse project because you'll then lose visibility on dependencies (inter-project dependencies as well as library dependencies) and this will quickly become quite hard to manage - and promotes cycles.
Best solution found so far is to refactor your project structure to rather use a flat layout, as described below:
/project-root | /project-root
+- subproject1 | +- project.xml
+- project.xml ===> /subproject1
+- subproject2 | +- project.xml
+- project.xml | /subproject2
+- project.xml | +- project.xml
And alter your properties in a similar way than the example below:
maven.multiproject.basedir=${basedir}/..
maven.multiproject.includes=*/project.xml
maven.multiproject.excludes=project-root/project.xml
If you really can't (or don't want to) flatten your layout, the only solutions that are offered to you are a few tricks, each with its own drawback.
Use those tricks at your own risk
if this issue really annoys you, then please vote for https://bugs.eclipse.org/bugs/show_bug.cgi?id=35973
To specify the version of WTP configuration files, set the property maven.eclipse.wtp.version .
To activate WTP you have to set the property maven.eclipse.wtp.enable to true.