NPE while run with default values

demtnt commented 6 years ago

${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 `<?xml version="1.0" encoding="UTF-8" ?> <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 commented 6 years ago

It is turns out there is no problem in 2.4.1 version

NodonDarkeye commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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

tkruse commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

wdschei commented 6 years ago

@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 commented 6 years ago

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

On Sep 5, 2018, at 10:42 AM, William Scheidegger notifications@github.com 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 commented 6 years ago

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

scphantm commented 6 years ago

Well, merging them is something I can probably do.

On Sep 6, 2018, at 9:20 AM, William Scheidegger notifications@github.com 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 commented 5 years ago

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

shevek commented 5 years ago

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

wdschei commented 5 years ago

@shevek What have you tried?

shevek commented 5 years ago

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 commented 5 years ago

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

https://github.com/rackerlabs/gradle-jaxb-plugin/issues/36#issuecomment-391542718

jmeierhofer commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 3 years ago

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

rackerlabs / gradle-jaxb-plugin

NPE while run with default values #36

Gradle 4.6

Code extract