code-distillery / baselining-maven-plugin Goto Github PK

We have a global parent pom project that contains the configuration (checkstyle, licensing, etc) (everit-maven-main on Github, org.everit.config.main on Maven Central) of our maven based projects. We would like to add the baselining-maven-plugin with following configration to it:

      <plugin>
        <groupId>net.distilledcode.maven</groupId>
        <artifactId>baselining-maven-plugin</artifactId>
        <version>1.0.4</version>
        <executions>
          <execution>
            <id>baseline</id>
            <goals>
              <goal>baseline</goal>
            </goals>
            <configuration>
              <explain>true</explain>
            </configuration>
          </execution>
        </executions>
      </plugin>

The build of this parent pom project fails with a NullPointerException:

Caused by: java.lang.NullPointerException
    at net.distilledcode.maven.baselining.BaselineMojo.isBundle(BaselineMojo.java:253)
    at net.distilledcode.maven.baselining.BaselineMojo.execute(BaselineMojo.java:128)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)

The artifact.getFile() method returns null for pom packaging and that causes the NPE.

I haven tried to fix this issue (return false in the isBundle() method if the artifactFile == null) and send a pull request, but I don't understand something. Why the plugin continues its execution if the isBundle() method returns false?

        if (isBundle(artifact.getFile())) {
            getLog().debug("Execution skipped, artifact is not a jar file.");
            return;
        }

In my understanding thats the case where the execution should be skipped.

My fix is not working obviously because the artifact.getFile() is also used when the baseline() method invoked and that causes another NPE:

Caused by: java.lang.NullPointerException
    at aQute.bnd.osgi.Jar.getName(Jar.java:80)
    at aQute.bnd.osgi.Jar.<init>(Jar.java:70)
    at net.distilledcode.maven.baselining.BaselineMojo.baseline(BaselineMojo.java:369)
    at net.distilledcode.maven.baselining.BaselineMojo.execute(BaselineMojo.java:153)

Please help me to clarify this issue. Thanks!

If I try to compile the plugin with Java 5 I get errors due to the @OverRide on the execute method in the BaselineMojo. Please explicitly set the Java version to 6 in the pom.xml to make that work. Compare also with http://stackoverflow.com/questions/1005898/java-should-i-add-an-override-annotation-when-implementing-abstract-methods.

The default phase currently is "package". This phase is only responsible for creating the binary output (jar, war, etc.) but not check its quality.

The verify phase has the following definition: run any checks to verify the package is valid and meets quality criteria.

I think this is the phase where baselining plugin should run by default.

Another reason:

Some tools might want to execute (IDE plugins) the package phase skipping the test phase to deploy the binary output to a development server, where the developer can test the changes. Checking the version of the binary at this phase slows down this procedure.

In case the version was raised against the baseline without any API changes, the plugin outputs something like:

Please raise the version of package org.test.api.consumer to 1.0.0

This is a littlebit confusing, because there was no need to raise the version and still this was done. It would be great if in those cases the error message would rather say something like

Raising the version of of package org.test.api.consumer to 2.0.0 was not justified, because it is API compatible with 1.0.0

If a bundle got deleted completely the baseline plugin fails with a NullPointerException.

Unexpected exception during mojo execution
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Unexpected exception during mojo execution
at net.distilledcode.maven.baselining.BaselineMojo.execute(BaselineMojo.java:180)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.NullPointerException
at aQute.bnd.version.Version.compareTo(Version.java:83)
at net.distilledcode.maven.baselining.BaselineMojo.reportFindings(BaselineMojo.java:199)
at net.distilledcode.maven.baselining.BaselineMojo.execute(BaselineMojo.java:175)
... 21 more

The Info element with the Set returned by baseline.getPackageInfos() contains a null value in suggestedVersion.

Sometimes it may be useful to exclude certain java packages from being checked, e.g. when re-packaging another library it makes sense to keep the original version information, even if that may not be correct according to semantic versioning principles.

Support for both whitelists, via "includes", and blacklists, via "excludes" may be desirable.

To better understand why an exported package's version needs to be raised, it would be helpful to get a list of the relevant API changes.

With such a list of changes it would be easier to manage API versions e.g. by delaying changes that require a major version increment or by refactoring the changes to have less impact on the API.