Workspace will not connect with KDS?!!!

[jose_tafolla]

I have selected my workspace location, and the project explorer is empty. I have also switched the workspace using the File directory but the explorer remains empty. It seems like there is a discontinuity between the workspace and the KDS software.

[robertpoor]

Erich:

Based on your helpful info, we solved the problem, although using a slightly different approach:

1. Add '.metadata' to the .gitignore file (most important!)
2. Delete the existing .metadata inside the workspace.kds directory
3. For each project:
   1. File => Import => General => Existing Projects into Workspace
   2. Select Root Directory => navigate to existing project under workspace.kds/
   3. Make sure "Copy projects into workspace" is UNchecked
   4. [Finish]

That brought back the projects to a point where they could be recompiled. 

Thanks for your help!

[BlackNight]

Hi Robert,

a few comments:

1. .ignore is a kind of filter only. Just make sure the files are deleted in the repository too.

3. 'copy projects' only works if there are no relative links to other places. It only copies the project folder and its content and not recursively all linked folder locations. SDK projects prior 2.x are using that kind of relative links to other folders in the project.

I hope this helps,

Erich

[robertpoor]

Haloo Erich!  I'm working with Jose on this project; here's a little additional info.  The short form: workspace A and workspace B seem to be nearly identical, but workspace A doesn't show any files in the file explorer while workspace B does:

Here's what we see when we open workspace A:

Here's what we see when we open workspace B:

Some salient details:

• running KDS 3.2.0
• Workspace B was pulled from a local machine, Workspace A was a git repository (in theory identical to Workspace B) that was pushed to github and then pulled back to the local machine.
• The protections and attributes of all the sub-files appear to be identical
• WinMerge reports the following:
  • .metadata/.mylyn is identical in A and B
  • .metadata/.plugins/ has a bunch of identical (and different) files.  I can supply the list if important.
  • .metadata/.log shows a different command line between the two:
    • A: Framework arguments:  -product com.somniumtech.branding.kds.ide -product com.somniumtech.branding.kds.ide -showlocation
      A: Command-line arguments:  -os win32 -ws win32 -arch x86 -product com.somniumtech.branding.kds.ide -data C:\Users\joset\Documents\SmartSensors\ws_a\workspace.kds -product com.somniumtech.branding.kds.ide -showlocation
    • B: Framework arguments: -product com.somniumtech.branding.kds.ide -showlocation
      B: Command-line arguments: -os win32 -ws win32 -arch x86 -product com.somniumtech.branding.kds.ide -showlocation
  • .metadata/.log shows an error for workspace B (the one that works!), but I don't think this is relevant:
    • java.lang.ClassNotFoundException: org.eclipse.e4.ui.workbench.renderers.swt.cocoa.ArrangeWindowHandler cannot be found
  • ./metadata/version.ini is identical except for the date (naturally)
• Inside one of the project directories (e.g. rex-cp):
  • Inside .settings, all files are identical except for .language.settings.xml, differing only in the hash value
  • .cproject is identical
  • .cwgeneratedFileSetLog is identical
  • .project is identical

Strictly speaking, there IS one other difference: workspace A (the failing one) has "windows" style line termination while workspace B (the working one) has "unix" style line termination.

But Jose and I are baffled as to why workspace A fails and workspace B works.

Is there any other info that would be helpful?

Best,

- rdp

[robertpoor]

Erich:

The .metadata folder location should not be moved,

Ah!  Duly noted.  I will make sure that .metadata is in the .gitignore file so this doesn't happen again.  

Are there other such files that should not be under git control (e.g. .settings or .cproject)?

[BlackNight]

Hi Robert,

I recommend to place projects outside of the workspace folder and instead have the IDE 'linking' to them. That way I can have projects in multiple repositories in different ways.

So:

- never ever put the .metadata folder into a repository (we have covered that :-) ).

- ignore everything which is derived or generated (generated make files, object files, ...)

- for Processor Expert or in general, see Version Control with Processor Expert Projects | MCU on Eclipse 

- for MCUXpresso or 'normal' Eclipse projects:
  a) you absolutely want the .project and .cproject in the repo

  b) put all your sources, linker files and launch configs into the repo (of course). The launch configs needs to be shareable (Sharing Debug Configuration with Eclipse | MCU on Eclipse )

  c) ignore the following
      /.settings/
      /debug/

     For the last one: this means your build/output folder. It could be 'release' too, or whatever you use

   Or look at the many .gitgnore I have on my main GitHub site, e.g. https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/MCUXpresso/i.MX%20RT1064_EVK/MIMXRT...

I hope this helps,

Erich

[BlackNight]

>>Workspace A was a git repository (in theory identical to Workspace B) that was pushed to github and then pulled back to the local machine.

Alarms are going on now. So I read this that the workspace (.metadata folder) has been  copied (by the pull) to a different location? As a general rule: never share/copy/alter the .metadata folder/location as it contains machine/envirionement/location specific information. The .metadata folder location should not be moved, otherwise 'strange' things like the one reported here will happen. Never put the .metadata e.g. on a VCS or move it around. Start with a new workspace. Think about the 'registry' on Windows: you cannot simply copy that to another machine, it will break. The .metadata folder contains caches and all other kind of things, and unless you know *exactly* what you are doing, keep it as is.

Maybe I read the details in a wrong way? In any case: do not 'share' the .metadata folder in a version control system. The only way it *might* work if you pull that folder into the exact same location on exact the same machine.

I hope this helps,

Erich

[BlackNight]

Not sure what you mean (could you post a screenshot)?

But if you select a new workspace, it will be 'empty' but will have the .metadata folder added.

Maybe you have filtered in your explorer the . (hidden) folders?

I hope this helps,

Erich