Difference between revisions of "TM and RSE FAQ"

Revision as of 22:42, 26 November 2006

Nav: DSDP/TM | TM and RSE FAQ | RSE 1.0 Known Issues and Workarounds

Introduction

How do I contribute to this FAQ?

Simply edit this page and add content. You can now use your bugzilla username and password to gain access.

How can I get notified of additions to that FAQ?

Log in to the Wiki. On your personal Preferences page, enable E-Mail notification. Then, click the watch tab of this page.

Is it really that easy?

Yes!

General

What is the Target Management Project?

It's all about remote computer systems (targets, hosts, boards, grids, farms, nodes...) and developing software on them: remote build, connect, get status, download, run, debug, ...

Since there are many different vendors and solutions around for remote access and especially in the device software space, the main charter of target management is to provide data models and frameworks that are flexible and open enough for vendor-specific extensions. Sample implementations are being provided for TCP/IP connections, FTP data transfer and gdb remote launching in the CDT environment. The basis for our implementations is the Remote System Explorer (RSE).

For a more official answer, see the Target Management Project Homepage.

What is RSE?

The Remote System Explorer (RSE) is a consistent framework and UI for accessing remote compute resources from Eclipse.

So what is the difference between TM and RSE?

The Target Management Project works in two repositories:

• org.eclipse.tm.core - Core Components for remote access that can be re-used without other dependencies. Currently, these include Jakarta Commons/Net, Zeroconf Discovery and a Terminal view.
• org.eclipse.tm.rse - The Remote System Explorer (RSE).

We are delivering RSE for download, which integrates some (but currently not all) core components into a consistent framework and UI. TM is the "project", RSE is the "product".

How is RSE licensed?

RSE consists of software produced by the TM / RSE team combined with third party software developed from other Open Source Projects. The software produced by the TM / RSE team is licensed under the Eclipse Public License (EPL). The software designed by third parties is made available under their respective licenses. Refer to the about.html file in the root directory of every RSE plugin for specific licensing information.

How do I find out about future releases of RSE?

See the RSE 2.0 Planning page.

If you wish to contribute to the development of RSE, we welcome the opportunity to work with you. The plans will be updated to reflect the commitments made by contributors to this projects. See #Working on RSE for information on how to get started.

Download and Installation

Which RSE build should I download?

The latest stable release version is available from the TM downloads page.

Which operating systems does RSE support?

The RSE Framework is platform independent. It will run where Eclipse will run. According to the TM Project Plan, we are testing on a set of Reference Platforms including Windows, Linux, MacOS X and Solaris.

For the remote side, we are testing the following combinations:

• The remote dstore agent is being tested on Windows, Linux and Solaris but should also run fine on any OS that supports a Java 1.4 VM or later. There are known implementations on AIX, OS/390, and z/OS.
• FTP is being tested against many public available servers including Windows, Linux, FileZilla, ProFTPD, and VxWorks. VMS based servers are known to have problems bug 161238.
• Ssh works against any ssh2 compliant server.

See also the test matrix on the RSE 1.0 Testing pages and below.

If you are using on a platform not mentioned here, please make yourself heard on the dsdp-tm-dev developer mailing list. You can contribute test results there.

If you have a favorite platform we highly encourage you to get involved and volunteer to own a feature that does not currently have an implementation that works on your platform of choice. See #Working on RSE for more information.

How do I ask questions?

Target Management and RSE related questions that are not answered in this FAQ or the documentation should be posted to the TM newsgroup. You will need a newsreader and a password. You can also use this simple web interface or this more advanced web interface to browse the newsgroup. General Questions about the Eclipse SDK which includes the Eclipse Platform, JDT (Java Development Tools), or PDE (Plugin Development Environment) should be posted to the Eclipse newsgroup.

Keep in mind that these newsgroups are public, so do not include any confidential information in your questions. You should also read "How to ask questions the smart way" by Eric Raymond before participating in the newsgroups. NOTE: Please submit bugs to bugzilla, not to the newsgroups. #How do I report a bug or request a feature? section of this document.

