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> <NoPackageCyclesRuleimplementation="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> <NoPackageCyclesRuleimplementation="org.scijava.packages.rules.NoPackageCyclesRule"> <includedPackages> <includedPackage>myapp.code.good</includedPackage> </includedPackages> </NoPackageCyclesRule> </rules> ... ... <rules> <NoPackageCyclesRuleimplementation="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