scijava-maven-plugin is a Maven plugin for managing SciJava-based software.
$ mvn scijava:help
[INFO] SciJava plugin for Maven 1.1.0
A plugin for managing SciJava-based projects.
This plugin has 7 goals:
scijava:bump
Bumps dependency and parent versions in SciJava projects.
scijava:populate-app
Copies .jar artifacts and their dependencies into a SciJava application
directory structure. ImageJ 1.x plugins (identified by containing a
plugins.config file) get copied to the plugins/ subdirectory and all other
.jar files to jars/. However, you can override this decision by setting the
scijava.app.subdirectory property to a specific subdirectory. It expects the
location of the SciJava application directory to be specified in the
scijava.app.directory property (which can be set on the Maven command-line).
If said property is not set, the populate-app goal is skipped.
scijava:eclipse-helper
Runs the annotation processor of the scijava-common artifact even inside
Eclipse.
scijava:help
Display help information on scijava-maven-plugin.
Call mvn scijava:help -Ddetail=true -Dgoal=<goal-name> to display parameter
details.
scijava:install-artifact
Downloads .jar artifacts and their dependencies into a SciJava application
directory structure. ImageJ 1.x plugins (identified by containing a
plugins.config file) get copied to the plugins/ subdirectory and all other
.jar files to jars/. However, you can override this decision by setting the
scijava.app.subdirectory property to a specific subdirectory. It expects the
location of the SciJava application directory to be specified in the
scijava.app.directory property (which can be set on the Maven command-line).
If said property is not set, the install-artifact goal is skipped.
scijava:set-rootdir
Sets the project.rootdir property to the top-level directory of the current
Maven project structure.
scijava:verify-no-snapshots
Mojo wrapper for the SnapshotFinder.
Parameters:
- failFast - end execution after first failure (default: false)
- groupIds - an inclusive list of groupIds. Errors will only be reported for
projects whose groupIds are contained this list. (default: empty - all
groupIds considered)
- groupId - Singular groupIds option. Will be appended to groupIds if both are
specified.It is recommended to enable the set-rootdir as well as the populate-app goal by making the SciJava POM the parent project:
<project ...>
<parent>
<groupId>org.scijava</groupId>
<artifactId>pom-scijava</artifactId>
<version>7.5.2</version>
</parent>
...
</project>Alternatively, you can include the plugin explicitly in the life cycle:
<plugins>
<!-- Set the rootdir property to the root of the multi-module project -->
<plugin>
<groupId>org.scijava</groupId>
<artifactId>scijava-maven-plugin</artifactId>
<version>0.1.0</version>
<executions>
<execution>
<id>set-rootdir</id>
<phase>validate</phase>
<goals>
<goal>set-rootdir</goal>
</goals>
</execution>
<execution>
<id>populate-app</id>
<phase>install</phase>
<goals>
<goal>populate-app</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>scijava-packages-rules provides a set of Maven Enforcer Plugin rules for policing the package hierarchy at build time.
Currently, the only way to utilize these rules is by explicitly declaring it in the life cycle
<plugin>
<artifactId>maven-enforcer-plugin</artifactId>
<dependencies>
<dependency>
<groupId>org.scijava</groupId>
<artifactId>scijava-packages-rules</artifactId>
<version>0-SNAPSHOT</version>
</dependency>
</dependencies>
<executions>
...
</executions>
</plugin>Circular dependencies are usually considered poor practice. To prevent circular dependencies, add the following execution:
<execution>
<id>enforce-no-package-cycles</id>
<goals>
<goal>enforce</goal>
</goals>
<phase>test</phase>
<configuration>
<rules>
<NoPackageCyclesRule
implementation="org.scijava.packages.rules.NoPackageCyclesRule" />
</rules>
</configuration>
</execution>If you want to exclude tests from cycle checking, you can use the parameter includeTests which is set to true by default:
...
<rules>
<NoPackageCyclesRule implementation="org.scijava.packages.rules.NoPackageCyclesRule">
<includeTests>false</includeTests>
</NoPackageCyclesRule>
</rules>
...If you want to exclude packages or restrict check to certain packages only, you can use includedPackages or excludedPackages (although you really should not!):
...
<rules>
<NoPackageCyclesRule implementation="org.scijava.packages.rules.NoPackageCyclesRule">
<includedPackages>
<includedPackage>myapp.code.good</includedPackage>
</includedPackages>
</NoPackageCyclesRule>
</rules>
... ...
<rules>
<NoPackageCyclesRule implementation="de.andrena.tools.nopackagecycles.NoPackageCyclesRule">
<excludedPackages>
<excludedPackage>myapp.code.bad</excludedPackage>
</excludedPackages>
</NoPackageCyclesRule>
</rules>
...Subpackage Dependence can throw a wrench into libraries wishing to follow the Dependency Inversion principle. To prevent subpackage dependence, add the following execution:
<execution>
<id>enforce-no-subpackage-dependence</id>
<goals>
<goal>enforce</goal>
</goals>
<phase>test</phase>
<configuration>
<rules>
<NoSubpackageDependenceRule
implementation="org.scijava.packages.rules.NoSubpackageDependenceRule" />
</rules>
</configuration>
</execution>- The original version by Daniel Seidewitz on Stackoverflow. Improved by showing all packages afflicted with cycles and the corresponding classes importing the conflicting packages; this version was written here. From there, the SciJava team made the behavior more extensible, making it easier to write and use more package-based rules.
- JDepend, the library being used to detect package cycles.
- For more information about package cycles, see "The Acyclic Dependencies Principle" by Robert C. Martin (Page 6).
- The Maven Enforcer Plugin