Re: [platform-dev] Workspace location, properties and declarative services

[Mickael Istria]

On Tue, Mar 23, 2021 at 6:37 PM Sebastian Zarnekow <
sebastian.zarne...@gmail.com> wrote:

> Personally I see a lot of value in backwards compatibility at Eclipse.
> Amongst others, the ResourcesPlugin is a very central API and its offered
> accessors to the workspace and friends are probably used by hundreds and
> thousands of plugins that are not under our control. Before moving code
> left and right, I would be really curious how a fully backwards compatible
> solution may look like.
>

Platform has policies and technical validation that ensure that backwards
compatibility is enforced at API level: most APIs have tests that are
contract/spec tests of the behavior, and there are a lot of tools to ensure
API so linkage compatibility is not broken by inadvertence. Concretely,
ResourcePlugin.getWorkspace() will never be removed.
If there are some tricky case you foresee about the upcoming refactoring
which risk of breaking the current API contract, I suggest you capture them
in some test case to integrate in the Platform test bench. In the best
case, they'll be consensual and be merged to prevent this area from
regressing in future refactorings; in the worst case, it's not clear the
behavior being tested is a contract, but it brings the test brings the best
possible material for discussing it.

What concerns me a little are the other exercises in that direction that
> did already land. I often read on bugzillas that class loading is
> dominating the entire activation and if a class is not loaded in context of
> plugin A, it will simply trigger the load in the context of a plugin B and
> there is no real gain in the total startup. After all, the code that is
> supposed to be executed must be loaded before it can run and before the
> workbench can appear.
>

Workbench is not the only consumer of the bundles. Many applications do run
headless, repeatedly at build-time (API Tools for instance). So even if
some refactorings do not impact workbench load, they can positively impact
other use cases, that are also interesting.

Even if I will be perceived as the party pooper: Another concern of mine
> (there is always another concern...): Is this level of complexity that is
> inherent to any multi threaded solution for bundle activation and class
> loading worth the few milliseconds that can be shaved.
>

I looked at a few reviews on the matter of workspace initialization, and my
impression is that it depends: in some cases, refactorings to use an OSGi
service do not increase complexity, they sometimes happen to better
separate concerns and thus improve maintainability/simplicity. But
sometimes, it's indeed slightly more complex.
I have the impression those are similar to any change and should be treated
individually like we do for all other changes, as there is not clear sign
that things get systematically simpler/harder, better/worse,... when using
services.


> But in the end, I'm not a committer on the platform and only a consumer
> that tries to maintain a complex framework across various versions of
> Eclipse in a backward- and forward-compatible way. In the end I can only
> voice my opinion and try to understand the solution such that I know how to
> best use it such that the code is still fine with Eclipse 4.8, 4.20, and
> all versions inbetween.
>

Platform usually try to capture new patterns in migration guide and
documentation. But for sure, if you want to still write code that targets
Eclipse 4.8, you won't be able to use newer APIs and patterns, eg your
plugin will keep calling ResourcePlugin.getWorkspace early in Activator and
Eclipse Workbench will not start faster when your plugin is installed. But
as long as you stick to 4.8 and verify you don't rely on APIs that don't
get deprecated/removed, it should work with 4.20 even if some refactorings
about internal Activator have been happening; 4.20 should not work worse
than 4.8.
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Workspace location, properties and declarative services

[Sebastian Zarnekow]

> To be fair, that’s just what the ResourcesPlugin does at the moment:

Private mutable static fields are not the same as a public mutable static
fields - especially without any synchronization means when the entire story
appears to be about concurrent bundle activation.
And better locality is something that I'm not sure about when the only
supposed client of an API is no longer the owner of the API.

Anyhow, nitpicking aside.

Personally I see a lot of value in backwards compatibility at Eclipse.
Amongst others, the ResourcesPlugin is a very central API and its offered
accessors to the workspace and friends are probably used by hundreds and
thousands of plugins that are not under our control. Before moving code
left and right, I would be really curious how a fully backwards compatible
solution may look like.
What concerns me a little are the other exercises in that direction that
did already land. I often read on bugzillas that class loading is
dominating the entire activation and if a class is not loaded in context of
plugin A, it will simply trigger the load in the context of a plugin B and
there is no real gain in the total startup. After all, the code that is
supposed to be executed must be loaded before it can run and before the
workbench can appear.

Even if I will be perceived as the party pooper: Another concern of mine
(there is always another concern...): Is this level of complexity that is
inherent to any multi threaded solution for bundle activation and class
loading worth the few milliseconds that can be shaved. Especially in the
light of

> hard-coded references to ResourcesPlugin that are likely to be affected
which we need to resolve

