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.

Bug 162933 - [67cat] Move native execution support to separate cluster
Summary: [67cat] Move native execution support to separate cluster
Alias: None
Product: cnd
Classification: Unclassified
Component: execution (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker with 3 votes (vote)
Assignee: Andrew Krasny
Depends on:
Reported: 2009-04-17 13:59 UTC by Peter Nabbefeld
Modified: 2012-10-26 14:26 UTC (History)
3 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Nabbefeld 2009-04-17 13:59:24 UTC
[ 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.
Comment 1 giorgio42 2009-04-17 21:59:28 UTC

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.

Comment 2 David Strupl 2009-04-18 13:06:59 UTC

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,
Comment 3 giorgio42 2009-04-18 22:01:55 UTC

thanks for your understanding. We can only hope that the resource stituation hasn't become worse during the last weeks.

Comment 4 Vladimir Voskresensky 2009-04-19 11:05:30 UTC
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 :-)

Comment 5 David Strupl 2009-04-20 10:28:45 UTC
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 ...
Comment 6 Vladimir Voskresensky 2009-04-20 10:48:49 UTC
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.
Comment 7 Peter Nabbefeld 2009-04-20 11:45:04 UTC
Execution support is, of course, also helpful for other clusters than cnd - how else to test startup scripts?
Comment 8 David Strupl 2009-04-20 11:45:53 UTC
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.
Comment 9 Vladimir Voskresensky 2009-04-20 12:10:58 UTC
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.
Comment 10 Jesse Glick 2009-04-20 15:02:55 UTC
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.
Comment 11 David Strupl 2009-04-20 15:52:00 UTC
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).
Comment 12 Jesse Glick 2009-04-20 16:42:41 UTC
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.
Comment 13 Andrew Krasny 2012-10-26 14:26:56 UTC
execution is in ide cluster.. will close this issue