Skip to content
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

Move to unified gradle build #1835

Merged
merged 1 commit into from
Aug 27, 2019
Merged

Move to unified gradle build #1835

merged 1 commit into from
Aug 27, 2019

Conversation

loosebazooka
Copy link
Member

@loosebazooka loosebazooka commented Jul 10, 2019

Fixes #1790.

prerequisites to merging:

post-merge

  • ensure you submit cr/263181540 after so the maven release works.

about:

  1. unified build ./gradlew build or ./gradlew <anytask> will run on all projects
  2. ./gradlew <subproject>:build will limit the build to a subproject and it's dependencies
  3. IDEs will require certain pre-steps for some of their tests that test against a plugin build (might be easier to run those from the commandline)
    • gradle: ./gradlew jib-gradle-plugin:pluginUnderTestMetadata
    • maven: ./gradlew jib-maven-plugin:install
  4. build.sh is gone, all builds should use ./gradlew directly
  5. any common dependency version should be defined in the parent build.gradle and all dependencies are implementation and are exported to runtime (not compile) scope transitively.
  6. The releases should work, but we should probably do a little testing after this merges to truly ensure that.

Copy link
Member

@chanseokoh chanseokoh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whatever it's doing, I like moving away from the current setup where we copy source directories of other projects. I gave a try in Eclipse.

In Eclipse, looks like I need to import 5 Gradle projects, which doesn't look wrong: jib, jib-core, jib-gradle-plugin, jib-maven-plugin, jib-plugins-common.

Now, I had to additionally configure extra build path through the IDE mechanism. jib-gradle-plugin and jib-maven-plugin could not see classes in jib-core, so I had to add jib-core as an additional dependent project for them. Interestingly, I did not have to add jib-plugins-common as an explicit project dependency. I wonder if this is also the case in IntelliJ.

Now, unrelated, I was always not really a fan of making src/main/resources and src/[integration-]test/resources as Java source files. Conceptually, this doesn't make sense, because resources there are not project source. (I know they were added as "source" for the sake of convenience in running tests.) Consequently, Eclipse sees the test resources whose extension is .java as the genuine project source to compile and include, hence showing compilation failure. I have been manually excluding some sub-directories (e.g., ...test/resources/gradle/projects) through the IDE build path to let it not think they are project source.

build.gradle Show resolved Hide resolved
@chanseokoh

This comment has been minimized.

@loosebazooka

This comment has been minimized.

@chanseokoh

This comment has been minimized.

@loosebazooka

This comment has been minimized.

@loosebazooka loosebazooka changed the title Move to unified gradle build (WIP Move to unified gradle build (WIP) Jul 19, 2019
@loosebazooka

This comment has been minimized.

@loosebazooka

This comment has been minimized.

@loosebazooka loosebazooka force-pushed the reworkBuild branch 3 times, most recently from 22e38b8 to 9a0672f Compare July 26, 2019 20:30
cd github/jib/jib-core
./gradlew prepareRelease
cd github/jib
./gradlew :jib-core:prepareRelease
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not actually convinced this matches up with our release scripts, I'll have to see.

build.gradle Outdated Show resolved Hide resolved
@loosebazooka
Copy link
Member Author

some of these changes can probably be broken out into unrelated fixes, I'll do that to make this isolated to the build stuff.

@loosebazooka

This comment has been minimized.

@loosebazooka loosebazooka force-pushed the reworkBuild branch 2 times, most recently from 7c90542 to 1c6636f Compare August 6, 2019 19:18
@@ -185,5 +67,5 @@ pluginBundle {
}
}
}
tasks.publishPlugins.dependsOn integrationTest
//tasks.publishPlugins.dependsOn integrationTest
Copy link
Member Author

@loosebazooka loosebazooka Aug 6, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to uncomment this

@TadCordle
Copy link
Contributor

We'll probably need to update CONTRIBUTING.md as well.

@loosebazooka loosebazooka force-pushed the reworkBuild branch 4 times, most recently from 1f44fee to d9f495a Compare August 13, 2019 19:16
@loosebazooka loosebazooka changed the title Move to unified gradle build (WIP) Move to unified gradle build Aug 13, 2019
@loosebazooka
Copy link
Member Author

This should be ready now to look at.

CONTRIBUTING.md Outdated Show resolved Hide resolved
@loosebazooka loosebazooka added this to the v1.6.0 milestone Aug 13, 2019
@loosebazooka loosebazooka force-pushed the reworkBuild branch 2 times, most recently from 448b483 to ec61dab Compare August 19, 2019 21:03
Copy link
Contributor

@TadCordle TadCordle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried this on my laptop and it feels a lot nicer/simpler. LGTM once eclipse is confirmed to work.

CONTRIBUTING.md Show resolved Hide resolved
CONTRIBUTING.md Outdated Show resolved Hide resolved
CONTRIBUTING.md Outdated Show resolved Hide resolved
@chanseokoh
Copy link
Member

Yeah, definitely this is a lot nicer. No more copying source directories, and I really like it.

For the record, the outcome of the most recent try on Eclipse:

Now, I had to additionally configure extra build path through the IDE mechanism. jib-gradle-plugin and jib-maven-plugin could not see classes in jib-core, so I had to add jib-core as an additional dependent project for them. Interestingly, I did not have to add jib-plugins-common as an explicit project dependency. I wonder if this is also the case in IntelliJ.

This is still true, unfortunately. Not a big deal for me, as I only have to do this once and it's done.

Okay, I manually ran ./gradlew pluginUnderTestMetadata at the root (the jib/ directory), which created jib-gradle-plugin/build/pluginUnderTestMetadata/plugin-under-test-metadata.properties.

This was probably due to my lack of understanding of this thing. The old setup had the same problem; nothing new. I learned running test on the command line just generates this file. Once generated, I'm good.

Then I manually added jib-gradle-plugin/build/pluginUnderTestMetadata as an extra classpath folder for my test run configuration in Eclipse, and it works. Something unnecessary in the old setup.

No longer the case. No need to add an extra classpath. It works now. Or maybe I just misunderstood this part back then.

@chanseokoh

This comment has been minimized.

@loosebazooka

This comment has been minimized.

@loosebazooka
Copy link
Member Author

@chanseokoh about the javadoc, are you sure the bad @param is on a public method? The gradle javadoc (maybe different than maven) only generates javadoc for public apis

@chanseokoh
Copy link
Member

Yeah, it does fail. Didn't realized it only works for public things.

@TadCordle
Copy link
Contributor

Is there more work to be done on this or is this good to go?

@loosebazooka
Copy link
Member Author

I gotta rebase on the 1.5.1 release, but other than that, yeah

- also upgrades gradle to 5.2.1
- all builds should happen from root :<project>:<task>, build.sh removed
- tests that run the plugin may not work in IDEs unless correct setup
task run first
- special eclipse helpers to clear up classpath
- adds protections for transitive dependency overrides

// Use this to ensure we correctly override transitive dependencies
// TODO: There might be a plugin that does this
task ensureTransitiveDependencyOverrides {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is some new code to protect against us accidentally import httpclient of a different version transitively. It does the job, but I worry about the maintainability, as there may not be a way to know if it suddenly stops working. I guess currently it works, worst case it may not work.

@loosebazooka loosebazooka merged commit af34d9f into master Aug 27, 2019
@loosebazooka loosebazooka deleted the reworkBuild branch August 27, 2019 18:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Jib build is complicated
4 participants