Home » Eclipse Projects » Oomph » Executing ResourceCreationTask after workspace switch
| | | |
| Re: Executing ResourceCreationTask after workspace switch [message #1710478 is a reply to message #1710405] |
Wed, 07 October 2015 05:39   |
 Ed Merks
Messages: 33258
Registered: July 2009 |
Senior Member |
|
|
Johannes,
If you specify a task in a project setup of course it will only perform
when a stream for that project is referenced by the workspace.setup. If
you switch to a new workspace, that definitely won't be the case; there
will be an empty workspace.setup, and because it references no streams,
there will be no workspace task that resolve the workspace.location
variable. Also, when using the installer to create an installation, if
that project isn't selected, no workspace is created, and the installer
will not know where the workspace.location is in that case either. So
you can't just move the task to your product setup.
However, in a running IDE, ${osgi.instance.area} contains a URI for the
location of the workspace. So perhaps if moved your task to the
product, used ${osgi.instance.area} for the location of the workspace,
and (and this is important!) restricted the task (via the advanced
properties) to perform only on STARTUP and MANUAL, the task will perform
for each workspace opened by that installation. Note that it will
perform only in the running IDE which is the only place where the
workspace location is definitely known; this might be a problem if
something else has read (looked for) this file early during the
launching of the IDE before the task was executed.
On 06/10/2015 3:00 PM, Johannes Dorn wrote:
> @Ed: Thanks for the hint about the URL, I have corrected that mistake.
> You are right though in that this doesn't cause/affect the original
> problem.
>
> @Alexander: When i go to Navigate > Open Setup, i don't see the
> project setup listed. The product setup is there, though. When i then
> Import the setup as you suggested, i do get the wizard and as part of
> the resulting task, the resource creation task is correctly executed.
> So this already gives me a workaround. Thanks!
>
> Of course, i would like to spare developers the hassle to import the
> project setup. The resource creation task should thus be executed once
> for every workspace.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Executing ResourceCreationTask after workspace switch [message #1710826 is a reply to message #1710478] |
Fri, 09 October 2015 14:31 |
Johannes Dorn
Messages: 61
Registered: June 2013 |
Member |
|
|
Thank you, Ed!
This helps me understand the Oomph process a bit better.
Your suggested solution of moving the task into the product setup using the ${osgi.instance.area} variable kinda works. But i have two issues with it.
Perhaps you can help me once more.
The first problem is that the user is asked for the value of "osgi.instance.area (undeclared)" during the setup.
This field is mandatory; the setup won't continue without an input here.
What the user puts in here is irrelevant. When it comes to evaluating the value in the IDE, the workspace path is resolved, which results in a correct resource creation.
I've tried creating a variable with the name "osgi.instance.area" with a fixed value of "foo", but if i do that, "foo" is the resolved value later on rather than the workspace path.
How can i use the variable without having the user have to input anything here? Preferrably, the user shouldn't be aware of the variable, even when selecting "show all variables."
The second thing is that when i declare the target URL like this: "${osgi.instance.area|uri}.recommenders/snipmatch/repositories.config" it is resolved during setup as "file%3A/Users/johannes/workspace/.recommenders/snipmatch/repositories.config" which is not a file URL and is instead seen as a path relative to the Oomph setup file location. Note, i am testing in Mac OS X.
When i declare the target URL like this: "${osgi.instance.area}.recommenders/snipmatch/repositories.config" it is resolved as "file:/Users/johannes/workspace/.recommenders/snipmatch/repositories.config" and works perfectly. I am surprised though that the "file:" part is prepended and worried that it might not behave correctly on all Operating systems.
Thanks again, i feel i'm almost there.
|
|
| |
| Re: Executing ResourceCreationTask after workspace switch [message #1710861 is a reply to message #1710826] |
Fri, 09 October 2015 20:25 |
Ed Merks
Messages: 33258
Registered: July 2009 |
Senior Member |
|
|
Johannes,
Comments below.
On 09/10/2015 4:31 PM, Johannes Dorn wrote:
> Thank you, Ed!
> This helps me understand the Oomph process a bit better. Your
> suggested solution of moving the task into the product setup using the
> ${osgi.instance.area} variable kinda works. But i have two issues with
> it. Perhaps you can help me once more.
>
> The first problem is that the user is asked for the value of
> "osgi.instance.area (undeclared)" during the setup. This field is
> mandatory; the setup won't continue without an input here.
Is that during the installer processing? As I said, you must disable it
for bootstrap because in the installer it's the workspace of the
installer, and it doesn't have one...
> What the user puts in here is irrelevant. When it comes to evaluating
> the value in the IDE, the workspace path is resolved, which results in
> a correct resource creation.
> I've tried creating a variable with the name "osgi.instance.area" with
> a fixed value of "foo", but if i do that, "foo" is the resolved value
> later on rather than the workspace path.
> How can i use the variable without having the user have to input
> anything here? Preferrably, the user shouldn't be aware of the
> variable, even when selecting "show all variables."
>
It should always be defined in the running IDE...
>
> The second thing is that when i declare the target URL like this:
> "${osgi.instance.area|uri}.recommenders/snipmatch/repositories.config"
> it is resolved during setup as
> "file%3A/Users/johannes/workspace/.recommenders/snipmatch/repositories.config"
> which is not a file URL and is instead seen as a path relative to the
> Oomph setup file location. Note, i am testing in Mac OS X.
Yes, that's why I said " ${osgi.instance.area} contains a URI"... It's
already a URI...
> When i declare the target URL like this:
> "${osgi.instance.area}.recommenders/snipmatch/repositories.config" it
> is resolved as
> "file:/Users/johannes/workspace/.recommenders/snipmatch/repositories.config"
> and works perfectly. I am surprised though that the "file:" part is
> prepended and worried that it might not behave correctly on all
> Operating systems.
>
> Thanks again, i feel i'm almost there.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Executing ResourceCreationTask after workspace switch [message #1710863 is a reply to message #1710853] |
Fri, 09 October 2015 20:33 |
Ed Merks
Messages: 33258
Registered: July 2009 |
Senior Member |
|
|
Johannes,
Comments below.
On 09/10/2015 8:01 PM, Johannes Dorn wrote:
> I've looked some more into my second issue with the way
> ${osgi.instance.area} resolves.
> The system property is already a file URL, so using the "|uri"
> modifier is not necessary and will in fact try to escape the URL.
> Thus, for Mac, and probably Linux, ${osgi.instance.area} works as
> expected.
>
> Unfortunately, it doesn't work in Windows 7.
> Here it resolves to "file:/C:/Users/codetrails/workspace/"
That is correct, URI.createFileURI(new File(".'").getAbsolutePath())
will create file:/<drive>:/<path>. So does new
File(".'").getAbsoluteFile().toURI() for that matter.
> The ResourceCreationTask doesn't work with this kind of URL. It should
> have three slashes after the protocol. [1]
> If i manually set the URL to
> "file:///C:/Users/codetrails/workspace/"... it works as expected.
In my opinion file://C:/... is more correct. It has the drive as the
authority and that prevents ".." from navigate up beyond that point.
But in any case file:///C:/... should work too; this has an empty
authority as opposed to the first form above, which as a null authority.
>
> Is there a way to a) work with this style of URL, to b) convert the
> URL into something the ResourceCreationTask can work with, or c) is
> this a bug in the way URLs are treated in Windows?
I'm not sure your basis for the conclusion that file:/C:/... is wrong.
This is commonly used everywhere and should work everywhere...
>
> [1] https://en.wikipedia.org/wiki/File_URI_scheme#Windows_2
This information does not reflect what Java itself does on Windows. Try
new File(".'").getAbsoluteFile().toURI() which has nothing to do with EMF...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Executing ResourceCreationTask after workspace switch [message #1710864 is a reply to message #1710861] |
Fri, 09 October 2015 20:49 |
Johannes Dorn
Messages: 61
Registered: June 2013 |
Member |
|
|
Ed Merks wrote on Fri, 09 October 2015 16:25
Is that during the installer processing? As I said, you must disable it
for bootstrap because in the installer it's the workspace of the
installer, and it doesn't have one...
I had disabled it for Bootstrap, it is only triggered for Startup and Manual.
Still, the setup asks for a value.
Ed Merks wrote on Fri, 09 October 2015 16:25
It should always be defined in the running IDE...
Yes, defining a variable with the same name was just an attempt to get rid of the setup asking for a value.
Ed Merks wrote on Fri, 09 October 2015 16:25
I'm not sure your basis for the conclusion that file:/C:/... is wrong.
This is commonly used everywhere and should work everywhere...
I am probably wrong about this, yes (I don't have much experience with Windows file systems).
The point is though, that the file:/C:/... URL doesn't work for the ResourceCreationTask while the file:///C:/... URL does work. I haven't tried the file://C:/... URL, but that would be academic anyway, since all i get is the file:/C:/... version.
|
|
|
| Re: Executing ResourceCreationTask after workspace switch [message #1710903 is a reply to message #1710864] |
Sat, 10 October 2015 15:15 |
Ed Merks
Messages: 33258
Registered: July 2009 |
Senior Member |
|
|
Johannes,
To test this, I tried adding the following task to my workspace.setup of
a debug self-hosted IDE:
<?xml version="1.0" encoding="UTF-8"?>
<setup:ResourceCreationTask
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:setup="http://www.eclipse.org/oomph/setup/1.0"
content="Testing"
targetURL="${osgi.instance.area}sample.text"
encoding="UTF-8"/>
That works and the task produced
"D:\sandbox\oomph-master\ws-IDE\sample.text" on disk as expected.
But I see your point that the installer will prompt for the variant,
because it's not defined in the installer. So I'm looking at how to
specify logic so that an undeclared variant that isn't actually used by
any triggered task is not prompted. Note that the installer generally
prompts for things that won't actually be needed until the IDE performs
the task to avoid a second round of prompting once the installed IDE is
launched; that bites us in this case.
Feel free to pen a bug; I also have it working locally, but it needs
more testing and review...
On 09/10/2015 10:49 PM, Johannes Dorn wrote:
> Ed Merks wrote on Fri, 09 October 2015 16:25
>> Is that during the installer processing? As I said, you must disable
>> it for bootstrap because in the installer it's the workspace of the
>> installer, and it doesn't have one...
>
> I had disabled it for Bootstrap, it is only triggered for Startup and
> Manual.
> Still, the setup asks for a value.
>
> Ed Merks wrote on Fri, 09 October 2015 16:25
>> It should always be defined in the running IDE...
>
> Yes, defining a variable with the same name was just an attempt to get
> rid of the setup asking for a value.
>
> Ed Merks wrote on Fri, 09 October 2015 16:25
>> I'm not sure your basis for the conclusion that file:/C:/... is
>> wrong. This is commonly used everywhere and should work everywhere...
>
> I am probably wrong about this, yes (I don't have much experience with
> Windows file systems).
> The point is though, that the file:/C:/... URL doesn't work for the
> ResourceCreationTask while the file:///C:/... URL does work. I haven't
> tried the file://C:/... URL, but that would be academic anyway, since
> all i get is the file:/C:/... version.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Mon Dec 09 04:22:57 GMT 2024
Powered by FUDForum. Page generated in 0.02888 seconds |
] 
Search
Help
Register
Login
Home
