Skip to content

Migrate to Gradle wrapper build #11

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wcmatthysen opened this issue Apr 10, 2019 · 14 comments
Closed

Migrate to Gradle wrapper build #11

wcmatthysen opened this issue Apr 10, 2019 · 14 comments
Labels
enhancement New feature or request
Milestone

Comments

@wcmatthysen
Copy link
Member

Migrated this issue from upstream originally logged by @pdavidc: NASAWorldWind#60

Migrate World Wind Java to a Gradle wrapper based build system. Gradle builds integrate fully with the IntelliJ IDE internal build system, eliminating the duplicity of separate IDE build and ANT build process.

@AndrewTasso
Copy link

AndrewTasso commented Apr 10, 2019

This would be a very large undertaking and would likely require some lines drawn in the sand in regards to certain features of WW that might not easily be carried forward (such as WebStart). That said, I'm going to take a peek at the repo and see what can be done. I'm short on personal time nowadays. So, at the very least, I'd like to provide some guidance.

@wcmatthysen
Copy link
Member Author

Great, thanks. Any help with regards to this would be very much appreciated. I think if we can at least just build the worldwind.jar and worldwindx.jar files then that would be a great start. Also, if we can let Gradle fetch the JOGL and Gluegen jars as external dependencies then that would be great too. We can leave the WebStart stuff for later (I think).

I think the main issue that we need to discuss is whether we are going to change the structure of the source folders to fit in with the recommended way of doing things (i.e. a src/main/java folder). That is probably going to be a bit of a disruptive change. I have managed to do it in my own fork of WorldWind back in the day (when I built it with Maven) but the problem is that it will make merging any upstream code-changes a difficult task.

@wcmatthysen wcmatthysen added enhancement New feature or request task Not a bug and removed task Not a bug labels Apr 10, 2019
@AndrewTasso
Copy link

@wcmatthysen In all honesty, I would treat those as two changes/issue. I highly recommend the maven standard directory layout for project organization (which Gradle uses as a default). But Gradle can be configured to utilize the current source/project paths. So, it's entirely up to those in charge which they'd like to come first.

@wcmatthysen
Copy link
Member Author

Yeah, I agree. It is probably best if the restructuring is a separate issue. One of the things that I'm not sure about is whether there will still be development done upstream or whether all development will cease on the 3rd of May. If development starts again and we go through with the restructure, then merging patches from upstream will be a pain. So, this issue should probably just be focused on getting Gradle to build a WorldWind jar given the current directory structure.

@PJHogan
Copy link
Member

PJHogan commented Apr 10, 2019

Right now, I have my money on NASA continuing development. Their Keystone Cops behavior on this one had to sober up a bit when another Federal agency said they would hire the NASA dev team if NASA was walking away from the project. This crew is the some of the best geospatial talent on the planet! Maybe NASA is starting to smell the coffee. . .

@wcmatthysen
Copy link
Member Author

@AndrewTasso, I added an initial gradle build configuration in this pull request: #30.

It just compiles the worldwind and worldwindx jars. The tests can also be run, as well as building the javadoc. There are still a lot of tasks that need to be added such as the webstart stuff, as well as building the MilStd2525 jar among others. But, I think this is a good starting point for us to get this going. So basically the commands are:

gradle clean build -- To clean, compile and run the tests.
gradle test -- To just run the tests.
gradle javadoc -- To generate the javadocs.

Then, I just wanted to hear your opinion on adding the gradle wrapper. I see that it is a bit of a contentious issue online whether or not to commit the wrapper to version-control. I personally feel that we should not commit the gradle wrapper to version control. Instead we should specify somewhere in our readme that the user should run a command like:

gradle wrapper --gradle-version 5.4

to get the gradle-wrapper that can then be used to build the project.

@wcmatthysen
Copy link
Member Author

As a reference, here is the contents of the build.gradle file:

apply plugin: 'java'

group = 'gov.nasa'
version = '2.2.0'

sourceCompatibility = '1.8'
targetCompatibility = '1.8'

repositories {
    mavenLocal()
    mavenCentral()
    jcenter()
}

dependencies {
    def joglVersion = '2.3.2'
    implementation "org.jogamp.jogl:jogl-all-main:$joglVersion"
    implementation "org.jogamp.gluegen:gluegen-rt-main:$joglVersion"

    implementation files('gdal.jar')

    implementation 'org.codehaus.jackson:jackson-core-asl:1.9.13'

    testImplementation 'junit:junit:4.5'
}

sourceSets {
    main {
        java {
            srcDirs = ['src']
        }
    }
    test {
        java {
            srcDirs = ['test']
        }
    }
}