People will still come into a newsgroup asking questions that have been answered before and often will not provide any information about what versions they have installed, and what the problem is. You will be much more likely to get help if you provide enough information to reproduce the problem. The section on [[#how to report a bug] gives a list of some information which could be useful.

How do I report a bug or request a feature?

The Target Management Project and RSE (like the Eclipse Project) uses bugzilla as its bug and feature tracking system. Around, this, we have developed some queries and best practices on the TM Bug Process Page.

Entering a bug/feature report is as simple as filling in a web form on the eclipse bugzilla page. The first time you enter a bug you will need to create a new bugzilla account for yourself by providing an email address and choosing a password.

Before entering a bug report, you should search bugzilla to see if someone else has already entered a bug report similar to yours. If you find a bug report that outlines the problem you are seeing, you can simply annotate it with your comments to let the developers know that you have also hit the bug. Also you can add yourself to the CC list of the bug so that you will notified when the status of the bug changes or someone adds comments.

Once you have searched bugzilla and not found anything, you can go ahead and enter a new bug report. Please read the bug writing guidelines located on the eclipse bug reporting page.

To make your bug report more helpful include the following in your bug reports:

Environmental settings:

1. The build level of Eclipse that you are using. For example, "Eclipse 3.2.1"

2. The build level of RSE that you are using. For example, "RSE 1.0 build I20061104"

3. Your computer's specifications (OS version + patch level, memory, other pertinent info)

4. The contents of your .log file (or lack thereof). This is especially important if you get a dialog that reports an internal error. See What is this .log file I hear so much about? for information on finding your .log file.

5. The Java runtime or development kit you are using to run eclipse (use java -version or java -fullversion)

Problem Description:

1. A description of what you were doing,

2. A description of what behavior that you observed, and

3. An explanation of how the observed behavior differs from the expected behavior

Where is this .log file that I hear so much about?

The .log file is located in the workspace/.metadata directory.

The .log file is used by the Eclipse Platform to log runtime errors. It is useful to include it in bug reports because it contains stack traces that occur in plug-ins. When you report a bug, make sure to include your .log file!

Working on RSE

How do I build RSE from CVS if I want a more recent build than is on the downloads page?

Start Eclipse SDK, and import a CVS Team Project Set as explained on the TM CVS Setup page.

How do I export it so that it can be used with an external Eclipse installation?

You can either:

a) Export an RSE feature via File->Export->Plugin Development->Deployable Features. This will automatically export all the required plugins.

b) Export all the plugins etc. individually or all at once via File->Export->Plugin Development->Deployable Plugins and Fragments. However, this is more error prone and you're better off doing a).

c) Use the ANT stuff in org.eclipse.tm.rse/releng to build RSE the way the nightly build does.

How do I use eclipse to develop eclipse?

The self-hosting instructions explain how to use eclipse to develop eclipse.

• If you want to work with the current version of the eclipse code, you will need to connect to the Eclipse Project CVS repository. To connect to the Eclipse Project CVS repository, open the CVS repositories view (Perspective->Show View->Other...->CVS->CVS Repositories) and create a new CVS repository location (right click->New->CVS Repository Location. Paste the following information into the "Add CVS Repository" dialog, "Host" field:

•  :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse

NOTE: When you are connected as anonymous you will have read rights to the repository, but you will not be able to commit any code.

How do I modify the code

Change any file you want. When you save it, it will be built.

How do I run with my changes?

After successfully building RSE inside Eclipse, one typically wants to run an instance of Eclipse with the freshly built plugins (perhaps after making some changes to the source code). This is very easy to do in the PDE. Here are the steps:

1. Open the "Plug-in Development" perspective (you may have to go to "Others" to find it).

2. Select the menu action Run -> Run As... -> Run-time workbench.

3. You may also use the drop down on the debug icon, select Run-time workbench

How do I submit a fix for a bug?

While using the Eclipse SDK to develop your plug-in, you found a bug in RSE. You submitted a bug report, but need the fix now. You've debugged the problem, and there is a simple fix. So you figured out how to use eclipse to develop eclipse and have written a fix for the bug you found. Now you want to release the fix to the eclipse community. How do you do this?

First, create a patch. You can create a patch by using the Team patch creation facility.

1. Select the project you have patched. It must be connected to the CDT CVS repository.

2. Right click->Team->Create Patch...

3. The Create Patch wizard will prompt you for a file name. You should name your patch with the bugzilla bug report id.

Now you can submit the patch to the appropriate component developer mailing list. Be sure to include information about what your patch fixes. The committers for the component will evaluate your patch to see if it fixes the bug and is acceptable. If your patch is accepted, it will be released by the component team into the repository.

How do I distribute my changes to my customers?

Anyway that you see fit! Actually, if anybody has suggestions for this answer, please fill them in here.