We recently updated our project from Maven to Gradle in Rational Team Concert and had issues with RTC not recognizing changes in the subprojects. I was able to get this to work by bringing back in the old .project for the mastermodule and this appeared to allow us to move forward with checking in files. Currently the issue is that when we do refreshes of any of the projects, when Gradle synchronizes - it wants to overwrite the .project file which causes multiple issues and doesn’t allow for us to checkin changes. After updating this morning to 1.0.12 - I am not able to get anything to show up as modified although it is not trying to update the .project file additionally after the update it keeps wiping out the gradle.prefs file and after synchronizing I have the same issues.
The initial project file looks like this:
<?xml version="1.0" encoding="UTF-8"?> <projectDescription> <name>powersuitefx-master-module</name> <comment></comment> <projects> </projects> <buildSpec> <buildCommand> <name>org.eclipse.m2e.core.maven2Builder</name> <arguments> </arguments> </buildCommand> <buildCommand> <name>org.eclipse.buildship.core.gradleprojectbuilder</name> <arguments> </arguments> </buildCommand> </buildSpec> <natures> <nature>org.eclipse.m2e.core.maven2Nature</nature> <nature>org.eclipse.buildship.core.gradleprojectnature</nature> </natures> </projectDescription>
When I refresh a project:
Project file is now altered
<?xml version="1.0" encoding="UTF-8"?> <projectDescription> <name>powersuitefx-master-module</name> <comment></comment> <projects> </projects> <buildSpec> <buildCommand> <name>org.eclipse.m2e.core.maven2Builder</name> <arguments> </arguments> </buildCommand> <buildCommand> <name>org.eclipse.buildship.core.gradleprojectbuilder</name> <arguments> </arguments> </buildCommand> </buildSpec> <natures> <nature>org.eclipse.m2e.core.maven2Nature</nature> <nature>org.eclipse.buildship.core.gradleprojectnature</nature> </natures> <filteredResources> <filter> <id>1459542769231</id> <name></name> <type>26</type> <matcher> <id>org.eclipse.ui.ide.multiFilter</id> <arguments>1.0-projectRelativePath-matches-false-false-javafx-claims</arguments> </matcher> </filter> <filter> <id>1459542769482</id> <name></name> <type>26</type> <matcher> <id>org.eclipse.ui.ide.multiFilter</id> <arguments>1.0-projectRelativePath-matches-false-false-javafx-contentmanagement</arguments> </matcher> </filter> <filter> <id>1459542770299</id> <name></name> <type>26</type> <matcher> <id>org.eclipse.ui.ide.multiFilter</id> <arguments>1.0-projectRelativePath-matches-false-false-javafx-customer</arguments> </matcher> </filter> <filter> <id>1459542770956</id> <name></name> <type>26</type> <matcher> <id>org.eclipse.ui.ide.multiFilter</id> <arguments>1.0-projectRelativePath-matches-false-false-javafx-financials</arguments> </matcher> </filter> <filter> <id>1459542771627</id> <name></name> <type>26</type> <matcher> <id>org.eclipse.ui.ide.multiFilter</id> <arguments>1.0-projectRelativePath-matches-false-false-javafx-framework</arguments> </matcher> </filter> <filter> <id>1459542772492</id> <name></name> <type>26</type> <matcher> <id>org.eclipse.ui.ide.multiFilter</id> <arguments>1.0-projectRelativePath-matches-false-false-javafx-mstech-viewer</arguments> </matcher> </filter> <filter> <id>1459542773421</id> <name></name> <type>26</type> <matcher> <id>org.eclipse.ui.ide.multiFilter</id> <arguments>1.0-projectRelativePath-matches-false-false-javafx-policy</arguments> </matcher> </filter> <filter> <id>1459542774128</id> <name></name> <type>26</type> <matcher> <id>org.eclipse.ui.ide.multiFilter</id> <arguments>1.0-projectRelativePath-matches-false-false-powersuite-app</arguments> </matcher> </filter> <filter> <id>1459542774841</id> <name></name> <type>26</type> <matcher> <id>org.eclipse.ui.ide.multiFilter</id> <arguments>1.0-projectRelativePath-matches-false-false-build</arguments> </matcher> </filter> <filter> <id>1459542775598</id> <name></name> <type>26</type> <matcher> <id>org.eclipse.ui.ide.multiFilter</id> <arguments>1.0-projectRelativePath-matches-false-false-.gradle</arguments> </matcher> </filter> </filteredResources> </projectDescription>
When we compare with RTC with the initial project file we can see our changes:
With the new .project file, same file shows empty:
We think this might have to do with the filters being added to the .project file by Buildship.
Thanks.
Hey there,
I’m not familiar with RTC, but it seems to me it only considers the files in the root project when collecting changes, is that correct? That is kind of odd compared to how SVN and Git integration in Eclipse work (they will detect changes based on the underlying file system).
In any case, what you are seeing is caused by the resource filters that we added up until Buildship 1.0.10. The reason for those filters is simple: You already have the subprojects in your workspace as actual projects, so for the most part you don’t want to see them duplicated in the root project. In older Eclipse versions, you would also get duplicate entries in the “Open Resource Dialog”.
Since Buildship 1.0.11, we no longer add resource filters, instead we just hide the folders with a UI filter (which can be toggled by the user). To work around the “Open Resource” duplication problem for older Eclipse version, we decided to mark those folders as “derived”. I guess RTC is ignoring them for that reason in 1.0.11 too. The “derived” flag has also lead to other integration issues with eGit, so we decided to drop it in 1.0.13. This means that older Eclipse versions will show duplicate entries when you “Open Resource”, but that’s a small price to pay. Newer Eclipse versions have a “Hide duplicate resources” option.
So to sum it up: Please try out the Buildship nightly build tomorrow/Monday. It should fix the issue you are describing.
That’s intentional, the settings file has been migrated so all settings are in “org.eclipse.buildship.core.prefs” and they no longer contain absolute paths, so you can share them with your team. You can always see the latest changes in the Buildship release announcements.
Cheers,
Stefan
I ran into an issue with initial testing with a brand new workspace with just our source code loaded. When doing the import it couldn’t find org.eclipse.buildship.core.prefs for the master module which is interesting to me since isn’t it generated when you run the Gradle Project Import?
Here’s the error -
Anyway, I am going to test again this morning with a brand new eclipse install as well as new workspace and reimport the latest buildship plugin and will let you all know. If I still have an issue, I was debating whether to just copy the .prefs file from another workspace
Did you use the “Import Gradle project” wizard? You will have to use that wizard the first time you import a project.
Sorry if I didn’t specify that a little better but I meant the Import Gradle Project when I stated import. Haven’t had time to finish trying the import again in a “clean” environment but am planning on doing this shortly.
Please also include the stacktrace and which version of Eclipse and Buildship you are using 
Here is the stack trace - I tried to upload the entire error log as a .zip but states new users can’t upload files but yet I can upload the .jpg
- I tried this with a current project that I had setup with the version of buildship we had been using previously which was 1.0.8 so the org.eclipse.buildship.core.prefs did exist in my master module. I then updated the Gradle plugin by using the following site - http://download.eclipse.org/buildship/updates/e45/milestones/1.0. After Restart of Eclipse I then ran the Import Gradle project. I used the last milestone version you had for buildship 1.0.13.v20160407-1626-m
Eclipse version is 4.5 (Mars) and when doing the Gradle Project import - I used the Gradle Wrapper and had modified the gradle-wrapper.properties to to point to https://services.gradle.org/distributions/gradle-2.12-bin.zip
Please let me know what additional information you need. The current setup of the workspace as described above would be how the developers would have it configured currently by already have been running the older version of buildship and then trying to upgrade. I can test again with a workspace in which I didn’t run the older buildship version first but did get the same error that I referenced previously.
Buildship versions prior to 1.0.10 stored their connection settings in the .settings/gradle.prefs file, not in the .settings/org.eclipse.buildsip.core.prefs file.
Judging by the stacktrace, the project did not have that gradle.prefs file when you imported it into the new version. Could you please check whether that file is present on all projects before you migrate?
With the older version of buildship, we only had 1 gradle.prefs file that we had to modify for the master module (powersuitefx-master-module). If I need to create a separate gradle.prefs file for each of the subprojects I can do so.
I have created a separate gradle.prefs file for each project and ran the project import again and we are still having the same issues with the powersuitefx-master-module .project file being modified which in turn causes the same issues as reported earlier.
I am looking at the differences between each of the .project files as well to see if there is something I can change
Please note that Buildship does not remove the resource filters that earlier (<1.0.11) versions added. You’ll have to remove them manually once. The “overwrite” option on import can help with that.
Buildship 1.0.11+ will not add new filters.
A question about your setup: From your earlier comments it sounds like you use linked resources for the settings files. Is that correct? If yes, you’ll have to change that, they contain project specific information.
Thanks, I will look at that and rerun this again after cleaning up the gradle.prefs files as well as running with the overwrite option. We are not using Linked Resources but this was a project imported from Maven originally so maybe that has something to do with it. There is nothing specific in the master-module .project shown below
powersuitefx-mastermodule
<?xml version="1.0" encoding="UTF-8"?> <projectDescription> <name>powersuitefx-master-module</name> <comment></comment> <projects> </projects> <buildSpec> <buildCommand> <name>org.eclipse.m2e.core.maven2Builder</name> <arguments> </arguments> </buildCommand> <buildCommand> <name>org.eclipse.buildship.core.gradleprojectbuilder</name> <arguments> </arguments> </buildCommand> </buildSpec> <natures> <nature>org.eclipse.m2e.core.maven2Nature</nature> <nature>org.eclipse.buildship.core.gradleprojectnature</nature> </natures> </projectDescription>
Heres is one of the subprojects which currently does have all of the linked resources in it.
<?xml version="1.0" encoding="UTF-8"?> <projectDescription> <name>javafx-claims</name> <comment>Project javafx-claims created by Buildship.</comment> <projects> </projects> <buildSpec> <buildCommand> <name>org.eclipse.jdt.core.javabuilder</name> <arguments> </arguments> </buildCommand> <buildCommand> <name>org.eclipse.buildship.core.gradleprojectbuilder</name> <arguments> </arguments> </buildCommand> </buildSpec> <natures> <nature>org.eclipse.buildship.core.gradleprojectnature</nature> <nature>org.eclipse.jdt.core.javanature</nature> </natures> <filteredResources> <filter> <id>1455723647121</id> <name></name> <type>26</type> <matcher> <id>org.eclipse.ui.ide.multiFilter</id> <arguments>1.0-projectRelativePath-matches-false-false-build</arguments> </matcher> </filter> <filter> <id>1455723647129</id> <name></name> <type>26</type> <matcher> <id>org.eclipse.ui.ide.multiFilter</id> <arguments>1.0-projectRelativePath-matches-false-false-.gradle</arguments> </matcher> </filter> </filteredResources> </projectDescription>
Interesting, the code was definitely never designed to work if projects don’t have a prefs file. Might have been a coincidence that it worked in your case
Here’s things I’d do:
- verify that 1.0.13 is installed
- remove resource filters (if present) from .project files
- remove “derived” flag (if set) from subproject folders
The latter two can be achieved manually or by doing an “overwrite” import in a fresh workspace.
I looked for anything within the subprojects for a derived flag under properties but only found Store the encoding of the derived resources separately and this wasn’t checked. What other property would there be?
I removed the resource filters for all the projects as well as created the correct gradle prefs files. I was not prompted for any overwrite when doing the Import project so am not sure where this is set. After the import - I no longer see that buildship is trying to modify the .project but also am now not able to get RTC to recognize that a change has been made. I’m looking into that a little closer but do see now that RTC doesn’t think any of the subprojects are under source control but I do not have the option to add them either 
That option is offered only if you use “Import Gradle project” and the projects are not in the workspace already.
Not on the sub-projects, but on the folders that contain the sub-projects inside the root project.
- root
|- sub (right click here)
- sub (not here)
I don’t know RTC, have you made sure they are not in some ignore-file?
I have checked my ignore rules and there isn’t anything specific for this but for some reason they are being ignored. I am going to reload an empty workspace and run through this yet again and follow the steps specifically and will also overwrite the import in the fresh workspace. If that doesn’t work, I will frame a question to IBM on what it’s looking for under Pending changes to determine when a change is made which will hopefully lead me in the right direction.
Thanks for you assistance and hopefully we can get this resolved and you will have an idea of what is needed for any future RTC users
Just to clarify: Most of the things I explained here were just to cleanup the broken projects you had before.
If you have a fresh workspace with Buildship 1.0.13 installed, then just doing “Import Gradle Project” should work, no matter what was there before
Technically an earlier version of buildship was used when we first checked the files into SourceControl, I have to load the master module and then run buildship and since it does have the .project files there. So should I not have to generate the gradle.prefs files and it will find these for me? I went through and tested with creating all of the gradle.prefs now and validated that the folders for each project are not derived. After running buildship and subsequently Gradle Refresh Project, they now show as Derived and RTC still wants to ignore them. Stopping for today and will pick this up tomorrow.
If you use “Import Gradle Project”, it will generate the prefs file. You just need to make sure that the projects are not in the workspace before.
Sound like you are not using 1.0.13. The stacktrace you posted does not match 1.0.13. Please double-check what you have installed.