// Compile worldwind jar.
jar {
    dependsOn classes
    version = null
    from sourceSets.main.output
    exclude 'gov/nasa/worldwindx/**'
    from(sourceSets.main.allSource) {
        include 'gov/nasa/worldwind/util/**/*.properties'
        include 'config/**'
        include 'images/**'
    }
}
// Copy worldwind jar to project-directory.
jar.doLast {
    copy {
        from "$buildDir/libs/${jar.archiveName}"
        into "${project.projectDir}"
    }
}

// Compile worldwindx jar.
task extensionsJar(type: Jar) {
    archiveBaseName = 'worldwindx'
    version = null
    from sourceSets.main.output
    include 'gov/nasa/worldwindx/**/*.class'
    from(sourceSets.main.allSource) {
        include 'gov/nasa/worldwindx/applications/sar/*.html'
        include 'gov/nasa/worldwindx/applications/sar/config/**'
        include 'gov/nasa/worldwindx/applications/sar/data/**'
        include 'gov/nasa/worldwindx/applications/sar/images/**'
        include 'gov/nasa/worldwindx/applications/worldwindow/config/**'
        include 'gov/nasa/worldwindx/applications/worldwindow/images/**'
        include 'gov/nasa/worldwindx/examples/data/**'
        include 'gov/nasa/worldwindx/examples/images/**'
    }
}
// Copy worldwindx jar to project-directory.
extensionsJar.doLast {
    copy {
        from "$buildDir/libs/${extensionsJar.archiveName}"
        into "${project.projectDir}"
    }
}

artifacts {
    archives extensionsJar
}

test {
    dependsOn jar
    classpath += project.files("$buildDir/libs/${jar.archiveName}", configurations.runtime)
}

javadoc {
    options {
        overview = "${project.projectDir}/src/overview.html"
        windowTitle = 'WorldWindJava API'
        title = 'NASA WorldWind Java-Community Edition'
        header = 'NASA WorldWind-CE'
        splitIndex = true
        noDeprecated = true
        version = false
        author = false
        use = true
    }
    exclude 'com/**'
    exclude 'gov/nasa/worldwind/formats/**'
}

@wcmatthysen
Copy link
Member Author

You'll see I'm building against a local gdal jar:

implementation files('gdal.jar')

The reason for this is that the WorldWind gdal jar has a custom class or two that is not included in the distributed jars on maven-central. We still need to figure out how we are going to solve this (see #17).

@robmilton
Copy link

I love the fact that there is a community beginning to work on WWJ! Especially in light of the Java 9+ changes. And I would love to contribute any way I can. We've been using WWJ for many years, but I just cloned my first Git repository yesterday!

I did want to mention that I first attempted to open the WWJ-CE project in Apache NetBeans 11. But I received an error stating...

Could not set unknown property 'archiveBaseName' for task ':extensionsJar' of type org.gradle.api.tasks.bundling.Jar.
A problem occurred evaluating root project 'worldwind'.
Build file '<path-to-project>\WorldWindJava\build.gradle' line:73

Line 73 of the build.gradle is: archiveBaseName = 'worldwindx'

Unfortunately I don't know the first thing about Gradle, but I was able to open and build the project in Apache NetBeans 10 without any issue.

Just wanted to mention this in case you wanted to test with Apache NetBeans 11. Or if there's anything I could do to help (and learn along the way) I'd be glad to.

@PJHogan
Copy link
Member

PJHogan commented Apr 25, 2019

Welcome aboard Rob!
Greatly appreciate your spirit and support!
And Bruce '@emxsys' is a 'Jeep Man' too. (emxsys.com)

@wcmatthysen
Copy link
Member Author

Hi @robmilton,

I also ran into that issue. I think I need to change that to baseName instead of archiveBaseName if I look at what they say on stackoverflow. I am not an expert on Gradle and I just slapped together the build.gradle file as I went along. There might still be issues with it that we need to solve. My initial goal was to just get it compiling from the command line when you run gradle build

@robmilton
Copy link

@wcmatthysen I think the attribute should be named archivesBaseName. I then changed rootProject.name='worldwind' to rootProject.name='WorldWindJava' in the settings.gradle file and the errors seemed to clear up in NetBeans 11.

I don't know anything about using Gradle. After making the changes above it seems like any Gradle task I attempt in NetBeans seems to complete without errors, but I haven't figured out how to actually build the WorldWind JAR yet.

@wcmatthysen
Copy link
Member Author

@robmilton, thanks, I'll check it out. I have only used NetBeans 8.2 to build the project so far, and I had to change the archiveBaseName to baseName for it to work. I'll try to see if I can build the project in NetBeans 11 with your recommendations in mind.

@wcmatthysen
Copy link
Member Author

I think we now have a working Gradle build that have been used a number of times to build WorldWind on Travis as well as IDEs such as NetBeans. This issue can thus be closed. We can re-open separate issues in the future if anything pops up again regarding the Gradle build.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants