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.
[ JDK VERSION : 1.6.* ] bat/sh file editing has been moved to cnd cluster. This is against the sense of ergonomics cluster development, as for just editing some little files, the whole cnd cluster needs to be activated. As David Strupl pointed out, this has been done to bring it together with native execution support. However, if the whole support would be moved into its separate cluster, it could still be managed by cnd team, without creating unnessecary dependencies on cnd cluster.
David, my almost daily use case for editing .bat and .sh files in NetBeans is writing batch reports in Java which are developed and tested on Windows and deployed on Solaris and run by cron. Before support for these scripting languages (probably a more correct term) had been added in NetBeans I always had to keep JEdit or some other "programmer's editor" around and Alt-Tab to it. Now I just double-click these files in the Favorites window. Installing .bat/.sh support from the Update center takes less than a minute on my Latitude D600. Can't say the same about C++ support. And why should I have to install C++ support if I never code in C++? My (and maybe others) interest in support for .bat/.sh (and Tcl and Perl) is probably different from the C++ developers. They need Windows batch and Unix shell scripts to launch their (really native) programs. For me syntax and error highlighting are the productivity boosters. Being able to run the script directly from NetBeans would be a nice to have, not more. Therefore I would very much would prefer the solution suggested by Peter. If the status we had in 6.5.1 cannot be maintained (it's not ideal, but I am not sure why not, as probably very few people install both features), then please, instead of taking the shortcut of killing these modules and force people to install C++ support to get syntax highlighting in bash scripts, please put them into a separate cluster (probably together with Tcl and others), and call it something like "All other languages" (as you see I am still at a loss as to what's "native" here...). If I haven't misunderstood the NetBeans platform architecture completely, it should be possible for the C++ development enviroment to build what they need on top of the .bat and .sh modules. Regards Georg
Georg, I think you understand it correctly and you are even better than me in clean explanation what and why this is needed. The only problem is to find someone to implement this. As you have noticed I have increased the priority of this enhancement to P2 to suggest that this is some people really want this to happen. Also voting in this case helps the maintainers to decide what is important and what isn't - so your votes definitely count here. I actually agree with Peter and you that the result of implementing this enhancement request would be better than the current state. All the best, David
David, thanks for your understanding. We can only hope that the resource stituation hasn't become worse during the last weeks. Regards Georg
David, Btw, I don't think that anyone in CND team understands why bat/sh was moved into our cluster. I filed P1 issue 162660, because C++ support depends on it while editor team decided to remove it. What was the reason of such decision? Anyway thanks, that at least it was restored back in 6.7 even in CND cluster few days before beta :-) Thanks, Vladimir.
Because you already had there the execution and data object. We have just moved the lexer (coloring) classes so they would be in one please and not in 2. If this enh request is implemented and the support for additional languages is moved to a different cluster the question will be raised who will maintain the code. BTW my team maintains Java + basic editor infrastructure so these languages do not fit in there. That is not saying they fit in CND either ...
David, we are fine to support this languages. The main concern here is that "coloring" of shell/bat files (not native execution) is requested by non c/c++ users. So, may it's not so bad to have coloring part in ide cluster with the simplest DataObject Factory registered for this mime-types with the lowest priority => CND Factories will be called if they present and create more advanced DOs with native execution support as well.
Execution support is, of course, also helpful for other clusters than cnd - how else to test startup scripts?
No, although 2 data objects for one mime type are possible it is not a good way to do things especially with the ergonomics feature.
I think, if there are 2 factories for the same mime-type the winner is with higher priority, so in general there shouldn't be 2 data objects. Although you are right about "ergonomics" it introduces quite a few problems all the time :-), but even in that case after restart there will be the winner Factory with higher priority.
I would agree with vv159170's suggestion to have the basic support in the ide cluster, with something in cnd cluster registering a higher-priority loader offering some added CND-oriented features that need special infrastructure.
If I may vote I am against having a support for one language in 2 different places (especially when the support is not very big as in this case).
Well all the coloring code would be in ide cluster; the DataObject with its factory is just ~10 LoC. The cnd part would be nearly disjoint in this case.
execution is in ide cluster.. will close this issue