NPE while run with default values

[demtnt]

${project.projectDir}/build.gradle

`buildscript {
dependencies {
classpath 'gradle.plugin.org.openrepose:gradle-jaxb-plugin:2.5.0'
}
}

plugins {
id 'org.openrepose.gradle.plugins.jaxb' version '2.5.0'
}

group 'com.example'
version '1.0-SNAPSHOT'

apply plugin: 'java'

sourceCompatibility = 1.8

repositories {
mavenCentral()
}

dependencies {

}

jaxb {
xsdDir = "${project.projectDir}/src/main/resources/schema"
xjc {
}
}`

${project.projectDir}/src/main/resources/schema/example.xsd
`
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="aaa.bbb.ccc"

<xs:element name="shiporder">
    <xs:complexType>
        <xs:sequence>
            <xs:element name="orderperson" type="xs:string"/>
            <xs:element name="shipto">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="name" type="xs:string"/>
                        <xs:element name="address" type="xs:string"/>
                        <xs:element name="city" type="xs:string"/>
                        <xs:element name="country" type="xs:string"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
            <xs:element name="item" maxOccurs="unbounded">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="title" type="xs:string"/>
                        <xs:element name="note" type="xs:string" minOccurs="0"/>
                        <xs:element name="quantity" type="xs:positiveInteger"/>
                        <xs:element name="price" type="xs:decimal"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
        </xs:sequence>
        <xs:attribute name="orderid" type="xs:string" use="required"/>
    </xs:complexType>
</xs:element>

</xs:schema>`

Administrators-MacBook-Pro-3:artifid User$ ./gradlew --version

---

Gradle 4.6

Build time: 2018-02-28 13:36:36 UTC
Revision: 8fa6ce7945b640e6168488e4417f9bb96e4ab46c

Groovy: 2.4.12
Ant: Apache Ant(TM) version 1.9.9 compiled on February 2 2017
JVM: 1.8.0_141 (Oracle Corporation 25.141-b15)
OS: Mac OS X 10.13.4 x86_64

Administrators-MacBook-Pro-3:artifid User$ java -version
java version "1.8.0_141"
Java(TM) SE Runtime Environment (build 1.8.0_141-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.141-b15, mixed mode)

Administrators-MacBook-Pro-3:artifid User$ ./gradlew xjc --stacktrace

FAILURE: Build failed with an exception.

• What went wrong:
  Execution failed for task ':xjc'.

Cannot get property 'managedNodes' on null object

• Try:
  Run with --info or --debug option to get more log output. Run with --scan to get full insights.

• Exception is:
  org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':xjc'.
  at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:103)
  at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:73)

It is looks like
def manager = getManager()
was not created in file org.openrepose.gradle.plugins.jaxb.task.JaxbXjc

[demtnt]

It is turns out there is no problem in 2.4.1 version

[NodonDarkeye]

Whenever I'm using binding files I'm now getting a NPE on manager:

    def manager = getManager()
    if (!getBindings().isEmpty()) {
      // have bindings, can't use Node processing, one xjc run and exit
      log.info("bindings are present, running ant xjc task on all xsds in '{}' and then exiting!", getSchemasDirectory())
      def namespace = manager.treeRoot.pop().data.namespace ?: "random-namespace"
      xjc(getXsds(), [], getEpisodeFile(namespace))
      return
    }

I'm getting the exeption "Cannot get property 'treeRoot' on null object" which leads me to think manager is null in this case. I've also tested with version 2.4.1 and I'm also not getting the error there.

[wdschei]

@NodonDarkeye

I created a Short, Self Contained, Correct (Compilable), Example / Minimal, Complete, and Verifiable example for #21 here:

• https://github.com/wdschei/gradle-jaxb-plugin_issue21

Can you submit a PR to that project that causes the issue you describe to occur?

[ben-manes]

I am upgrading from 2.4.1 and also get the NPE

Caused by: java.lang.NullPointerException: Cannot get property 'treeRoot' on null object
        at org.codehaus.groovy.runtime.NullObject.getProperty(NullObject.java:60)
        at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:174)
        at org.codehaus.groovy.runtime.callsite.NullCallSite.getProperty(NullCallSite.java:47)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:296)
        at org.openrepose.gradle.plugins.jaxb.task.JaxbXjc.start(JaxbXjc.groovy:98)

[NodonDarkeye]

@wdschei I've had a busy week, I'll try to get something together in the weekend

[tkruse]

Gradle 4.1-4.5 and jaxb-plugin 2.5.0, also getting Cannot get property 'managedNodes' on null object. 2.4.1 still works (also with gradle 4.x).

Gradle 4.7 and jaxb-plugin 2.5.0 works for me.

Deleting files in .gradle/<gradle-version> also worked for me

Trying to reproduce how those got messed up would take a while.

The changelog shows many changes from 2.4.1 to 2.5, but the actual code diff of plugin source files is rather small, and nothing seems to justify a new NPE when using 2.4.1 vs. 2.5.0 on the same gradle 4.5.1 version (the change of groovy version may be more relevant).

Trying to reproduce the problem, I found I could not, meaning I could not provide a simple example having the same problem. Eventually I copy/pasted my whole project folder with cp -r, but in the copy I could not reproduce the issue. So I finally deleted the file hashes in .gradle/ and the problem went away.

Bottom line: trying to reproduce this issue, make sure to delete those file hashes.

[wdschei]

@tkruse Glad you found us over here already.

So, are you saying that by deleting the files in the .gradle/<gradle-version> directory made the plugin work for you after experiencing an NPE?

[tkruse]

@wdschei yes, after the NPE encountered, I deleted the .gradle/<gradle-version>, and the NPE never came back. Before that, I had played around with different versions of this plugin and the original one from "jacobono", so I don't know what action caused what trouble there.

[wdschei]

@tkruse Glad to hear it is working for you.

To answer your other thought on the Gradle forums, we have looked at replacing this repo with a non-forked version. So far we have gotten the traction by publishing directly to the Gradle Plugin Portal and by folks looking at the issues and PR's on the original repo. We are still investigating how to make the transition without losing our current list of issues and the searchable PR accountability.

[wdschei]

@tkruse That turned out to be much easier than expected. We are now detached from the original repository that we had been forked from.

[TruthNZ]

Deleting the whole .gradle/ folder resolves the issue for the next build, until someone does a gradle clean. Then the NPE returns.

Deleting just the .gradle/<gradle-version>/ folder seems to resolve the issue, without gradle clean resetting it.

However you get the issue if you start a new project / checkout a new copy of a project. First build works, all builds after a gradle clean fail with a NPE, until you manually delete just the .gradle/<gradle-version>/.

[wdschei]

We have tracked down what is causing this and there will be a fix forthcoming. It basically boils down to the Inputs for the dependency tree task are not complete and the task is not always running when it needs to. This was introduced in during the updates to make the Up To Date checks work with Gradle 4.x. During our investigation, we decided there was no need for this to have ever been a separate task, so it will just be merged into the xjc task.

The short-term workaround is to perform a cleanXsd-dependency-tree anytime there is a modification to a schema or bindings file. This will force the dependency tree to be generated.

[scphantm]

i just ran into this one too. when are you expecting a new release?

[wdschei]

@scphantm This is a side project that we started maintaining since it was previously abandoned and PR's were just sitting. We do dogfood this plugin and have run into this issue occasionally. However, the the pain threshold has not been reached to force it to bubble to the top of our backlog. That said, I can't give you a good date for a bug fix release. Maybe during our 4'th quarter hack day.

We are more than happy to accept PR's if this is something you think you might want to tackle.

[scphantm]

What do you think is the fix, merge the two tasks together into one?

…

On Sep 5, 2018, at 10:42 AM, William Scheidegger ***@***.***> wrote: @scphantm This is a side project that we started maintaining since it was previously abandoned and PR's were just sitting. We do dogfood this plugin and have run into this issue occasionally. However, the the pain threshold has not been reached to force it to bubble to the top of our backlog. That said, I can't give you a good date for a bug fix release. Maybe during our 4'th quarter hack day. We are more than happy to accept PR's if this is something you think you might want to tackle. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[wdschei]

At this point we haven't given it much thought.

[scphantm]

Well, merging them is something I can probably do.

…

On Sep 6, 2018, at 9:20 AM, William Scheidegger ***@***.***> wrote: At this point we haven't given it much thought. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[shevek]

This triggered even without a change to the schema file, but on a gradle version update.

[shevek]

The workaround given doesn't work. Is there any other workaround, or is this dead?

[wdschei]

@shevek What have you tried?

[shevek]

It fails after a gradlew clean. We tried running cleanXsd-dependency-tree, but that didn't fix it. The only thing that works is deleting the whole of .gradle/ which really slows down the next build. Currently running gradle 4.10.3.

[wdschei]

@shevek Do you continue to get an NPE following the steps in:

