mirrors/cdt
1
0
Fork 0
mirror of https://github.com/eclipse-cdt/cdt synced 2025-07-05 16:15:25 +02:00
Code Issues Wiki Activity

[doc] Fix unnecessary broken links and redirects found by Linksleuth

Browse source
This commit is contained in:
Martin Oberhuber 2007-02-28 17:45:36 +00:00
parent 9f75eb674c
commit 9f9115b625
10 changed files with 101 additions and 101 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
releng/org.eclipse.rse.build/template/buildNotes.php
View file

@ -111,7 +111,7 @@ support in the future into internal packages.</p>
API changes on the RSE 1.0 maintenance stream (1.0.x), but we need to
change the API for TM 2.0 in a not backward compatible way.<br/>
All such API changes are voted on
by committers on the <a href="http://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev">
by committers on the <a href="https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev">
dsdp-tm-dev</a> developer mailing list, and documented in a migration guide
for future releases.</p>
<p>Currently, we see the following areas for more potential API changes:

2
rse/doc/org.eclipse.dstore.doc.isv/provisional_api.html
View file

@ -20,7 +20,7 @@ feedback and help further improving the APIs. Therefore,</p>
<p>This means, that we reserve the right to change any API after RSE 1.0
in a not backward compatible way. All such API changes will be voted on
by committers on the <a href="http://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev">
by committers on the <a href="https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev">
dsdp-tm-dev</a> developer mailing list, and documented in a migration guide
for future releases. We expect that with Community Feedback, we'll reach a
stable, hardened API for RSE 2.0. Please give your feedback on

2
rse/doc/org.eclipse.dstore.doc.isv/toc.html
View file

@ -27,7 +27,7 @@ feedback and help further improving the APIs. Therefore,</p>
<p>This means, that we reserve the right to change any API after RSE 1.0
in a not backward compatible way. All such API changes will be voted on
by committers on the <a href="http://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev">
by committers on the <a href="https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev">
dsdp-tm-dev</a> developer mailing list, and documented in a migration guide
for future releases. We expect that with Community Feedback, we'll reach a
stable, hardened API for RSE 2.0. Please give your feedback on

2
rse/doc/org.eclipse.rse.doc.isv/guide/rse_int.html
View file

@ -36,7 +36,7 @@ feedback and help further improving the APIs. Therefore,</p>
<p>This means, that we reserve the right to change any API after RSE 1.0
in a not backward compatible way. All such API changes will be voted on
by committers on the <a href="http://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev">
by committers on the <a href="https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev">
dsdp-tm-dev</a> developer mailing list, and documented in a migration guide
for future releases. We expect that with Community Feedback, we'll reach a
stable, hardened API for RSE 2.0. Please give your feedback on

156
rse/doc/org.eclipse.rse.doc.isv/guide/rse_int_architecture.html
View file

