[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-team-dev] ResourceRuleFactory.modifyRule()
|
Thanks Michael, the "team" package segment made me
think it was a team component. Seems that many team providers are
affected by this change anyway. The link to the related bug is also
helpful. Will file a bug under resources to correct javadoc as you
suggest.
~Vladimir.
Vladimir, The API in questions comes from the Resources plug-in.
Basically, in 3.2, the modifyRule for a project had to be expanded to the
workspace root to accomodate certain types changes made to the project
description that require other projects to be locked. This does not appear to be
reflected in the javadoc. Perhaps you could log a bug report against
Platform/Resources requesting that the javadoc be improved. As for the issue of whether it is safe to use the project
rule, it depends on what kind of modifications you are doing to the project. You
need to be careful since the default rule factory determines the smallest
possible rule scope (i.e. subclasses provided by repository providers can use
the rule of the parent or a wider rule). I would say that if you are creating or
opening a project or changing its description, you should use the modify rule.
However, if you are modify resources in the project, a finer grained rule that
corresponds to the operation you are performing could be used.
Also, you may be interested in bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=128709 which requsts a new rule
factory method specific to project opening. Michael
"Vladimir Grishchenko"
<vladgri@xxxxxxxxxxx> Sent by: platform-team-dev-bounces@xxxxxxxxxxx
13/02/2007 01:46 PM
Please respond
to Generic team support framework
<platform-team-dev@xxxxxxxxxxx> |
|
To
| <platform-team-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| [platform-team-dev]
ResourceRuleFactory.modifyRule() |
|
Hello,
Hope someone can shed some light here. In 3.2 the method in
subj returns
workspace root when supplied resource is a project while in
previous
releases it just returned the project itself. The javadoc for this
method is
somewhat misleading:
/**
* Default implementation
of
<code>IResourceRuleFactory#modifyRule</code>.
* This default implementation
returns the resource being modified,
or the
* parent resource if modifying a project
description file.
* Note that this must encompass any rule required by
the
<code>validateSave</code> hook.
* <p>
* Subclasses may override this method.
The rule provided by an
overriding
* method must at least contain the rule from this
default
implementation.
*
*
@see
org.eclipse.core.runtime.jobs.ISchedulingRule#contains(org.eclipse.core.runt
ime.jobs.ISchedulingRule)
*
@see
org.eclipse.core.resources.IResourceRuleFactory#modifyRule(IResource)
* @see
IFileModificationValidator#validateSave(IFile)
* @see
IProjectDescription#DESCRIPTION_FILE_NAME
*/
public ISchedulingRule modifyRule(IResource resource) {
//modifying the project description requires
the root
if (resource.getType() ==
IResource.PROJECT)
return workspace.getRoot();
IPath path = resource.getFullPath();
//modifying the project description may cause
linked
resources to be created or deleted
if (path.segmentCount() == 2
&&
path.segment(1).equals(IProjectDescription.DESCRIPTION_FILE_NAME))
return parent(resource);
return resource;
}
First it is incorrect in that it does not reflect the case when
the supplied
resource is a project. Second it suggests that all derived rule
factories
must be pessimistic in case of projects and essentially project
level
operations should lock the whole workspace according to the
current
implementation, is this intended?
My real question is if it is
safe to use project as a rule just like it was
in pre 3.2
releases.
Thanks and
regards,
Vladimir.
_______________________________________________
platform-team-dev
mailing
list
platform-team-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-team-dev