Merge branch 'scijava-packages-rules'

This introduces an adapted version of the
no-package-cycles-enforcer-rule project, plus a new
NoSubpackageDependenceRule to foster healthy package dependencies.

There are still some loose ends, but it's a functional starting point.

Please note: this is a rather evil merge; sorry about that. But it
was the easiest way forward while abiding by SciJava's release-ready
integration branch rule (compiles with passing tests).

Author: ctrueden

.gitignore

@@ -1,5 +1,5 @@
 /.classpath
+/.idea/
 /.project
 /.settings/
 /target/
-*.swp

NOTICE.txt

@@ -1,3 +1,23 @@
+========================================================================
+Portions of this project were adapted from no-package-cycles-enforcer-rule:
+https://github.com/andrena/no-package-cycles-enforcer-rule
+
+Copyright 2013 - 2018 David Burkhart, Ben Romberg, Daniel Galan y Martins,
+Bastian Feigl, Marc Philipp, and Carsten Otto.
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+========================================================================
+
 This project contains files under the Apache 2.0 license, as follows:
 
 

README.md

@@ -111,3 +111,123 @@ Alternatively, you can include the plugin explicitly in the life cycle:
   </plugin>
 </plugins>
 ```
+
+SciJava Packages Rules
+====================
+
+scijava-packages-rules provides a set of [Maven Enforcer Plugin](https://maven.apache.org/enforcer/maven-enforcer-plugin/) rules for policing the package hierarchy at build time.
+
+## Usage
+
+Currently, the only way to utilize these rules is by explicitly declaring it in the life cycle
+
+```xml
+<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>
+```
+
+Rules
+====================
+
+# No Package Cycles
+[Circular dependencies](https://en.wikipedia.org/wiki/Circular_dependency) are usually considered poor practice. To prevent circular dependencies, add the following `execution`:
+
+```xml
+<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>
+```
+
+### Including test classes
+
+If you want to exclude tests from cycle checking, you can use the parameter `includeTests` which is set to true by default:
+
+```xml
+        ...
+        <rules>
+            <NoPackageCyclesRule implementation="org.scijava.packages.rules.NoPackageCyclesRule">
+                <includeTests>false</includeTests>
+            </NoPackageCyclesRule>
+        </rules>
+        ...
+```
+
+### Restricting scope
+
+**:warning: Only use this, if there is no other way! Once there are exceptions, the connection between those excluded packages
+will grow stronger and stronger, without notice!**
+
+If you want to exclude packages or restrict check to certain packages only, you can use `includedPackages` or `excludedPackages` (although you really should not!):
+
+```xml
+        ...
+        <rules>
+            <NoPackageCyclesRule implementation="org.scijava.packages.rules.NoPackageCyclesRule">
+                <includedPackages>
+                    <includedPackage>myapp.code.good</includedPackage>
+                </includedPackages>
+            </NoPackageCyclesRule>
+        </rules>
+        ...
+```
+
+```xml
+        ...
+        <rules>
+            <NoPackageCyclesRule implementation="de.andrena.tools.nopackagecycles.NoPackageCyclesRule">
+                <excludedPackages>
+                    <excludedPackage>myapp.code.bad</excludedPackage>
+                </excludedPackages>
+            </NoPackageCyclesRule>
+        </rules>
+        ...
+```
+
+
+# No Subpackage Dependence
+Subpackage Dependence can throw a wrench into libraries wishing to follow the [Dependency Inversion principle](https://en.wikipedia.org/wiki/Dependency_inversion_principle). To prevent subpackage dependence, add the following `execution`:
+
+```xml
+<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>
+```
+
+
+## See also
+
+* The original version by Daniel Seidewitz on [Stackoverflow](http://stackoverflow.com/questions/3416547/maven-jdepend-fail-build-with-cycles). Improved by showing all packages afflicted with cycles and the corresponding classes importing the conflicting packages; this version was written [here](https://github.com/andrena/no-package-cycles-enforcer-rule). From there, the SciJava team made the behavior more extensible, making it easier to write and use more package-based rules.
+* [JDepend](https://github.com/clarkware/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)](http://www.objectmentor.com/resources/articles/granularity.pdf). 
+* The [Maven Enforcer Plugin](https://maven.apache.org/enforcer/maven-enforcer-plugin/)