@ -1,78 +1,78 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
<meta name="copyright" content="Copyright (c) IBM Corporation and others 2005, 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="Content-Style-Type" content="text/css">
<link rel="STYLESHEET" href="../book.css" charset="ISO-8859-1" type="text/css">
<title>RSE Architecture</title>
<link rel="stylesheet" type="text/css" href="../book.css">
</head>
<body>
<h1>RSE Architecture</h1>
<p> The Remote System Explorer is structured into three major layors:</p>
<ul>
<li><A href="#Services">Service Layer</A></li>
<li><A href="#Subsystems">Subsystem Layer</A></li>
<li><A href="#UIs">UI Layer</A></li>
</ul>
<h2><A name="Services">RSE Service Layer</A></h2>
<p>
This is the headless, barebones API layer that is used to interact with different protocols to
provide remote services that can be integrated into RSE. By default, RSE defines the following
types of services:
<ul>
<li>File Service - for listing, modifying, copying, and transfering remote file and folders</li>
<li>Shell Service - for launching remote shells and interacting with the associated IO</li>
<li>Process Services - for listing remote processes</li>
</ul>
<p>
New service types can be added as needed, either in core RSE, or extensions to the base. The service
interfaces are defined loosely so that different implementations of the same service can be made using
different protocols. For example, the IFileService could be implemented locally with java.io, FTP, DataStore or some
other protocol. Similarly, the IShellService could be implemented locally via DataStore, telnet, SSH or something
else.
</p>
<h2><A name="SubSystems">RSE Subsystem Layer</A></h2>
<p>
RSE subsystems integrate the services of the service layer with connection information, model artifacts and persistence.
Each subsystem is associated with a single service type. For example, the file service subsystem is associated with the
file service. Each <a href="rse_int_subsystems.html">subsystem</a> is associated with one or more services from the service layer,
a <a href="rse_int_connectorservices.html">connector service</a> and, in some cases, a model adapter, which is used to
convert artifacts from the service layer into a form that is suitable for the subsystem layer.
</p>
<p>
Subsystems are contributed via the subsystem configuration extension point. A subsystem configuration is registered with
one or more system type (i.e. Local, Linux, Windows, etc.). When there is an RSE <a href="rse_int_hosts.html">host</a>
of a particular system type, the subsystem configurations that are registered with that system type are used to instantiate
and configure the subsystems for that host. Each subsystem configuration determines the subsystem to instantiate, the service
implementation, the connector service and anything else that requires customization for it's service.
</p>
<p>
Multiple subsystem configurations can exist for the same type of subsystem. This will be the case when there are more than
one protocols that can be used to implement the same service. For example, there are both FTP and DataStore implementations of
the IFileService. Subsystem configurations are contributed for both the FTP implementation and the DataStore one. In
such cases, only one subsystem is instantiated for each host, however that subsystem can have its configuration changed from FTP
to DataStore and vice versa.
</p>
<p>
Subsystems are RSE objects that are persistable and maintain higher level functionality from the service layer. Subsystems that
are used to query information on a host often have <a href="rse_int_filters.html">filters</a>. Filters provide the user the means to
specify a criteria for which to query a set of data. In addition to filters, there are more arbitrary properties that can be
associated with a subsystem, each of which can be saved and restored across sessions.
</p>
<h2><A name="UI">RSE UI Layer</A></h2>
<p>
The Remote System Explorer perspective provides views that render the subsystems and associated artifacts. Users can create
new connections, which can be expanded to reveal subsystems and the information the subsystems reveal about a system.
</p>
</body>
</html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
<meta name="copyright" content="Copyright (c) IBM Corporation and others 2005, 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="Content-Style-Type" content="text/css">
<link rel="STYLESHEET" href="../book.css" charset="ISO-8859-1" type="text/css">
<title>RSE Architecture</title>
<link rel="stylesheet" type="text/css" href="../book.css">
</head>
<body>
<h1>RSE Architecture</h1>
<p> The Remote System Explorer is structured into three major layors:</p>
<ul>
<li><A href="#Services">Service Layer</A></li>
<li><A href="#Subsystems">Subsystem Layer</A></li>
<li><A href="#UI">UI Layer</A></li>
</ul>
<A name="Services"></A><h2>RSE Service Layer</h2>
<p>
This is the headless, barebones API layer that is used to interact with different protocols to
provide remote services that can be integrated into RSE. By default, RSE defines the following
types of services:
<ul>
<li>File Service - for listing, modifying, copying, and transfering remote file and folders</li>
<li>Shell Service - for launching remote shells and interacting with the associated IO</li>
<li>Process Services - for listing remote processes</li>
</ul>
<p>
New service types can be added as needed, either in core RSE, or extensions to the base. The service
interfaces are defined loosely so that different implementations of the same service can be made using
different protocols. For example, the IFileService could be implemented locally with java.io, FTP, DataStore or some
other protocol. Similarly, the IShellService could be implemented locally via DataStore, telnet, SSH or something
else.
</p>
<A name="Subsystems"></A><h2>RSE Subsystem Layer</h2>
<p>
RSE subsystems integrate the services of the service layer with connection information, model artifacts and persistence.
Each subsystem is associated with a single service type. For example, the file service subsystem is associated with the
file service. Each <a href="rse_int_subsystems.html">subsystem</a> is associated with one or more services from the service layer,
a <a href="rse_int_connectorservices.html">connector service</a> and, in some cases, a model adapter, which is used to
convert artifacts from the service layer into a form that is suitable for the subsystem layer.
</p>
<p>
Subsystems are contributed via the subsystem configuration extension point. A subsystem configuration is registered with
one or more system type (i.e. Local, Linux, Windows, etc.). When there is an RSE <a href="rse_int_hosts.html">host</a>
of a particular system type, the subsystem configurations that are registered with that system type are used to instantiate
and configure the subsystems for that host. Each subsystem configuration determines the subsystem to instantiate, the service
implementation, the connector service and anything else that requires customization for it's service.
</p>
<p>
Multiple subsystem configurations can exist for the same type of subsystem. This will be the case when there are more than
one protocols that can be used to implement the same service. For example, there are both FTP and DataStore implementations of
the IFileService. Subsystem configurations are contributed for both the FTP implementation and the DataStore one. In
such cases, only one subsystem is instantiated for each host, however that subsystem can have its configuration changed from FTP
to DataStore and vice versa.
</p>
<p>
Subsystems are RSE objects that are persistable and maintain higher level functionality from the service layer. Subsystems that
are used to query information on a host often have <a href="rse_int_filters.html">filters</a>. Filters provide the user the means to
specify a criteria for which to query a set of data. In addition to filters, there are more arbitrary properties that can be
associated with a subsystem, each of which can be saved and restored across sessions.
</p>
<A name="UI"></A><h2>RSE UI Layer</h2>
<p>
The Remote System Explorer perspective provides views that render the subsystems and associated artifacts. Users can create
new connections, which can be expanded to reveal subsystems and the information the subsystems reveal about a system.
</p>
</body>
</html>