#36 (comment)

[jmeierhofer]

Hi @wdschei
I also get this NPE and I found a way to reproduce and temporary fix the issue, like suggested from @TruthNZ

Setup

Gradle 5.3

plugins {
    id "org.openrepose.gradle.plugins.jaxb" version "2.5.0"
}

dependencies {
    jaxb 'org.glassfish.jaxb:jaxb-xjc:2.3.2'
    jaxb 'org.glassfish.jaxb:jaxb-runtime:2.3.2'
    compile("com.sun.xml.bind:jaxb-core:2.3.0.1")
    compile("com.sun.xml.bind:jaxb-impl:2.3.2")
}

Error example

./gradlew build -xtest -> WORKS
./gradlew clean -> WORKS
./gradlew build -xtest -> ERROR: Execution failed for task 'xjc' > Cannot get property 'managedNodes' on null object

Delete folder <my_project>/.gradle/5.3/executionHistory
./gradlew build -xtest -> WORKS
./gradlew build -xtest -> ERROR

Delete folder <my_project>/.gradle/5.3/executionHistory
./gradlew build -xtest -> WORKS
./gradlew build -xtest -> ERROR

A problem with this workaround is, that deleting the executionHistory folder slows down the build.

Working example

I don't know why, but this case is working fine. Seems like the build task from the error example somehow breaks the XJC.

./gradlew cleanXsd-dependency-tree cleanXjc xjc -> WORKS
./gradlew clean -> WORKS
./gradlew cleanXsd-dependency-tree cleanXjc xjc -> WORKS
./gradlew cleanXsd-dependency-tree cleanXjc xjc -> WORKS
./gradlew cleanXsd-dependency-tree cleanXjc xjc -> WORKS

[bjornvester]

A work-around that works for us, and doesn't include cleaning anything, has been to insert the following in the build.gradle file:

tasks.named("xsd-dependency-tree").configure {
    inputs.dir(xjc.bindings)
}

For us, it was caused by the fact that the xsd-dependency-tree task needs to run for the xjc task to work, but the xjc task has an additional up-to-date check on the bindings folder that the former doesn't have.

We don't use binding files at all, but it defaults to looking in the src/main/resources/schema folder, so any changes here will cause the xjc task to be rerun - even if you have a different xsdDir property configured. After we got aware of this, we also changed the bindingsDir property to point to a non-existing folder so it wouldn't cause unnecessary reruns as well.

[jmeierhofer]

@bjornvester
I can't get your suggestions to work properly. I tried:

• modifying the xsd-depdendency-tree inputs.dir
• changing the xjc bindingsDir to a non-existent folder
• both settings

Code extract

// XJC config
jaxb {
    xjc {
        xsdDir = "${project.projectDir}/src/main/resources"
        destinationDir = "${project.buildDir}/xjc-generated/java"
        episodesDir = "${project.buildDir}/xjc-generated/resources"
        args = ["-encoding", "UTF-8"]
        
        bindingsDir = "${project.projectDir}/empty_xjc"
    }
}
compileJava.dependsOn xjc

tasks.named("xsd-dependency-tree").configure {
    inputs.dir("${project.projectDir}/empty_xjc")
}

I am still getting the error:

Execution failed for task ':wcs-server:xjc'.
> Cannot get property 'managedNodes' on null object

[jmeierhofer]

I managed to find a workaround which works for my project, thanks to the input from @bjornvester:

tasks.named("xsd-dependency-tree").configure {
    outputs.upToDateWhen { false }
}

This will disable the incremental build feature completely for the XJC task, but it works without any exception. I am still interested in a real bugfix for this gradle-jaxb-plugin.

[eddurov]

on Gradle 6.5.1

plugins {
    id "org.openrepose.gradle.plugins.jaxb" version "2.5.0"
}

jaxb {
...
    xjc {
        ...
    }
}

dependencies {
    implementation 'javax.xml.bind:jaxb-api:2.3.1'
    implementation 'org.glassfish.jaxb:jaxb-runtime:2.3.1'
    jaxb 'org.glassfish.jaxb:jaxb-xjc:2.3.1'
    jaxb 'org.glassfish.jaxb:jaxb-runtime:2.3.1'
    xjc 'gradle.plugin.org.openrepose:gradle-jaxb-plugin:2.5.0'
    implementation 'gradle.plugin.org.openrepose:gradle-jaxb-plugin:2.5.0'
}

works correctly without any workarounds just by ./gradlew xjc