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.
NB plugin tasklist/usertasks
No immediate plans to implement Run File for NBM projects. Not necessarily clear what it should do, anyway - what should the classpath be? same as for unit tests? or something else? Generally unit tests should be used in preference to this, though there are cases (e.g. contrib/quickfilechooser/build.xml#demo) where it is desirable to run a main class in order to interactively try some fragment of GUI which has been decoupled sufficiently from the rest of the module.
*** Issue 71890 has been marked as a duplicate of this issue. ***
I write different little tools and other things that I use during the development process to evaluate certain strategies for implementing details of my applications. I really miss not being able to write these as standalone applications to start inside of my project. At some point, I might make some part of these 'tools' into tests, but it really inhibits my productivity to have to go through the testing mechanisms to do these simple tasks.
*** Issue 120054 has been marked as a duplicate of this issue. ***
*** Issue 135272 has been marked as a duplicate of this issue. ***
Would need a new target in common.xml to run a single src/**/*.java under the assumption it has a main method, probably using test.unit.run.cp or similar.
*** Bug 193297 has been marked as a duplicate of this bug. ***
*** Bug 179131 has been marked as a duplicate of this bug. ***
Bug #154358 implemented Run File (as main) for classes in test/unit/src, which would be the preferred placement for code not intended to be in the actual module. (So long as the class is not named *Test, it need not use JUnit.)
*** Bug 165309 has been marked as a duplicate of this bug. ***
*** Bug 44265 has been marked as a duplicate of this bug. ***
*** Bug 197667 has been marked as a duplicate of this bug. ***
Hi Jesse, Thanks for considering this enhancement request. The lack of this feature makes it awkward to transition from a non-platform application to a NetBeans platform application. Sure makes it look like the menu items like "Run File" and "Debug File" are broken -- since they are grayed out. More importantly: I can quickly debug JPanels in a non-platform application. It takes 1 second for the JPanel to show up. But it is suddenly awkward in a platform application. The "Run File" feature is missing, and it isn't clear what can be substituted. I resort to actually running the whole platform application -- which takes 22 seconds to start up. This is much slower than the 1 second I'm used to, and suddenly I am regretting the idea of switching to a platform app. Perhaps it would be a more consistent user experience if the feature were removed from the non-platform support as well as the platform support? That would make it easier for new people down the line, right? My desire is to have the feature implemented. Is it difficult to do? Kind Regards, -John
I second John's comment--the inability to do a quick "Run File" on arbitrary main classes in a platform module makes very useful testing & iteration workflows that are possible with regular application projects impossible with platform application projects.
RFEs no longer under consideration for NB 7.2; possible for the subsequent release. There are two possible ways ModuleActions could support COMMAND_RUN/DEBUG/PROFILE_SINGLE on findSources(context) in addition to findTestSources(context, false): 1. Using JavaRunner, as in existing unused bypassAntBuildScript (but modified to use QUICK_RUN/DEBUG). 2. Using something akin to setupRunMain, with matching harness changes as in comment #6. #1 ("Compile on Save" mode) has the advantage of being relatively simple to implement, and also launching most quickly. #2 would be a bit more work to implement, and a little slower at runtime, but more robust - works even if the Java editor is confused so long as the Ant build succeeds; and would run with module JARs including computed manifests in the classpath, so that all XML layers would be loaded (otherwise probably only generated-layer.xml's from annotations would be visible). Note that as with unit tests (excepting usage of NbModuleSuite), only modules in this module's transitive dependency graph would be on the classpath, so layers and services from unrelated modules in the app would not be there.