This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Headliner task for the remote development features being added to NB 6.5 for C and C++. See http://wiki.netbeans.org/NB65EngineeringPlan#section-NB65EngineeringPlan-CC for (a few more) details.
*** 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:-)