30
rse/doc/org.eclipse.rse.doc.isv/guide/rse_int_filters.html
View file

@ -1,15 +1,15 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
<meta name="copyright" content="Copyright (c) IBM Corporation and others 2005, 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="Content-Style-Type" content="text/css">
<link rel="STYLESHEET" href="../book.css" charset="ISO-8859-1" type="text/css">
<title>RSE Hosts</title>
<link rel="stylesheet" type="text/css" href="../book.css">
</head>
<body>
<h1>RSE Filters</h1>
</body>
</html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
<meta name="copyright" content="Copyright (c) IBM Corporation and others 2005, 2007. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="Content-Style-Type" content="text/css">
<link rel="STYLESHEET" href="../book.css" charset="ISO-8859-1" type="text/css">
<title>RSE Filters</title>
<link rel="stylesheet" type="text/css" href="../book.css">
</head>
<body>
<h1>RSE Filters</h1>
</body>
</html>

2
rse/doc/org.eclipse.rse.doc.isv/guide/tutorials.html
View file

@ -18,7 +18,7 @@ extend the RSE:
<li><a href="tutorial/subsystem.html">Creating a subsystem configuration</a> for working with remote resources, using the <a href="plugin/subsystem.html">org.eclipse.rse.core.subsystemConfigurations</a> extension point.
</ul>
<p>The source code for all tutorials is available in the RSE-examples package, which
can be obtained from the DSDP <a href="http://download.eclipse.org/dsdp/tm/downloads">
can be obtained from the DSDP <a href="http://download.eclipse.org/dsdp/tm/downloads/">
Target Management download site</a> or directly from the RSE <b>Update Site</b>. In fact,
the simplest way to get the examples is to choose <I>Help &gt; Software Updates &gt;
Find and Install</I> from the Workbench, get the Examples installed, and then choose

2
rse/doc/org.eclipse.rse.doc.isv/guide/usingAPIs.html
View file

@ -42,7 +42,7 @@ feedback and help further improving the APIs. Therefore,</p>
<p>This means, that we reserve the right to change any API after RSE 1.0
in a not backward compatible way. All such API changes will be voted on
by committers on the <a href="http://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev">
by committers on the <a href="https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev">
dsdp-tm-dev</a> developer mailing list, and documented in a migration guide
for future releases. We expect that with Community Feedback, we'll reach a
stable, hardened API for RSE 2.0. Please give your feedback on

2
rse/doc/org.eclipse.rse.doc.isv/options.txt
View file

@ -52,7 +52,7 @@
-bottom "Copyright (c) IBM Corporation and others 2000, 2006. All Rights Reserved."
-group "RSE Core Plug-in Packages" "org.eclipse.rse.core;org.eclipse.rse.core.*"
-group "RSE UI Plug-in Packages" "org.eclipse.rse.ui;org.eclipse.rse.ui.*"
-link http://java.sun.com/j2se/1.5/docs/api
-link http://java.sun.com/j2se/1.4.2/docs/api
-linkoffline ./../../../org.eclipse.platform.doc.isv/reference/api @javadoc.link.location@/platform/reference/api/
-linkoffline ./../../../org.eclipse.dstore.doc.isv/reference/api ../org.eclipse.dstore.doc.isv/reference/api
-link http://bundles.osgi.org/javadoc/r4

2
rse/doc/org.eclipse.rse.doc.isv/provisional_api.html
View file

@ -20,7 +20,7 @@ feedback and help further improving the APIs. Therefore,</p>
<p>This means, that we reserve the right to change any API after RSE 1.0
in a not backward compatible way. All such API changes will be voted on
by committers on the <a href="http://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev">
by committers on the <a href="https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev">
dsdp-tm-dev</a> developer mailing list, and documented in a migration guide
for future releases. We expect that with Community Feedback, we'll reach a
stable, hardened API for RSE 2.0. Please give your feedback on