NullPointerException attempting to convert large maven pom to gradle


(Tyler Thrailkill) #1

I’m attempting to begin using gradle by converting an existing pom using the gradle init tool, but I’m receiving an NPE. Here is the output of gradle init --stacktrace --debug.

https://pastebin.com/c4C8ruVh (I am a new user so I can’t upload, and this is way longer than the length limit allows. )

I can’t provide the source since we are closed, source, but I can say we’re using a BOM. What steps should I take to figure out what is causing the NPE? WIll I just have to convert the pom by hand? I’m completely new to gradle so I’m not sure where to start.


(uklance) #2

I’m not sure how to fix the NPE but a possible workaround is to generate an effective pom via the help:effective-pom mojo and then run gradle init on the effective pom.

This should “denormalise” any <dependencyManagement> declarations in your poms which you suspected might be causing the NPE

Eg: mvn help:effective-pom -Doutput=effective-pom.xml

For a multi-module maven build there might be an extra step to split the single effective pom xml file into one per module prior to running gradle init (effective-pom will nest <project> within <projects> in this case)


(Tyler Thrailkill) #3

Dang, it is a multi-module maven project so I got the effective pom, pulled out the different projects and pasted them into their respective existing pom (i’m seeing problems with reportPlugins but I’m ignoring those) but when I run gradle init I still get the NPE error. :persevere:


(uklance) #4

Sorry if my suggestion wasted your time… was worth a try :wink:


(Tyler Thrailkill) #5

wasn’t a waste. Learning more about gradle the more I try to get this working so.


(Benjamin Muschko) #6

From the log it looks like /Users/tylerthrailkill/Documents/dev/code/server/pom.xml is the problem. Maybe you can remove portions of it to isolate the issue.


(Tyler Thrailkill) #7

Hmm. That’s the parent pom, so if I remove parts of it, it might break the submodules… But I will try that!


(Tyler Thrailkill) #8

@Lance @bmuschko Got it to work! The solution was a combination of your two suggestions. Convert project to effective pom, replacing each pom with their respective from the effective pom. Then I kept getting the NPE, so I just kept removing parts of a single pom until it worked.

Turns out that the effective pom kept a reference to the parent pom and so it was always breaking looking for the parent pom. Not sure why it was an NPE, but I was successfully able to convert most of the pom over to gradle!
Thanks guys!


(Benjamin Muschko) #9

Glad to hear that. I think it would still be great if we could identify why the Gradle code was failing specifically. Do you think you could put together a simplistic example that produces the issue? Also, if you feel super ambitious I’d welcome a fix for this issue so other users don’t run into the same problem.


(Tyler Thrailkill) #10

whoo. i can try to put together an example. A fix I’m entirely unsure of. Like I said, I’m brand new to gradle, but I can always try! :smiley:


(uklance) #11

You could simply remove <parent> from the effective pom if that’s causing issues. Effective pom duplicates anything in the parent pom in its children so it’s redundant


(Tyler Thrailkill) #12

yes that was the solution. sorry if that wasn’t clear.


(Tyler Thrailkill) #13

@bmuschko alright here is a working example of the bug. should I make a github issue?



(uklance) #14

In your sample project, it’s referencing a parent that doesn’t exist in the project. I’m guessing this comes from a maven repository?

Possibly the gradle init plugin can’t access this parent pom because it’s not available via gradle APIs?

See https://github.com/gradle/gradle/issues/2809


(Tyler Thrailkill) #15

that does sound similar to the problem. From what I understood, gradle would look at the m2 settings.xml to find the repositories to look in. ideally it would see that parent pom in the local repository and be able to use it. If anything the error message needs to be improved.


(uklance) #16

Just a wild guess, but I think it’ll work without effective pom if you set the <relativePath> in each <parent>

Eg:

    <parent>
        <groupId>com.gradleiniterror</groupId>
        <artifactId>parent</artifactId>
        <version>1.0-SNAPSHOT</version>
        <relativePath>../../path/to/parent</relativePath>
    </parent>

(Tyler Thrailkill) #17

you mean just to use gradle init right? Because we do need the parent in nexus/artifactory, so a relative path isn’t a solution to the problem.


(uklance) #18

Yep, just for Gradle init. You’re ditching the maven build I assume so it doesn’t matter.


(Tyler Thrailkill) #19

I’m attempting to test gradle build times against our current maven build times to see whether it’s feasible to switch. I was hoping to use nebula dependency recommender to continue to have a BOM.


(uklance) #20

FWIW I’m currently working on a gradle plugin which invokes mvn help:effective-pom at build time then uses a freemarker template to generate gradle files which are then applied. It’s all dynamic and only runs on-demand (ie if maven poms change).

In theory you can run gradle and maven builds in parallel until you switch to gradle by copy/pasting the dynamically generated gradle files into your build.gradle and ditch maven for ever!

If you wanted to generate nebula dependency recommender code from maven poms it’d likely work with a custom freemarker template.

I’ll post back here when I’ve got something worth sharing if you’re interested