*** Issue 135839 has been marked as a duplicate of this issue. ***

A brief description copied from #136323, which I'm now closing as dup:

It should be possible to run IDE on a users desktop (most likely Windows or Linux), but to build, run and debug
applications on a server that has another architecture (say, Solaris on Sparc or x86).

*** Issue 136452 has been marked as a duplicate of this issue. ***

where does it say anything in http://wiki.netbeans.org/NB65EngineeringPlan#section-NB65EngineeringPlan-CC about remote
debugging a similar way such using gdbserver ?

Why not use gdbserver ? everything is already there, I believe it would only require minor changes to the UI, not ?

My problem with a gdbserver solution is that its a partial solution to remote development.
It handles debugging, but does not handle building or running (without the debugger). I'm
looking at something which deals with all of that.

The current plan is to use OpenSSH and we'll need to run remote commands that way. So
running gdb via OpenSSH fits with the overall model. Running it with gdbserver doesn't.

Another issue I have with a gdbserver solution is that we have to support more versions of
gdb than I like and on more platforms. At least 1 platform (Solaris) doesn't come with easy
access to gdbserver (gdb is optional on Solaris, and easy to find/install, the same is not
true with gdbserver).

In reference to the project plan, I plan on updating it today and/or tomorrow. The project
has just started and current plan information was provided by my manager, not by any of
the developers doing the project (2 or 3). So look back in a day or two and the project
plan should be more complete.

Project documentation:
    Project definition: http://wiki.netbeans.org/CndDistributedDevelopment
    User views: http://wiki.netbeans.org/CndNb65UserViewRemoteDevelopment2
    Remote Development Design Spec: http://wiki.netbeans.org/CndNb65RemoteDevelopmentDesignSpec

It would be nice if the remote development architecture you develop / support is / becomes compatible with current work 
in this area done by the (community partner) HP Distributed NetBeans team 
(http://h71000.www7.hp.com/openvms/products/ips/netbeans).  Their target server platform is OpenVMS, where rexec'ing is 
comparatively expensive, so they implement a persistent server that gets passed remote development commands for the 
duration of the NetBeans user's remote development session.

I trongly concur with an SSH-based client / server implementation, as cleartext client / server channels are 
increasingly hard to get approved for use by network security folks at the customers I develop for.  The HP Distributed 
NB client / server architecture uses Java RMI, but that doesn't tunnel so well because of RMI's embedding of client IP 
addressing (NATting firewall-unfriendly)and its dynamic port-usage.

Current Status: Most major features are working fairly well. We haven't added much failure checking
and things like unknown hosts tend to mess us up. On a sub-feature by sub-feature basis:

    Run - With the limitation that we require running with Console Type set to Output Window, we
          do a pretty complete job of this.
    Build - There are various bugs in our remote compiler set management which we're still working
          on. Build output also doesn't have paths mapped from the remote host path to the local
          host path (ie, if running on Windows to a Unix server, you'll see the Unix path rather than
          the equivalent Windows path).
    Debug - This is almost completely broken. It should get fixed this week (at least to the point of
          minimal debugging).
    Edit - Basic editing is a NetBeans feature and works fine. The Code Assistance we add depends on
          the remote compiler set management and is subject to the problems we're seeing there. But if
          setup correctly, (I think :-) its working.

There are various exceptions and miscelaneous failures. We've handed off to QA this week and that should
get us a better idea of our current quality. Bugs for this feature are filed in IZ under category "cnd"
and subcategory "remote" (although some remote issues will probably be filed in other subcategories).

The feature is implemented (with bugs:-)