0

I have an Ecplise project shared on a Git repository with other people in a team.

It often happens that we have to add some linked resources in this project, effectively modifying the .project content, which is later committed and pushed to the repo.

Now, when another user pulls the modifications and opens its own Ecplise instance, if they have already imported the project before the configuration changes, Eclipse doesn't see the changes and still uses the old metadata, showing mistakes during the compilation of the project. the only way I have found to fix the situation is to delete the .metadata folder and reimport the project. Is there an easier way?

EDIT:

Eclipse version is 4.6.0.v20160606-1342, Build id: I20160606-1100. I am not working natively on Eclipse, but on a derived IDE (CCS Studio from Texas Instrument) and updating version is out of question.

Regarding the NullPointerException I mentioned in the comments, here is the stacktrace taken from the logs.

!ENTRY org.eclipse.ltk.ui.refactoring 4 10000 2019-04-04 18:16:36.261
!MESSAGE Internal Error
!STACK 0
java.lang.NullPointerException
    at com.ti.ccstudio.project.core.internal.temp.XMoveDeleteHook.deleteFile(XMoveDeleteHook.java:83)
    at org.eclipse.team.internal.core.MoveDeleteManager.deleteFile(MoveDeleteManager.java:50)
    at org.eclipse.core.internal.resources.Resource.unprotectedDelete(Resource.java:1827)
    at org.eclipse.core.internal.resources.Resource.delete(Resource.java:782)
    at org.eclipse.ltk.core.refactoring.resource.DeleteResourceChange.perform(DeleteResourceChange.java:163)
    at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:280)
    at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:280)
    at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:257)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2267)
    at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:305)
    at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation.executeChange(UIPerformChangeOperation.java:96)
    at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:221)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2267)
    at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:86)
    at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)
bracco23
  • 2,181
  • 10
  • 28
  • About what changes do you talk? Eclipse displays an item with an error instead of linked files/folders, right? As soon as the files/folders exists, a _Refresh_ (F5) should be sufficient to display the linked files/folder. – howlger Apr 04 '19 at 15:22
  • We mostly add/remove linked resources, so there is no actual file to rely on, the information is completely stored only in the `.project` file. – bracco23 Apr 04 '19 at 15:26
  • And when the link is removed, it is usually because the original file is removed too, which also gives a `NullPointerException` if I try to remove the link from the GUI. – bracco23 Apr 04 '19 at 15:28
  • I'm not able to reproduce this issue in Eclipse 2019-03 (4.11). Please show the `.project` file and give a step-by-step instruction to reproduce this issue. Please also show the stack trace of the `NullPointerException` (maybe it is caused by some specific tooling which locks files). – howlger Apr 04 '19 at 15:49
  • @howlger I have update the question with the info you asked for. Also, if i manually edit the link and point to any existing file, it allows me to delete it, so I guess it is somehow related to the face that the original file does not exist anymore. – bracco23 Apr 04 '19 at 16:20
  • According to the stack trace the NPE happens inside the CCS Studio from Texas Instrument code (in `com.ti.ccstudio.project.core.internal.temp.XMoveDeleteHook` line 83). Please report this bug to Texas Instrument, if it is not yet known. – howlger Apr 04 '19 at 21:59

1 Answers1

1

.project (or any other IDE metadata) should not be tracked in git because you will be facing problems like this over and over again and again... and again.

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • according to https://stackoverflow.com/a/119377/6397798, `.project` files are among the ones that should be tracked, but, apart from that, they are already tracked so that solution is not doable. – bracco23 Apr 04 '19 at 14:45
  • 1
    Sure... and that's just _an opinion_ on the subject. You can record mine: _ don't do it_ . If rewriting the history of the project is an option, I'd advice to rewrite it so that that directory is not included ever. If you choose to remove it _moving forward_ say, when you want to go back to a revision that has it, git will complain. If you force it and then you come back to a revision that doesn't have it, it will be removed and your IDE will complain.... in other words, you are stuck between a hard rock and a hard place. Take your pick. – eftshift0 Apr 04 '19 at 14:49
  • 1
    @eftshift0 The `.project` file is intended to be shared (everything that is not intended to be shared is stored in the `/.metadata` directory outside of the project). Everything referenced should not be outside of the shared repository and absolute paths should be avoided. Of course, this rule does not only apply to the `.project` but to all project content. – howlger Apr 04 '19 at 15:12