-
Notifications
You must be signed in to change notification settings - Fork 59
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
upgrade gradle-intellij-plugin version and use newer gradle plugin sy… #708
Conversation
ignore this for now, running into some build problems |
} | ||
|
||
plugins { | ||
id 'net.researchgate.release' version '2.3.4' | ||
id 'org.jetbrains.intellij' version '0.1.5' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think, but I don't remember why, that this method of plugin import broke stuff. Have you tested this change out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its the new way to do it since gradle 2.1. I only recently upgraded the gradle wrapper on the project.
Its the version of the plugin that's breaking stuff. Not sure why yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it has something to do with muli-plugin projects like ours. I actually dug up on old issue you were contributing to: JetBrains/intellij-platform-gradle-plugin#17 . My suspicion is that the new version of the plugin is not compatible with the workaround you came up with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has been a valid way to import when we first set this up. But it did
cause breakages, I think related to evaluation order of stuff or something.
(sorry my memory is not so good) @loosebazooka might remember better.
On Thu, Jun 2, 2016 at 3:42 PM, Etan Shaul notifications@github.com wrote:
In build.gradle
#708 (comment)
:}
plugins {
id 'net.researchgate.release' version '2.3.4'
- id 'org.jetbrains.intellij' version '0.1.5'
Its the new way to do it since gradle 2.1. I only recently upgraded the
gradle wrapper on the project.Its the version of the plugin that's breaking stuff. Not sure why yet.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/gcloud-intellij/pull/708/files/d18beb8b378475ba4fb10ea67ad9eb5f6c0a4d32#r65605102,
or mute the thread
https://github.com/notifications/unsubscribe/AHf5HRtQvun-sUdVLsGSiWpSL1pbqkkLks5qHzIJgaJpZM4Is2Xx
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be. The new "plugins" syntax is new to gradle > 2.1: https://docs.gradle.org/2.1/release-notes#new-and-noteworthy
Either way its the version of the gradle-intellij-plugin thats causing the problem here (I tested it with the new import method but without upgrading the version and everything works fine).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was something weird going on, maybe it had something to do with subprojects? I really have no idea... it was so long ago, check the logs?!
An update on this so it does just sit here: I tried unsuccessfully to upgrade to the latest version of the gradle-intellij plugin but kept hitting a wall. It has to do with the fact that we have subprojects. Previously, the plugin would sandbox the Account plugin first then the Cloud Tools plugin afterwards, correctly creating two folders. After upgrading the plugin, the sandbox logic doesn't work the same way: after staging one of the plugins in /build/idea-sandbox/plugins the next staging wipes out the contents of the folder (rather then appending to it like before) resulting in only a single plugin being sandboxed. I tried a couple things including giving the subprojects different root sandbox directories and then manually (in build.gradle) copying things over, but this didn't work. This isn't blocking anything but I just wanted to update. Any ideas welcome. |
…ij into upgrade-ij-gradleplugin * 'master' of github.com:GoogleCloudPlatform/gcloud-intellij: (30 commits) IJ build version (#762) Update tracking api clients (#760) Update CHANGELOG.md (#759) Experimenting with new tracking API (#752) Release v0.9.6 beta (#758) Service lookup should use interface (#757) Release v0.9.5 beta (#756) Identify and properly label all compat projects (#753) Follow the convention /virtual/eventType/eventName (#754) Updates our app-tools-lib-for-java to the new name and released version. (#755) Retrieve plugin name from PluginInfoService (#743) Track deploy and stop task execution events (#750) Create pre-build task for app engine artifact sources (#749) Update changelog release date (#747) Restructure metrics event actions (#744) Don't show custom deployment options when flex compat (#745) Don't set environment in resetEditorFrom() (#739) Sync up with app-tools - remove setting of gsUtil (#737) Update changelog for next release (#735) Save and load artifact deployment source types (#734) ...
lgtm! maybe add a note on this pr with a link to their fix for this. |
Oh. Also, we might not want to change the way we are defining the dependency in this PR in case it has other side-effects (e.g. leave it in the dependencies section like before). |
Ok, sounds good, I'll make that change. It also looks like we're failing CI builds since the newer plugin version requires java 1.8. I'll update the travis config as well to reflect this. |
Oh it requires 8? I think thats a problem since we are targeting IJ 15+ which doesn't yet support java 8. |
I guess we can still run our builds on java 8 but target 7. On Thu, Jun 30, 2016 at 12:23 PM, Etan Shaul notifications@github.com
|
@patflynn but since we use Travis to generate the archives we upload to the JB repository, won't we have a binary compatibility issue if we build with java 8? |
obsolete. closing |
…ntax