Re: [platform-team-dev] ResourceRuleFactory.modifyRule()

[Michael Valenta <Michael_Valenta@xxxxxxxxxx>]

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