and therefore at the risk of breaking plugins that used to run perfectly
fine for years?

All this really makes me wonder if the imposed risk and effort (in coding,
reviewing, testing etc) is in a healthy relation to the outcome.

But in the end, I'm not a committer on the platform and only a consumer
that tries to maintain a complex framework across various versions of
Eclipse in a backward- and forward-compatible way. In the end I can only
voice my opinion and try to understand the solution such that I know how to
best use it such that the code is still fine with Eclipse 4.8, 4.20, and
all versions inbetween.

Best
Sebastian


On Tue, Mar 23, 2021 at 5:55 PM Alex Blewitt  wrote:

> On 23 Mar 2021, at 10:58, Sebastian Zarnekow 
> wrote:
>
> Hi Alex,
>
> given the long explanation for the issue and the impact such a change
> might have on downstream consumers along with the scray feeling that I have
> about code like
>
> public class Workspace .. {
> /**
>  * Used by ResourcesPlugin to identify the workspace, not for other uses.
>  */
> public static IWorkspace singleton;
> ..
> }
>
>
> To be fair, that’s just what the ResourcesPlugin does at the moment:
>
>
> https://github.com/eclipse/eclipse.platform.resources/blob/7fc856229a1e26eae354adf70d11b39d6727c20e/bundles/org.eclipse.core.resources/src/org/eclipse/core/resources/ResourcesPlugin.java#L350-L356
>
> It was a refactoring that essentially moved it from
> ResourcesPlugin.workspace to Workspace.workspace for better locality. This
> is where it initialises the static singleton at the moment:
>
>
> https://github.com/eclipse/eclipse.platform.resources/blob/7fc856229a1e26eae354adf70d11b39d6727c20e/bundles/org.eclipse.core.resources/src/org/eclipse/core/resources/ResourcesPlugin.java#L464
>
> Alex
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Workspace location, properties and declarative services

[Sebastian Zarnekow]

Hi Alex,

given the long explanation for the issue and the impact such a change might
have on downstream consumers along with the scray feeling that I have about
code like

public class Workspace .. {
/**
 * Used by ResourcesPlugin to identify the workspace, not for other uses.
 */
public static IWorkspace singleton;
..
}

I'd like to pick Ed's question: What is the net-benefit the change you are
making? I think that it will help to understand the goal (beyond "Use DI
instead of Activator") in order to understand the outlined solution.

Best
Sebastian



On Mon, Mar 22, 2021 at 11:38 PM Alex Blewitt 
wrote:

> I’m trying to migrate the Workspace initialisation from an Activator
> start() method to a Declarative Service in
> https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/178145
>
> Although this works if the workspace location has been set with a -data
> flag, it doesn’t work if the user decides to change the location later on.
> That’s because the IDEApplication prompts the user for a location in the
> org.eclipse.ui.ide bundle, which in turn, has a dependency on the
> org.eclipse.core.resources bundle that defines the workspace.
>
> The following happens at startup:
>
> * Equinox publishes an org.eclipse.services.datalocation.Location of type
> osgi.instance.area
>
>
> https://github.com/eclipse/rt.equinox.framework/blob/1c00fefd63ceff66a96d66f578a30a5677864877/bundles/org.eclipse.osgi/container/src/org/eclipse/osgi/internal/framework/SystemBundleActivator.java#L178
>
> * IDEApplication prompts the user for a dialog, and then sets the instance
> location:
>
>
> https://github.com/eclipse/eclipse.platform.ui/blob/b65540939ac72f0c57a7b2ed32235fcfc9471361/bundles/org.eclipse.ui.ide.application/src/org/eclipse/ui/internal/ide/application/IDEApplication.java#L313
>
> * This is ultimately accessible from
> Workspace->LocalMetaArea->Activator.installLocation
>
>
> https://github.com/eclipse/rt.equinox.bundles/blob/e4e1bb43f2b17f84b39c6361e938bd9ae7e6e086/bundles/org.eclipse.equinox.common/src/org/eclipse/core/internal/runtime/Activator.java#L55
>
>
> The problem is that because the Location is published at startup, whether
> or not it has been set, it’s not trivial to configure to DS to set up a
> dependency to arrive when the value has been changed. It’s also not clear
> what should happen to configurations that use ResourcesPlugin but don’t use
> the IDEApplication.
>
> The problem is that if we launch the Workspace with no dependencies, it
> will default to and initially set up) the default value, unless @noDefault
> is specified, in which case it will likely error out.
>
> We could set up a dependency such that the Workspace only is launched when
> an osgi.instance.area Location is published, but Equinox will do this
> automatically unless the @noDefault is given.
>
> Finally, we could publish a service/placeholder/Location in
> IDEApplication, which could be used to trigger the creation of the
> Workspace by DS.
>
> Ultimately I think the only way of solving it is to either set the URL of
> the workspace as a service property of the location when it’s published,
> and when the URL is updated then update the service properties accordingly.
> Thus we could have the creation of the workspace dependent upon a service
> being published:
>
> {org.eclipse.osgi.service.datalocation.Location}={type=osgi.instance.area}
> =>
>
> {org.eclipse.osgi.service.datalocation.Location}={type=osgi.instance.area,url=/path/to/workspace}
>
> We could then set up the DS component for the Workspace to listen to a
> service filter that has the URL set as a property.
>
>
> https://github.com/eclipse/rt.equinox.framework/blob/1c00fefd63ceff66a96d66f578a30a5677864877/bundles/org.eclipse.osgi/supplement/src/org/eclipse/osgi/service/datalocation/Location.java#L37
>
> Thoughts?
>
> Alex
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Workspace location, properties and declarative services

[Alex Blewitt]

> On 23 Mar 2021, at 08:56, Lars Vogel  wrote:
> 
> Hi Alex,
> 
> What about sending out an event via the EventAdmin service once the
> workspace location changes?  We currently have the UI events in e4 via
> the IEventBroker for example for the application start.

The problem is that events published via EventBroker are ephemeral. If an event 
has been published and then your bundle currently runs, you don’t have a way of 
picking that up. The EGit integration looks at startup whether the Platform is 
running or not, and takes different actions based on the assumption that it’s 
been triggered before/after the event has been released. For services which 
must be started I think relying on EventAdmin is not the best trigger.

If Eclipse supported the config admin service, you could replace the OSGi 
Location services that get published with a dynamic config policy, and then 
have the workspace service depend on a configuration policy being set. As it 
stands, the Location services are a minimal service wrapper around such 
configuration with some supporting methods.

Alex

___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] How to best document consumed OSGi/DS services?

[Wim Jongman]

I don't think we strongly need such specific javadoc annotations at the
> moment. Specific annotations were not required for extension points, so I
> don't think they should be necessary for services.
>

Extension points are not documented in the Javadoc. It would be nice if
they'd be documented the same way that you now want to document the
services...
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Workspace location, properties and declarative services

[Lars Vogel]

Hi Alex,

What about sending out an event via the EventAdmin service once the
workspace location changes?  We currently have the UI events in e4 via
the IEventBroker for example for the application start.

But the service property also sounds good to me.

Best regards, Lars

On Mon, Mar 22, 2021 at 11:38 PM Alex Blewitt  wrote:
>
> I’m trying to migrate the Workspace initialisation from an Activator start() 
> method to a Declarative Service in 
> https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/178145
>
> Although this works if the workspace location has been set with a -data flag, 
> it doesn’t work if the user decides to change the location later on. That’s 
> because the IDEApplication prompts the user for a location in the 
> org.eclipse.ui.ide bundle, which in turn, has a dependency on the 
> org.eclipse.core.resources bundle that defines the workspace.
>
> The following happens at startup:
>
> * Equinox publishes an org.eclipse.services.datalocation.Location of type 
> osgi.instance.area
>
> https://github.com/eclipse/rt.equinox.framework/blob/1c00fefd63ceff66a96d66f578a30a5677864877/bundles/org.eclipse.osgi/container/src/org/eclipse/osgi/internal/framework/SystemBundleActivator.java#L178
>
> * IDEApplication prompts the user for a dialog, and then sets the instance 
> location:
>
> https://github.com/eclipse/eclipse.platform.ui/blob/b65540939ac72f0c57a7b2ed32235fcfc9471361/bundles/org.eclipse.ui.ide.application/src/org/eclipse/ui/internal/ide/application/IDEApplication.java#L313
>
> * This is ultimately accessible from 
> Workspace->LocalMetaArea->Activator.installLocation
>
> https://github.com/eclipse/rt.equinox.bundles/blob/e4e1bb43f2b17f84b39c6361e938bd9ae7e6e086/bundles/org.eclipse.equinox.common/src/org/eclipse/core/internal/runtime/Activator.java#L55
>
> The problem is that because the Location is published at startup, whether or 
> not it has been set, it’s not trivial to configure to DS to set up a 
> dependency to arrive when the value has been changed. It’s also not clear 
> what should happen to configurations that use ResourcesPlugin but don’t use 
> the IDEApplication.
>
> The problem is that if we launch the Workspace with no dependencies, it will 
> default to and initially set up) the default value, unless @noDefault is 
> specified, in which case it will likely error out.
>
> We could set up a dependency such that the Workspace only is launched when an 
> osgi.instance.area Location is published, but Equinox will do this 
> automatically unless the @noDefault is given.
>
> Finally, we could publish a service/placeholder/Location in IDEApplication, 
> which could be used to trigger the creation of the Workspace by DS.
>
> Ultimately I think the only way of solving it is to either set the URL of the 
> workspace as a service property of the location when it’s published, and when 
> the URL is updated then update the service properties accordingly. Thus we 
> could have the creation of the workspace dependent upon a service being 
> published:
>
> {org.eclipse.osgi.service.datalocation.Location}={type=osgi.instance.area}
> =>
> {org.eclipse.osgi.service.datalocation.Location}={type=osgi.instance.area,url=/path/to/workspace}
>
> We could then set up the DS component for the Workspace to listen to a 
> service filter that has the URL set as a property.
>
> https://github.com/eclipse/rt.equinox.framework/blob/1c00fefd63ceff66a96d66f578a30a5677864877/bundles/org.eclipse.osgi/supplement/src/org/eclipse/osgi/service/datalocation/Location.java#L37
>
> Thoughts?
>
> Alex
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev



-- 
Eclipse Platform project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: http://www.vogella.com
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] How to best document consumed OSGi/DS services?

[Christoph Läubrich]

> Concretely, I want *extensibility* to be documented. So yes, I think
> it's about usage of some services.

ok

> Actually, it's the most important part IMO. The Platform usage of DS
> here and there is the extensibility, it needs to be documented.

but DS is only *one* way to consume a service, so I think this should 
not be limited to the ds topic.


> I don't think we strongly need such specific javadoc annotations
> at the moment. Specific annotations were not required for extension
> points

but require statically crafted extension schemas... the counter-part for 
DS would be the component.xml that could for sure be scanned by some 
tool and generate whatever docs that are desired from.
But as mentioned before, DS is just a way to consume services and even a 
DS component is not required to consume/produce *all* services in a 
declarative way.


So when it comes to OSGi Services the Service interface is where to 
define the contract, thus either class annotations or javadoc 
annotations seems most suitable for me.


If one wants to follow a "standard" I think the most normative would be 
the OSGi Specification itself, but this is nothing that could be 
generated out of code automatically I think.


For example take the "Config Admin Specification"[1], it contains 
several section describing how the service behaves, what consumers has 
to take into account and so on.


Further down, it describes the ServiceInterfaces e.g. the 
ConfigurationPlugin [2], taking a look at the source code one would see 
that it is a mixture of java annotations (e.g. @ConsumerType) as well as 
described Properties (e.g. CM_TARGET), or are annotated (e.g. CM_RANKING 
@since) that make up the contract of that services. How this service is 
consumed/provided (ds, service tracer, blueprint,..) doesn't matter.


Last but no least, it contains a package-info-class with some additional 
information where to find further information and the @Version 
annotation of what version this part is.



[1] https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.cm.html
[2] 
https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.cm.html#org.osgi.service.cm.ConfigurationPlugin



Am 23.03.21 um 08:49 schrieb Mickael Istria:



On Tue, Mar 23, 2021 at 6:24 AM Christoph Läubrich 
mailto:lae...@laeubi-soft.de>> wrote:


I'm not sure what you have in mind. DO you like to document the *usage*
of DS?


Concretely, I want *extensibility* to be documented. So yes, I think 
it's about usage of some services.


as mentioned earlier I would expects documentation at the service
interface itself.


Right.

That platform uses DS to consume services is just an
implementation detail and doesn't bother the provider much.


Actually, it's the most important part IMO. The Platform usage of DS 
here and there is the extensibility, it needs to be documented.


Such documentation then could of course use javadoc annotations that
then could be present in the html output as well see

https://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.8.1/examples/tag-configuration.html




I don't think we strongly need such specific javadoc annotations at the 
moment. Specific annotations were not required for extension points, so 
I don't think they should be necessary for services.


Concretely, I think we need a page similar to 
https://help.eclipse.org/2021-03/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fextension-points%2Findex.html 
 
but listing the service classes and their usage in some extensibility 
contracts.
I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=572207 
 on that matter. 
This is IMO critical that we get a "minimal viable product" of such 
documentation before we start growing the extensibility of Platform via 
services.


___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev


___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] How to best document consumed OSGi/DS services?

[Mickael Istria]

On Tue, Mar 23, 2021 at 6:24 AM Christoph Läubrich 
wrote:

> I'm not sure what you have in mind. DO you like to document the *usage*
> of DS?
>

