search

jmchamberlain / workspacemechanic

Automatically exported from code.google.com/p/workspacemechanic
0 stars 0 forks source link

Cannot enter relative path for task source directories (Windows) #24

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Open the Workspace Mechanic preferences page
2. Click New...
3. Try to add a path like the default "\.eclipse\mechanic"

What is the expected output? What do you see instead?
I removed the default path (silly me) and then tried to add it back, but
the "New..." button only provides a directory browser dialog, so a path
like the default (relative to user.home) cannot be added to list of task
sources.  

What version of the product are you using? On what operating system?
Version 0.0.2 on Windows XP SP2

Please provide any additional information below.
It would be preferable to have a dialog with an edit box and an optional
"Directory..." button, like you get when adding a JRE.

Original issue reported on code.google.com by michael....@gmail.com on 27 May 2010 at 8:48

GoogleCodeExporter commented 8 years ago 
I agree with your assessment of what would be better. I'm thinking of including 
URL-based tasks, which would make this a non-issue. But perhaps I'll just add 
it sooner rather than later.

Original comment by konigsb...@gmail.com on 14 Feb 2011 at 4:45

GoogleCodeExporter commented 8 years ago 
I've removed that too. Now I am forced to use absolute paths.

Original comment by anat...@rainforce.org on 16 Feb 2011 at 4:12

GoogleCodeExporter commented 8 years ago 
I've written something to replace it which will be in the 0.0.4 release.

Original comment by konigsb...@gmail.com on 17 Feb 2011 at 7:47

GoogleCodeExporter commented 8 years ago 
There are also Dynamic path variables in 3.6+ builds 
http://download.eclipse.org/eclipse/downloads/drops/R-3.6-201006080911/eclipse-n
ews-part1.html#dynamic_path_variables

Original comment by anat...@rainforce.org on 17 Feb 2011 at 8:24

GoogleCodeExporter commented 8 years ago 
Wait, I didn't understand the issue. Are you looking to have task source 
directories be relative to the workspace If that is the case I don't understand 
why you would do that. The idea behind the Workspace Mechanic is that settings 
live outside the workspace and so are made available to all workspaces.

Original comment by konigsb...@gmail.com on 17 Feb 2011 at 1:07

GoogleCodeExporter commented 8 years ago 
It is non that obvious that '.' specifies project root. PROJECT_LOC can be used 
to set this explicitly.

Original comment by anat...@rainforce.org on 17 Feb 2011 at 2:11

GoogleCodeExporter commented 8 years ago 
I think the right solution is to only allow absolute directories. I don't see 
the value of a relative directory. If you have a reason why that is helpful I 
can consider it.

Original comment by konigsb...@gmail.com on 17 Feb 2011 at 2:28

GoogleCodeExporter commented 8 years ago 
The original path was relative to a user's application data folder.  For 
example:
C:\Documents and Settings\MYUSER\.eclipse\mechanic

I'd like to enter paths relative to known Eclipse locations like this settings 
folder, or the Eclipse configuration folder for example.

Original comment by michael....@gmail.com on 18 Feb 2011 at 6:19

GoogleCodeExporter commented 8 years ago 
Hmm.... so I could see adding variable support. In fact, there already _is_ 
variable support, but it's hidden and one way (it's how we get the default 
paths to be in the user's home directory, but it only goes in one direction.) 
Let's see.

Original comment by konigsb...@gmail.com on 18 Feb 2011 at 6:45

GoogleCodeExporter commented 8 years ago 
Another usecase for workspace relative paths is, when you share your tasks via 
SCM. Then you can easily update the tasks with the normal source code update.

Original comment by konra...@gmx.de on 18 Mar 2011 at 7:09

GoogleCodeExporter commented 8 years ago 
I can see that. I'm not going to work on this immediately, but I think it might 
be worth doing.

Original comment by konigsb...@gmail.com on 18 Mar 2011 at 9:08

GoogleCodeExporter commented 8 years ago 
I can see that. I'm not going to work on this immediately, but I think it might 
be worth doing.

Original comment by konigsb...@gmail.com on 18 Mar 2011 at 9:09

GoogleCodeExporter commented 8 years ago 
Have a look at 
http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/gui
de/resAdv_variables.htm, section "path variables"

Original comment by konra...@gmx.de on 18 Mar 2011 at 7:25

GoogleCodeExporter commented 8 years ago 
and 
http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/gui
de/resInt_linked.htm

Original comment by konra...@gmx.de on 18 Mar 2011 at 7:27

GoogleCodeExporter commented 8 years ago 
Yes, I'm familiar with variable resolution. You'll see that it already does 
some. The issue is that  the way the code is laid out, variables are resolved 
before being stored, which means you'll never see you ${ again. This isn't a 
high priority for me, but if you're interested in expiditing this, patches are 
always welcome. See 
http://code.google.com/a/eclipselabs.org/p/workspacemechanic/wiki/DeveloperGuide

Original comment by konigsb...@gmail.com on 18 Mar 2011 at 9:17

GoogleCodeExporter commented 8 years ago 
Some findings regardings this issue:
- using IPathVariableManager and the dialog PathVariableSelectionDialog is not 
usefull, when working on workspace level, since by default no variables are 
provided for a workspace (even the variables which could be resolved on 
workspace level like WORKSPACE_LOC, ECLIPSE_LOC). Only the IPathVariableManager 
for a IResource below a workspace provides a standard set of variables.
- The IStringVariableManager provides no dialog for selecting a variable. 
Therefore one has to implement the whole UI.

Original comment by konra...@gmx.de on 10 Apr 2011 at 9:33

GoogleCodeExporter commented 8 years ago 
I committed a patch for this issue in my clone at: 
https://code.google.com/a/eclipselabs.org/r/konrad-w-devel/.
I already signed the CLA. Please review the patch.

Original comment by konra...@gmx.de on 10 Apr 2011 at 12:32

GoogleCodeExporter commented 8 years ago 
Thanks. I'm commenting on the change in your forked repository directly.

Original comment by konigsb...@gmail.com on 10 Apr 2011 at 3:46

GoogleCodeExporter commented 8 years ago 
I answered your comments a long time ago. Do you need any further information 
from my side or can you apply that patch?

Original comment by konra...@gmx.de on 7 Jun 2011 at 3:45

GoogleCodeExporter commented 8 years ago 
I've applied a slightly different version of the patch which is going to 
undergo some alterations to make it cross-platform compatible, which ought to 
get published soon.

Original comment by konigsb...@gmail.com on 10 Sep 2011 at 2:24

GoogleCodeExporter commented 8 years ago 
Issue 112 has been merged into this issue.

Original comment by konigsb...@gmail.com on 30 Oct 2013 at 6:01

GoogleCodeExporter commented 8 years ago 
Any updates on this? 
I would also like to use ${workspace_loc} since we share our workspace 
mechanics between all our developers.

Original comment by chrak...@gmail.com on 14 May 2014 at 10:52

GoogleCodeExporter commented 8 years ago 
It should have been published some time ago, to be honest. Is it really not in 
there?

Original comment by konigsb...@gmail.com on 14 May 2014 at 9:50

GoogleCodeExporter commented 8 years ago 
The variable does not expand for me atleast when specifying paths, for example 
${WORKSPACE_LOC}/foo
The WORKSPACE_LOC variable is not resolved.

I am using Workspace Mechanic 0.4.0

Original comment by chrak...@gmail.com on 15 May 2014 at 6:47