Variable Substitution

[Thomas Oellrich]

Hi Robert,

I was wondering if it was possible to do variable substitution with
Java system properties during the import of the preference file
similar to the way Eclipse Team Etceteras does it?

http://kenai.com/projects/ete/pages/UserGuideWorkspaceConfig#2._Do_variable_substitutions_during_the_import_process

We have a few preferences that are absolute file paths that may be
different for each developer.

Cheers,
Tom

[Robert Konigsberg]

It's not something that currently exists, but feel free to add a
feature request, or better yet, a code contribution!

--
Robert Konigsberg

[Thomas Oellrich]

I've started work on some code. Could you just verify my assumptions before I send you a patch?

a) the feature is disabled by default and can be enabled either via plugin_customization.ini
(com.google.eclipse.mechanic/variableSubstitution=true) or via the Preferences dialog (see attachment)
b) variables are declared in the form ${variable_name}
c) a variable that cannot be resolved via system properties is left as is
d) the feature needs to work with both LASTMOD and RECONCILE preferences (personally, so far, I had no use for RECONCILE)

Cheers,
Thomas

2011/12/2 Robert Konigsberg <konig...@gmail.com>

[Robert Konigsberg]

Here are some questions I have for you.

Is this feature limited to .epf files, or other types, including .kbd?
Does the variable substitution work with preference metadata? Why or Why not?
There might be a legitimate use of ${variable.name} inside a file. Do
those now need to be escaped? How will you deal with this when some
people want variable substitution and some do not?

--
Robert Konigsberg

[Thomas Oellrich]

See comments inline

2011/12/9 Robert Konigsberg <konig...@gmail.com>

Here are some questions I have for you.

Is this feature limited to .epf files, or other types, including .kbd?

I only need it for .epf files so that's what I've started to implement.

Does the variable substitution work with preference metadata? Why or Why not?

Not quite sure what you mean with preference meta data. @title, @description and @audit_type?

There might be a legitimate use of ${variable.name} inside a file. Do
those now need to be escaped?

Unless variable.name happens to be a system property it would not be touched. One could think about adding a prefix such as ${mechanic.variable_name}. I could strip off the prefix and check whether variable_name is a system property

How will you deal with this when some

people want variable substitution and some do not?

It's disabled per default and needs to be switched on explicitly

[Thomas Oellrich]

Added another comment. See below...

2011/12/9 Robert Konigsberg <konig...@gmail.com>

Here are some questions I have for you.

Is this feature limited to .epf files, or other types, including .kbd?
Does the variable substitution work with preference metadata? Why or Why not?
There might be a legitimate use of ${variable.name} inside a file.

Instead of using the ubiquitous ${...} maybe something like @[...] would be more appropriate 

[Robert Konigsberg]

On Fri, Dec 9, 2011 at 10:09 AM, Thomas Oellrich <toel...@gmail.com> wrote:
> See comments inline
>
>
> 2011/12/9 Robert Konigsberg <konig...@gmail.com>
>>
>> Here are some questions I have for you.
>>
>> Is this feature limited to .epf files, or other types, including .kbd?
>
> I only need it for .epf files so that's what I've started to implement.

That's fine.

>>
>> Does the variable substitution work with preference metadata? Why or Why
>> not?
>
> Not quite sure what you mean with preference meta data. @title, @description
> and @audit_type?

Yes

>> There might be a legitimate use of ${variable.name} inside a file. Do
>> those now need to be escaped?
>
> Unless variable.name happens to be a system property it would not be
> touched. One could think about adding a prefix such as
> ${mechanic.variable_name}. I could strip off the prefix and check whether
> variable_name is a system property

Speaking of which, why would you use system properties when Eclipse
tends to rely on variable substitution?

> How will you deal with this when some
>>
>> people want variable substitution and some do not?
>
> It's disabled per default and needs to be switched on explicitly

I don't think a preference is the way to go. Instead I think
annotating that the .epf itself uses variable substitution makes more
sense. Then it matters less which characters you use. Trying to choose
a less likely pattern just means it'll happen less likely. We want no
conflicts at all.

What should happen if a variable (or system property) does not exist?

--
Robert Konigsberg

[Thomas Oellrich]

Let me see if I get this straight: Let's assume we have a maven.epf inside a shared directory. We would specify the variables that need to be substituted as a comma-separated list inside the .epf:

# @title Maven Settings

# @description Settings for m2e

# @task_type LASTMOD

# @substitution foo,bar

file_export_version=3.0

/instance/org.eclipse.m2e.core/eclipse.m2.userSettingsFile=${foo}/maven3/settings.xml

The developer has a generated script to start eclipse like so

eclipse -vmargs -Dfoo=/home/tom

and WM would replace ${foo} with /home/tom before importing the preferences into eclipse. Sounds great.

If one of the variables specified with @substitution is not actually used in the epf file, such as bar in the above example, I would ignore it. If foo does not actually exist as a system property, I would log to the error log of Eclipse and import the preference as is (including ${foo}).

I haven't quite understood your question though about why I'm using system properties. What could we use instead? How do you guys at Google handle the above scenario?

2011/12/9 Robert Konigsberg <konig...@gmail.com>

[Thomas Oellrich]

Regarding your question of why I'm using system properties instead of Eclipse properties, I guess you're asking why I'm not using something like this instead:

/instance/org.eclipse.m2e.core/eclipse.m2.userSettingsFile=${system:ECLIPSE_HOME}/../maven3/settings.xml

or

/instance/org.eclipse.m2e.core/eclipse.m2.userSettingsFile=${workspace_loc}/../../maven3/settings.xml

Let me give that another try and get back to you.

2011/12/10 Thomas Oellrich <toel...@gmail.com>

[Robert Konigsberg]

I do not think there is a need to list the variables. Instead just indicate if variable substitution will occur at all. Consider that this needs to be 100% compatible with existing behavior, no questions.

[Thomas Oellrich]

OK, I actually managed to convince our infrastructure architect to use the default m2e preferences (pointing to the developer's home directory) so it seems I might not need this feature after all (at least for now). If anybody ever needs it, I've already written some code I can contribute.

2011/12/10 Robert Konigsberg <konig...@gmail.com>

[Robert Konigsberg]

OK. The feature would still be useful, so keep it in mind. Thanks again!

--
Robert Konigsberg

[John Van Etten]

Has this not been implemented?  I would like to use ${workspace_loc} since I have different workspace folders for different branches of code. 

[Robert Konigsberg]

I don't think so. I think it's not a crazy amount of work to implement, but as I've been saying on the mailing list, I'll only entertain full patches with good tests.

On Fri, Dec 7, 2012 at 11:39 AM, John Van Etten <engage...@btvideoconferencing.com> wrote:

Has this not been implemented?  I would like to use ${workspace_loc} since I have different workspace folders for different branches of code. 

--
Robert Konigsberg

[John Van Etten]

I'll try and find some time to get my hands dirty and implement something.

[Martin Oberhuber]

Has this been implemented by now ?

I'm just annoyed by CDT bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=406783 so I cannot use ${user_home} for my CDT user dictionary... hoping that mechanic could replace this for me ?

[Robert Konigsberg]

I haven't received any patches, sorry.

On Mon, Apr 29, 2013 at 7:20 AM, Martin Oberhuber <martin.o...@gmx.at> wrote:

Has this been implemented by now ?

I'm just annoyed by CDT bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=406783 so I cannot use ${user_home} for my CDT user dictionary... hoping that mechanic could replace this for me ?

--
You received this message because you are subscribed to the Google Groups "Workspace Mechanic for Eclipse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to workspacemecha...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Robert Konigsberg