FacetedProject question [message #229472] |
Tue, 24 March 2009 20:37 |
Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
While trying to call FacetedProject.modify() from a Job, I noticed that
method uses the workspace root as a scheduling rule. This means that it
is locking the entire workspace.
In an effort to be a Jobs API good citizen, my Job uses the project
being modified as its scheduling rule. But this causes an error when
FacetedProject.modify() tries to obtain the root lock.
final IWorkspace ws = ResourcesPlugin.getWorkspace();
ws.run( wr, ws.getRoot(), IWorkspace.AVOID_UPDATE, monitor );
The only workaround I can come up with is to either specify the root as
the rule for my own Job, or speficy no rule at all.
Is it intentional and necessary to be so broad in the
FacetedProject.modify() code?
This is the Ganymede version of WST (1.3.x of the
org.eclipse.est.common.facet.core plugin).
Eric
|
|
|
|
Re: FacetedProject question [message #229666 is a reply to message #229495] |
Thu, 26 March 2009 13:48 |
Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
On 3/25/2009 6:48 AM, Konstantin Komissarchik wrote:
>> Is it intentional and necessary to be so broad in the
>> FacetedProject.modify() code?
>
> This API does take a pretty conservative position on purpose. The issue
> is that many of the facet action delegates reach out to other projects
> as part of their operation. You could argue that you know a little bit
> more about what's going on when you make the modify call manually
> (rather than by using the standard facets property page or the wizard).
> Maybe you know a little bit about implementation of facets you are
> trying to install. But even in that case, it is possible for a third
> party to have various listeners like PRE_INSTALL and POST_INSTALL
> registered that you may not be aware of. If those reach out to other
> projects, a project-scoped job will will fail.
>
> Maybe there is a clever way to safely handle such situations with Jobs
> API, but sometimes simple is the answer. :)
I wonder if using null as the scheduling rule would be a better simple
strategy.
Hmm, maybe not; looking at the comments for IWorkspace.run(), they say:
"If no scheduling rule is supplied, then any attempt to change resources
will fail."
That seems different than the contract for Job, which works fine even
with a null IScheduling rule. I wonder why the discrepancy - but that is
a question for eclipse.platform, I suppose...
> PS: Are you at EclipseCon? I'd love to buy you a beer if you are here.
Sadly, I'm not. It is quite bittersweet for me to read all the blogging
about it; on one hand I'm glad to have lots of perspectives on the
conference, but on the other hand each blog post I read makes me even
more disappointed about not being there
:-( :-)
Thanks for the offer, though. Maybe next year... or if you're ever in
Florida, look me up.
Eric
|
|
|
Powered by
FUDForum. Page generated in 0.03842 seconds