Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 334508

Summary:	Need to determine that the platform's working directory was created during the current session
Product:	[Eclipse Project] Platform	Reporter:	Szymon Brandys <Szymon.Brandys>
Component:	Runtime	Assignee:	platform-runtime-inbox <platform-runtime-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	daniel_megert, dj.houghton, john.arthorne, malgorzata.tomczyk, remy.suen, tjwatson
Version:	3.7
Target Milestone:	---
Hardware:	PC
OS:	All
Whiteboard:
Bug Depends on:
Bug Blocks:	364140

Description Szymon Brandys

2011-01-17 06:14:59 EST

I need to determine somehow that the platform's working directory (also known as the instance data area) was created during the current session. In other words I need to check that my Eclipse is not using an existing workspace, but has just created one.

I was chatting with Dj about .metadata/version.ini. I thought that the code creating the file could also set a flag indicating that the worksapce is new. I found that IDEApplication#checkInstanceLocation creates it, so we can't rely on that. We should set the flag somewhere in the core code. Maybe BasicLocation?

Comment 1 DJ Houghton

2011-01-20 10:36:42 EST

Tom, let's chat about this when you get back.

Comment 2 John Arthorne

2011-01-20 11:22:52 EST

I'm not convinced this is going to do the right thing. For example if you never do any team operations in the very first session, then you will never be aware that the workspace is new. Consider the following example:

1) Installer invokes "eclipse -initialize" to complete the install. Workspace gets created and eclipse immediately exits.
2) Product is started by the user. At this point it is not a "new" workspace because the initialize step already created it.

Comment 3 Szymon Brandys

2011-02-23 08:33:51 EST

Tom, any comment on it?

Comment 4 Thomas Watson

2011-02-23 11:05:16 EST

(In reply to comment #3)
> Tom, any comment on it?

I think this approach is incorrect.  A location can get locked from an external source that never runs team stuff or even the workbench.  Imagine some tool that provisions projects to a new workspace.  It would first try to lock the new workspace which creates the location, then lock it and then create projects for it.

The first time you launch with such a workspace you will not know it is new.  I am not sure I understand the need to know it is new.  Seems like you can set your own flag to determine that you have migrated or read your own settings.

Comment 5 Thomas Watson

2011-04-29 08:54:17 EDT

I'm closing this as wont fix.  I don't think the locking code is the correct place to put this kind of logic.