pkozelka / contentcheck-maven-plugin Goto Github PK

It could be also useful to have an option to check that an archive contains duplicated files on different locations, i mean especially JARs on different locations.

stacktrace:

java.lang.NullPointerException
    at net.kozelka.contentcheck.mojo.ContentCheckMojo.doExecute(ContentCheckMojo.java:58)
    at net.kozelka.contentcheck.mojo.AbstractArchiveContentMojo.execute(AbstractArchiveContentMojo.java:75)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
    ... 20 more

useful for

• preparing modules for package sealing
• detect and eliminate classpath problems caused by carelessly added dependencies

expected features:

• should fail after detecting (and logging) all problems
• log output should make it clear in which order the conflicting resources appear on classpath
• configurable behavior - some classes are intentionally duplicated on classpath
• by default, seek conflicts only for "*/.class" resources (because other resources are often designed to appear multiple times)
• by default, any conflict should fail the build - but this behavior must be configurable

implementation considerations:

• when used on many modules, the content of many dependencies would be searched again and again even if unchanged
• therefore it seems to make sense to cache the data in a (configurable) shared location, by default something like ${user.home}/.m2/something
• an embedded database (hsqldb, h2database, derby, ...) might be a good mean for such storage
• remember to support concurrent access to the storage

such a functionality can be generally useful.
Right now my use-case is to skip checking when used in clover-enabled build; that causes clover.jar to be included in the war.
The dirty workarround is to add clover.jar as approved, but the skip would allow keeping the approval list clean.

Another solution to my case could be to maintain a "devel-ignore" list; it would allow to ignore some files when building snapshot, but for release build, they will cause failure.

Use either MD5 or SHA1 hash to check integrity of the included files.
This can discover differences caused by improper modifications in nexus caches (or others).

this might be useful for use in projects consisting of microservices, where teams with independent codebase wish to keep their thirdparty dependencies as similar as possible.
One of motivations behind this can be a lengthy corporate procedure for approving thirdparty software.

it is ok to work with maven model classes outside, but using log or other pieces of plugin api prevents good structuring of the code in minimalistic dependencies in mind.
Think about targeting ant, cli, and other hosting platforms.

Currently, the conflict checker ignores the fact that the war file itself can contain classes that may potentially conflict with those in jar files.

On implementation side, this will require storing more information about a resource:

• its location in the containing archive (which, for war files, is prepended by WEB-INF/classes/)
• location to match against others, to see the conflict (simply without the prefix)

currently the only way how to tolerate some files with conflict is to specify number of allowed conflicts.

This is insufficient, and in teams with weaker code review habits it does not work in a way allowing step-by-step conflict reduction.

Adding a way to explicitly list which conflicts to allow might slightly help in such situation.

just to make the results easier to share and/or further process

how it should work:

• pom.xml will package all project dependencies into a zip, with antrun fragment attached to phase "process-test-classes" (to make testcompilation fail fast)
• one of junit tests will use this zip with one or more content listing resources to perform checks

In result, this will:

• allow us to use quite a big zip in unittests, without having to commit a big binary
• keep control on dependency graph of the plugin itself - not exactly important but stylish ;)

it should be based on existing output artifact and plugin configuration already present in pom.xml

... which could be a dedicated github repo for easier collaboration and sharing

Stacktrace:

Caused by: java.lang.NullPointerException
    at net.kozelka.contentcheck.introspection.AbstractIntrospector.checkArchiveManifest(AbstractIntrospector.java:163)
    at net.kozelka.contentcheck.introspection.AbstractIntrospector.isVendorArchive(AbstractIntrospector.java:143)
    at net.kozelka.contentcheck.introspection.AbstractIntrospector.readEntries(AbstractIntrospector.java:72)
    at net.kozelka.contentcheck.mojo.ContentListingGeneratorMojo.doExecute(ContentListingGeneratorMojo.java:36)
    at net.kozelka.contentcheck.mojo.AbstractArchiveContentMojo.execute(AbstractArchiveContentMojo.java:75)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
    ... 20 more

In such case, it would be useful to leave a copy in file target/contentcheck-maven-plugin/approved-content.txt

The command

mvn contentcheck:generate -DignoreVendorArchives=true

still adds SNAPSHOTs of the same projects

A conflict is just a duplicate when conflicting classes are exactly the same. This indicates that a component (somewhere in the dependency graph) has unclean design or build, but is quite harmless in runtime.

A conflict is serious when conflicting classes (or resources in general) are different. Then the order within classloader decides which one will be effective, and that order is frequently not reliable.

Serious conflicts - as defined here - increase risk of non-reproducible behavior.

Now it is not possible to properly control which project modules get into the webapp.
This is because their filename typically contains the "-SNAPSHOT" suffix, which changes during release.

This could be solved by inventing a special syntax, perhaps like

.module groupId:artifactId:classifier:type

which does not need changing with version changes.

This of course relies on availability of matching data in container JAR's manifest, or maven property files.