Open GoogleCodeExporter opened 9 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Issue 112 has been merged into this issue.
Original comment by konigsb...@gmail.com
on 30 Oct 2013 at 6:01
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
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
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
Original issue reported on code.google.com by
michael....@gmail.com
on 27 May 2010 at 8:48