| Trigger | Kind | diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resAdv_concurrency.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resAdv_concurrency.htm index d43b3bdbd4c..b1f0832a553 100644 --- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resAdv_concurrency.htm +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resAdv_concurrency.htm @@ -1,12 +1,9 @@ - + - - - - +
|---|
|
@@ -167,7 +170,7 @@ Resource Change Events |
|---|
Implementing a Resource Change Listener
+Implementing a Resource Change Listener
The following example implements a console-based resource change listener. A resource change listener is registered for specific types of events and information about these events is printed to the console: diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resAdv_hooks.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resAdv_hooks.htm index 59c32e2dc33..c1e0add7135 100644 --- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resAdv_hooks.htm +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resAdv_hooks.htm @@ -1,12 +1,9 @@ - +
- - - - +
-
+
Extending the platform with new marker types
Plug-ins can declare their own marker types using the org.eclipse.core.resources.markers diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resAdv_modify.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resAdv_modify.htm index 61115a7ec07..51ee9cda89d 100644 --- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resAdv_modify.htm +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resAdv_modify.htm @@ -1,12 +1,9 @@ - +
- - - - +
to determine whether a particular resource is in synch with the file system.
-
+
Mapping resources to disk locations
In the sample resource tree, we've assumed that all of the project content directories are diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resInt_filters.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resInt_filters.htm index 4a597e4c08d..fdf6d0532cb 100644 --- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resInt_filters.htm +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/resInt_filters.htm @@ -1,12 +1,9 @@ - +
- - - - +workspace root. Each node (other than the root) is one of the three kinds of resources, and each has a name that is different from its siblings.
-
+
diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime.htm index e0b293445ff..cca7bb8afe5 100644 --- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime.htm +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime.htm @@ -1,12 +1,9 @@ - +
- - - - +The acquire() method will not return until the calling job can be granted exclusive access to the lock.
In other words, if some other job has already acquired the lock, then this code will be blocked until the lock
is available. Note that the code that acquires the lock and manipulates myObject is wrapped in
-a try block, so that the lock can be released if any exceptions occur while working with the object.
+a try block, so that the lock can be released if any exceptions occur while working with the object.
Seems simple enough, right? Fortunately, locks are pretty straightforward to use. They are also reentrant, which means you don't have to worry about your job acquiring the same lock multiple times. Each lock keeps a count of the diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_jobs_progress.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_jobs_progress.htm index b8c3d1feba1..953d39a6815 100644 --- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_jobs_progress.htm +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_jobs_progress.htm @@ -1,18 +1,14 @@ - +
- - - +Reporting Progress
@@ -28,7 +24,7 @@
cancellation requests made from the progress view. When a user (or
plug-in using job API) attempts to cancel a job, the IProgressMonitor
-method isCanceled() will return true. It is the job's
+method isCanceled() will return true. It is the job's
responsibility to frequently
check the cancellation status of a job and respond to a cancellation by
exiting the run method as soon as possible once it detects a
diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_jobs_rules.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_jobs_rules.htm
index d714bf550cd..5b3b7cc913d 100644
--- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_jobs_rules.htm
+++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_jobs_rules.htm
@@ -1,12 +1,9 @@
-
+
-
-
-
-
+
Scheduling rules
@@ -68,11 +65,11 @@
How can that be? We told the light to turn on and then off, so its final state
should be off! The problem is that there was nothing preventing the
-LightOff job from running at the same time as the LightOn
+LightOff job from running at the same time as the LightOn
job. So, even though the "on" job was scheduled first, their
concurrent execution means that there is no way to predict the exact
-execution order of the two concurrent jobs. If the LightOff job ends
-up running before the LightOn job, we get this invalid result.
+execution order of the two concurrent jobs. If the LightOff job ends
+up running before the LightOn job, we get this invalid result.
What we need is a way to prevent the two jobs from running concurrently, and
that's where scheduling rules come in.
@@ -109,7 +106,7 @@
Now, when the two light switch jobs are scheduled, the job infrastructure will
-call the isConflicting method to compare the scheduling rules of the
+call the isConflicting method to compare the scheduling rules of the
two jobs. It will notice that the two jobs have conflicting scheduling rules, and
will make sure that they run in the correct order. It will also make sure they never
run at the same time. Now, if you run the example program a million times,
@@ -122,7 +119,7 @@
Rules can also be used independently from jobs as a general locking mechanism.
The following example acquires a rule within a try/finally block, preventing other
threads and jobs from running with that rule for the duration between
-invocations of beginRule and endRule.
+invocations of beginRule and endRule.
IJobManager manager = Job.getJobManager();
try {
manager.beginRule(rule, monitor);
@@ -133,7 +130,7 @@
You should exercise extreme caution when acquiring and releasing scheduling rules using such a coding pattern. If you fail to end a rule for which you -have called beginRule, you will have locked that rule forever.
+have calledbeginRule, you will have locked that rule forever.
Making your own rules
Although the job API defines the contract of scheduling rules, it does not actually @@ -143,36 +140,36 @@
Making your own rules
thread can be created to run it.
When a job does have a scheduling rule,
-the isConflicting method is used to determine if the rule conflicts with
+the isConflicting method is used to determine if the rule conflicts with
the rules of any jobs that are currently running. Thus, your implementation
-of isConflicting can define exactly when it is safe to execute your job.
-In our light switch example, the isConflicting implementation simply uses
+of isConflicting can define exactly when it is safe to execute your job.
+In our light switch example, the isConflicting implementation simply uses
an identity comparison with the provided rule. If another job has the identical rule,
they will not be run concurrently. When writing your own scheduling rules, be
-sure to read and follow the API contract for isConflicting carefully.
isConflicting carefully.
If your job has several unrelated constraints, you can compose multiple scheduling rules together using a MultiRule. For example, if your job needs to turn on a light switch, and also write information to a network socket, it can have a rule for the light switch and a rule for write access to the socket, -combined into a single rule using the factory method MultiRule.combine.
+combined into a single rule using the factory methodMultiRule.combine.
Rule hierarchies
-We have discussed the isConflicting method on
+We have discussed the isConflicting method on
ISchedulingRule,
-but thus far have not mentioned the contains method. This method is
+but thus far have not mentioned the contains method. This method is
used for a fairly specialized application of scheduling rules that many clients will not require.
Scheduling rules can be logically composed into hierarchies for controlling access to
naturally hierarchical resources. The simplest example to illustrate this concept is
a tree-based file system. If an application wants to acquire an exclusive lock
on a directory, it typically implies that it also wants exclusive access to the files
-and sub-directories within that directory. The contains method is
+and sub-directories within that directory. The contains method is
used to specify the hierarchical relationship among locks. If you do not need
-to create hierarchies of locks, you can implement the contains method
-to simply call isConflicting.
contains method
+to simply call isConflicting.
-Here is an example of a hierarchical lock for controlling write access to java.io.File handles.
+Here is an example of a hierarchical lock for controlling write access to java.io.File handles.
public class FileLock implements ISchedulingRule {
private String path;
@@ -202,17 +199,17 @@ Rule hierarchies
}
}
-The contains method comes into play if a thread tries to acquire +
The contains method comes into play if a thread tries to acquire
a second rule when it already owns a rule. To avoid the possibility of deadlock,
any given thread can only own one scheduling rule at any given time.
-If a thread calls beginRule when it already owns a rule, either through
-a previous call to beginRule or by executing a job with a scheduling rule,
-the contains method is consulted to see if the two rules are equivalent.
-If the contains method for the rule that is already owned returns true,
-the beginRule invocation will succeed. If the contains method returns
-false an error will occur.
beginRule when it already owns a rule, either through
+a previous call to beginRule or by executing a job with a scheduling rule,
+the contains method is consulted to see if the two rules are equivalent.
+If the contains method for the rule that is already owned returns true,
+the beginRule invocation will succeed. If the contains method returns
+false an error will occur.
-To put this in more concrete terms, say a thread owns our example FileLock
+To put this in more concrete terms, say a thread owns our example FileLock
rule on the directory at "c:\temp". While it owns this rule, it is only allowed
to modify files within that directory subtree. If it tries to modify files in other directories that
are not under "c:\temp", it should fail. Thus a scheduling rule is a
diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_jobs_scheduling.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_jobs_scheduling.htm
index d8e9e4e782c..e8df7dbc248 100644
--- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_jobs_scheduling.htm
+++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_jobs_scheduling.htm
@@ -1,12 +1,9 @@
-
+
Custom Scheduling Conditions
}The shouldSchedule method is called just before the job manager places the job in the queue. This allows the job
-to cancel itself if basic preconditions for scheduling are not met. The job should return false it
+to cancel itself if basic preconditions for scheduling are not met. The job should return false it
is inappropriate to schedule it. Likewise, the shouldRun method is called just before the job manager
runs the job. Any additional conditions that must be met before the job is run must be checked at this time.
the need for this information and the protocol for getting it.
Recall the workbench Show View dialog which shows all of the available views that have been installed in the platform.
-
+
We know that the category names and view names of all contributed views are specified in the plugin.xml file for any plug-in that contributes an extension for org.eclipse.ui.views. diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team.htm index 434be1851ad..25e62620bd4 100644 --- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team.htm +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team.htm @@ -1,16 +1,14 @@ - +
- - - +Version Control (Team) Support
The Eclipse version control support, via the team plug-ins, defines API that allow plug-ins to integrate the function of a versioning and configuration management diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_howto.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_howto.htm index ff3e0007c77..4008381a863 100644 --- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_howto.htm +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_howto.htm @@ -1,18 +1,20 @@ - +
- - - +Rich Team Integration
Integrating your repository's support with the platform starts with @@ -43,14 +45,14 @@
Rich Team Integration
with and links for information (both team-specific and workbench-oriented) on these topics.Getting Started
-| Define a + | Define a RepositoryProvider that represents your implementation. | -+ |
Getting Started |
| Provide a configuration wizard so that users can + | Provide a configuration wizard so that users can associate your provider with their projects. | -+ |
Getting Started |
| Add your actions to the Team menu. | -+ | Add your actions to the Team menu. | +
Getting Started |
Enhancing Resource Views
-| Add provider-specific properties to the + | Add provider-specific properties to the properties page for a resource. | -+ |
Enhancing Resource Views |
| Implement specialized decorators to show + | Implement specialized decorators to show team-related attributes | -+ |
Enhancing Resource Views |
| Reduce clutter by filtering out any resources + | Reduce clutter by filtering out any resources that are used in implementing team support. | -+ |
Enhancing Resource Views |
Handling User Editing and Changes to Resources
-| Intervene in the saving of resources so you can + | Intervene in the saving of resources so you can check permissions before a user changes a file. | -+ |
Handling User Editing and Changes to Resources |
| Intervene before a user edits a file to see if + | Intervene before a user edits a file to see if it's allowed. | -+ |
|
| Track changes to resources in the workspace so + | Track changes to resources in the workspace so you can allow associated changes in the repository. | -+ |
Handling User Editing and Changes to Resources |
| Enable the use of linked resources. | -+ | Enable the use of linked resources. | +
Handling User Editing and Changes to Resources |
Streamlining Repository-related Tasks
-| Provide an easy way to export a description of + | Provide an easy way to export a description of your projects. | -+ |
|
| Reduce clutter in the repository by ignoring + | Reduce clutter in the repository by ignoring files that can be regenerated. | -+ |
|
Enhancing Platform Integration
-| Add provider-specific preferences to the + | Add provider-specific preferences to the preferences page. | -+ |
Enhancing Platform Integration |
|
| Implement custom views to show detailed + | Implement custom views to show detailed information about repositories or their resources. | -+ |
Enhancing Platform Integration |
|
| Add your views or actions to existing workbench + | Add your views or actions to existing workbench perspectives if appropriate. | -+ |
|
|
| Implement a repository-specific perspective to + | Implement a repository-specific perspective to streamline repository administration or browsing. | -+ |
Model-based Merging+Model-based MergingWhen a Team provider is attempting a headless merge, it will do the following: @@ -341,7 +338,7 @@Model-based Mergingprovider when they are done. -Model Content in Team Operation Views+Model Content in Team Operation ViewsThe display of model elements in the context of a Team operation is made possible by the Common Navigator framework. @@ -378,7 +375,7 @@Model Content in Team Operation Viewsprovider's elements in the merge preview.History View+History ViewThe following improvements have been made in the area of file history and model element history: @@ -399,7 +396,7 @@History Viewoperations. -Remote Browsing+Remote BrowsingThe following has been provided to support remote browsing: -Decorating Model Elements with Team State+Decorating Model Elements with Team StateTeam providers can decorate model elements by converting their lightweight decorators to work for resource mappings in the same way @@ -435,7 +432,7 @@ Decorating Model Elements with Team Stateof resource has changed and can be passed to a team decorator as part of anIDecorationContext.
-Using the Saveable API+Using the Saveable API
Logical model providers may use the Showing the History of Sub-file Elements+Showing the History of Sub-file ElementsThe Showing the History of Sub-file Elementsreplacing the current element with an element from the history. -Grouping Related Changes+Grouping Related ChangesModel providers that wish to ensure that changes to sets of resources are committed or checked-in to a repository together can subclass the diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_model_repo.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_model_repo.htm index 7a3973bc2d1..b1cca36378f 100644 --- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_model_repo.htm +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_model_repo.htm @@ -1,17 +1,14 @@ - + - - - +Repository Roadmap for Logical Model Integration@@ -66,7 +63,7 @@Repository Roadmap for Logical Model Integration-Contributing Actions to Resource
+ |
+
+
-
-
-
+
Local History ExampleThe best way to understand the Synchronize APIs is to create a simple example that actually works. In this example we will be creating a page in the Synchronize diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_ui_actions.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_ui_actions.htm index 37690006cf0..cc333ad4f86 100644 --- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_ui_actions.htm +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_ui_actions.htm @@ -1,12 +1,9 @@ - + - - - - +Team Decorators(e.g. the
symbol indicates that the resource is managed by CVS).
-
-
-
-
Some decorators may be expensive to compute, so it's a good idea to allow the users some control over the use, or even content, of decorators. The CVS client provides a preference page that allows users to control the presentation and content of decorators. - - -See org.eclipse.ui.decorators for a complete description of the decorator extension point. The CVS decorator markup is as follows: diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_ui_history.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_ui_history.htm index b0fd58d4f5b..098408ab35e 100644 --- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_ui_history.htm +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/team_ui_history.htm @@ -1,12 +1,9 @@ - + - - - - +Adding Preferences and Properties- - - - |
+