rackerlabs / gradle-jaxb-plugin

Gradle plugin to ease projects that use xsds and the ant jaxb task
GNU General Public License v2.0
34 stars 21 forks source link

Cannot get property 'managedNodes' on null objects #38

Closed felixgao closed 6 years ago

felixgao commented 6 years ago

Trying to use the jaxb plugin and my xsd file is located at src/main/resources/schema/axml.xsd

The interesting part of the gradle file is the following

dependencies {
    //####################### XJC - JDK 1.7/1.8 ####################
    jaxb 'com.sun.xml.bind:jaxb-xjc:2.2.7-b41'
    jaxb 'com.sun.xml.bind:jaxb-impl:2.2.7-b41'
    jaxb 'javax.xml.bind:jaxb-api:2.2.7'
    jaxb 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.6.5'

    compile "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version"
    testCompile group: 'junit', name: 'junit', version: '4.12'
}
def generatedSrcDir = '${project.buildDir}/generated-sources'
//####################### XJC - JDK 1.7/1.8 ####################
jaxb {
    xsdDir = "src/main/resources/schema"

    xjc {
        generateEpisodeFiles = false
        taskClassname        = "org.jvnet.jaxb2_commons.xjc.XJC2Task"
        generatePackage      = "com.example.bizapps.service.osb.generated.schema"
        args                 = ["-Xinheritance", "-Xannotate"]
        destinationDir       = generatedSrcDir
    }
}

sourceSets {
    generated {
        java {
            srcDirs += generatedSrcDir
        }
    }
    main {
        java {
            compileClasspath += generated.output
            runtimeClasspath += generated.output
        }
        output.dir(sourceSets.generated.output.classesDir, builtBy: 'compileGeneratedJava')
    }
}

compileJava.dependsOn xjc

./gradlew --version

------------------------------------------------------------
Gradle 4.4
------------------------------------------------------------

Build time:   2017-12-06 09:05:06 UTC
Revision:     cf7821a6f79f8e2a598df21780e3ff7ce8db2b82

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

when I run ./gradlew --stacktrace :xjc

Caused by: java.lang.NullPointerException: Cannot get property 'managedNodes' on null object
        at org.openrepose.gradle.plugins.jaxb.task.JaxbXjc.start(JaxbXjc.groovy:104)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:46)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:39)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:26)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:780)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:747)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:121)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:110)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:92)
        ... 29 more

Not sure what it is actually looking for since the doc does not mention anything regarding the 'managedNodes' property.

radimk commented 6 years ago

Same problem here. My log shows something like this

> Task :xsd-dependency-tree UP-TO-DATE
> Task :xjc FAILED

XajbXjc.manager field is mapped to use project.jaxb.dependencyGraph but that one is only set from xsd-dependency-tree action execution. But if that preceding task is UP-TO-DATE it is left with null and xjc fails.

henri-tremblay commented 6 years ago

Felt on the same issue. No workaround right?

rorshachdb commented 6 years ago

Same for me when using --info to get more clues about what's going on I can see that the plugin is looking for schemas in the default xsdDir path rather than my custom "src/main/schemas"

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.

wdschei commented 6 years ago

This is a duplicate of #36 .

eekboom commented 6 years ago

The up-to-date checks are greatly welcomed. In 2.4 gradle always executed some tasks even if there really should have been nothing to do. 2.5 now correctly says everything is up-to-date on a second build invocation. However we are also bitten by this issue - at least I guess so: The error for us is "Cannot get property 'treeRoot' on null object" (which has been mentioned in relation to this bug at https://github.com/rackerlabs/gradle-jaxb-plugin/issues/36).

Will there be a 2.5.1 sometimes soon?

wdschei commented 6 years ago

@eekboom 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.

ghilainm commented 5 years ago

@wdschei Why is this closed if this is not fixed? Pain is super high for us. The XSD generation project is super slow and failure in another component makes rebuilding the project fail on XSD generation part with this error. We are forced to do gradle clean and rebuild the complete project to solve the issue.

wdschei commented 5 years ago

@ghilainm It is a duplicate.