Concretely, I want *extensibility* to be documented. So yes, I think it's
about usage of some services.

as mentioned earlier I would expects documentation at the service
> interface itself.


Right.


> That platform uses DS to consume services is just an
> implementation detail and doesn't bother the provider much.
>

Actually, it's the most important part IMO. The Platform usage of DS here
and there is the extensibility, it needs to be documented.

Such documentation then could of course use javadoc annotations that
> then could be present in the html output as well see
>
> https://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.8.1/examples/tag-configuration.html


I don't think we strongly need such specific javadoc annotations at the
moment. Specific annotations were not required for extension points, so I
don't think they should be necessary for services.

Concretely, I think we need a page similar to
https://help.eclipse.org/2021-03/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fextension-points%2Findex.html
but listing the service classes and their usage in some extensibility
contracts.
I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=572207 on that
matter. This is IMO critical that we get a "minimal viable product" of such
documentation before we start growing the extensibility of Platform via
services.
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Workspace location, properties and declarative services

[Ed Merks]

It sounds like a very sensitive area where even subtle changes in 
behavior (timing of events) are likely to be disruptive downstream...


What will be the net benefit from such a change from an end-user point 
of view as well as from and downstream developer point of view?  I.e., 
will something be faster or more flexible?  Will the platform be 
easier/cheaper to maintain?


I see this is related to the following bug.  There it talks about 
simplifying what the activator does:


  https://bugs.eclipse.org/bugs/show_bug.cgi?id=572128

Of course simplification is also a worthwhile goal...


On 22.03.2021 23:38, Alex Blewitt wrote:
I’m trying to migrate the Workspace initialisation from an Activator 
start() method to a Declarative Service in 
https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/178145 
 



Although this works if the workspace location has been set with a 
-data flag, it doesn’t work if the user decides to change the location 
later on. That’s because the IDEApplication prompts the user for a 
location in the org.eclipse.ui.ide bundle, which in turn, has a 
dependency on the org.eclipse.core.resources bundle that defines the 
workspace.


The following happens at startup:

* Equinox publishes an org.eclipse.services.datalocation.Location of 
type osgi.instance.area


https://github.com/eclipse/rt.equinox.framework/blob/1c00fefd63ceff66a96d66f578a30a5677864877/bundles/org.eclipse.osgi/container/src/org/eclipse/osgi/internal/framework/SystemBundleActivator.java#L178 



* IDEApplication prompts the user for a dialog, and then sets the 
instance location:


https://github.com/eclipse/eclipse.platform.ui/blob/b65540939ac72f0c57a7b2ed32235fcfc9471361/bundles/org.eclipse.ui.ide.application/src/org/eclipse/ui/internal/ide/application/IDEApplication.java#L313 



* This is ultimately accessible from 
Workspace->LocalMetaArea->Activator.installLocation


https://github.com/eclipse/rt.equinox.bundles/blob/e4e1bb43f2b17f84b39c6361e938bd9ae7e6e086/bundles/org.eclipse.equinox.common/src/org/eclipse/core/internal/runtime/Activator.java#L55 
 



The problem is that because the Location is published at startup, 
whether or not it has been set, it’s not trivial to configure to DS to 
set up a dependency to arrive when the value has been changed. It’s 
also not clear what should happen to configurations that use 
ResourcesPlugin but don’t use the IDEApplication.


The problem is that if we launch the Workspace with no dependencies, 
it will default to and initially set up) the default value, unless 
@noDefault is specified, in which case it will likely error out.


We could set up a dependency such that the Workspace only is launched 
when an osgi.instance.area Location is published, but Equinox will do 
this automatically unless the @noDefault is given.


Finally, we could publish a service/placeholder/Location in 
IDEApplication, which could be used to trigger the creation of the 
Workspace by DS.


Ultimately I think the only way of solving it is to either set the URL 
of the workspace as a service property of the location when it’s 
published, and when the URL is updated then update the service 
properties accordingly. Thus we could have the creation of the 
workspace dependent upon a service being published:


{org.eclipse.osgi.service.datalocation.Location}={type=osgi.instance.area}
=>
{org.eclipse.osgi.service.datalocation.Location}={type=osgi.instance.area,url=/path/to/workspace}

We could then set up the DS component for the Workspace to listen to a 
service filter that has the URL set as a property.


https://github.com/eclipse/rt.equinox.framework/blob/1c00fefd63ceff66a96d66f578a30a5677864877/bundles/org.eclipse.osgi/supplement/src/org/eclipse/osgi/service/datalocation/Location.java#L37 



Thoughts?

Alex

___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit