Cycle dependency among packages

[sadovnikov]

Adding NoPackageCyclesEnforcerRule to maven-enforcer-plugin highlights presence of a cycle dependency among the packages.
This disables applying the same enforcer rule to, for example, projects of IDE or build server plugins, where classes of "compile" dependencies, including plexus-utils, get baked into the build artifact

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <version>1.1.1</version>
        <dependencies>
          <dependency>
            <groupId>org.apache.ws.commons.axiom</groupId>
            <artifactId>no-package-cycles-enforcer-rule</artifactId>
            <version>1.2.20</version>
          </dependency>
        </dependencies>
        <executions>
          <execution>
            <id>enforce-no-package-cycles</id>
            <goals>
              <goal>enforce</goal>
            </goals>
            <phase>test</phase>
            <configuration>
              <rules>
                <NoPackageCyclesRule implementation="org.apache.axiom.buildutils.enforcer.NoPackageCyclesEnforcerRule"/>
              </rules>
            </configuration>
          </execution>
        </executions>
      </plugin>

[WARNING] Rule 0: org.apache.axiom.buildutils.enforcer.NoPackageCyclesEnforcerRule failed with message:
Package cycle detected. Classes involved:
  org.codehaus.plexus.util.xml.pull.MXParser -> org.codehaus.plexus.util.ReaderFactory
  org.codehaus.plexus.util.xml.pull.MXParser -> org.codehaus.plexus.util.xml.XmlStreamReader
  org.codehaus.plexus.util.xml.PrettyPrintXMLWriter -> org.codehaus.plexus.util.StringUtils
  org.codehaus.plexus.util.xml.SerializerXMLWriter -> org.codehaus.plexus.util.xml.pull.XmlSerializer
  org.codehaus.plexus.util.ReaderFactory -> org.codehaus.plexus.util.xml.XmlStreamReader

[rfscholte]

I think this is an issue with the NoPackageCyclesRule. It should not verify cycles within plugins, but only on your project, at least I hope so.

[sadovnikov]

I fully appreciate unusualness of the situation with plugins, where *.class files of their "compile" dependencies have to be placed into the plugin *.jar. NoPackageCyclesRule analyzes classes in "test" phase of the build, gets all *.class files and, unfortunately, it does provide a way to define packages to check.

I'll try to suggest PR to resolve the cycle in pluxus-util. However, even if accepted, it will take very long before new version starts being used through transitive dependencies. I have to write my own version of NoPackageCyclesRule anyway.