I guess Run File in j2seproject is only implemented for src/ not for
test/?

Yes. I will fix that.

Question is: should the classpath for class execution from test
subdirectory contain junit.jar or not?

Btw. the same case is debug-single which I will fix as well.

I will answer this myself: Yes.

Java source which is not JUnit source and which is located under test
directory has to use classpath which contains:
 - run.classpath
 - build.test.classes.dir
 - libs.junit.classpath
Instead of defining new separate classpath I would simply reuse
run.test.classpath for this.

This is simple to do, but means some conditional logic in action
provider and dedicated targets like "run-single-from-test-folder" and
"debug-single-from-test-folder". So before I commit this I have sanity
check questions: do we really want to support this? What is the use
case? What is the usefulness of putting some classes into test
directory? Should not test subfolder contain only unit tests? Or
should not be these main classes executed throught some unit test or
converted to be unit tests? Do we want to encourage users to do this
by implementing this issue? Whoever has an opinion on this, please
speak up.

CCing Jesse.

For J2SE project, yes junit.jar would be present.
It's the de facto standard.
But please, permits also to execute classes having main methods.

For Web Projects, maybe add httpunit or
http://jwebunit.sourceforge.net/ along junit.jar.

And why not add jellytools/jemmy for Swing Applications ?

Vincent, please comment also my other questions. What are you solving
by having these main classes which are not unit tests in test folder?

Re. conditional logic in action provider - sure, same as we already
have for Compile File.

I don't have a strong opinion on this one. Seems harmless, though I
agree that it is not ideal to encourage users to put non-JUnit-format
tests into the tests folder. Presumably in some cases you have mostly
tests plus a few demo scripts or performance measurement drivers etc.?
I don't know, would like some more info from Vincent on this.
Provisionally marking as an RFE since the current behavior is I think
as designed.

Re. HTTPunit, Jelly, etc. - completely unrelated, please keep it out
of this bug report. (Probably the web project type will have HTTPunit
support at some point, but I don't know more about it than that.)

In fact, they are unit tests, but they are not based upon junit framework.
I have 90% of my test cases written with junit. Somes others are
written with dbunit. 

And DBUnit tests is not exactly the same as junit.
So DBUnit can't be launched by just clicking CTRL-F6.
Reason is that when I click on Ctrl-F6, the build.xml is calling junit
task. But DBUnit tests need to be launched by dbunit task.
So, my first idea was to add a main method in my dbunit class to be
able to launch it.
I expected that by having a main method, I would be able to launch my 
db unit tests.

Because it is not the case, I have to search how I can easily add a
dbunit task in the build.xml and execute it from the IDE.

I hope that I answered to your questions.

Please let me know if it's not yet clear

"Reason is that when I click on Ctrl-F6, the build.xml is calling junit
task. But DBUnit tests need to be launched by dbunit task." - so that
is more the issue; you should probably be editing build.xml to invoke
<dbunit> where appropriate rather than cluttering the test sources
with main methods. Of course adding the main methods might be the
quickest workaround (assuming you have a fairly small number of such
tests).

Unless there are compelling usecases this is WONTFIX for me. But I
leave this open.

I don't know, I would rate it a +0 - potentially useful in some cases;
not aligned with the intended usage of the project type, but mostly
harmless if not used. I am mainly concerned about users attempting to
run real JUnit test classes via the main method and not understanding
that Run Test works correctly for any test case.

If NB will not support classes having main methods in Test Packages, 
why let user choose between Test and Source Packages.

When I use the New Wizard, for Junit Test classes, they will be
automatically created into the Test Packages. Impossible to choose
between Source Packages and Test Packages. That's the expected behaviour.

But when I use the New Wizard, for Java Main Class, I can choose
between Source Packages and Test Packages.
If Main Classes are not supported in Test Packages (I suppose it's the
same for Applet, JApplet, JApplet Form, ...)why then let user choose
between Source Packages and Test Packages if he can run them ?

I don't think we have any plans to make choice of template sensitive
to the particular source group within a project, at least not for D.
Would be nice, but gets a bit complicated.

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

I created 49028.

In my case, my main()'s create a simpler GUI for me to display a 3D
Model (using Java3D) that gets read in from a file and post processed.
One test program excercises the file reading/displaying classes, and
the other excercises the postprocessing (combining adjacent triangels
into triangle strips etc.) routines. Displaying these results in a GUI
is the best test method that I have found yet, and I just haven't
found the time to investigate how to use Junit to do this.

Junit may be the best thing  since sliced bread, but my project is
small , and so far I haven't needed it yet. I think the idea of
splitting out the test sources so that they don't get packed in the
application is great. So far though, it's a real shame that it's been
declared off limits unless the user wants to learn and use Junit. 

I also keep a few other programs in this area that were written as
simplified test cases for the J3D team to use to find bugs I filed.
Technically they don't test parts of my project, but they also aren't
part of my project either. At the same time this was the project that
I found thos bugs with, and this is where I"ll remember to look for
that code when I need it again for some reason.

BTW simplest workaround:

public class X extends TestCase {
    public static void main(String[] x) {...}
    public void testIt() {
        main(null);
    }
}

Is Run File in j2seproject even implemented for src? I am running 
4.0 Beta 2 (build 200409220845) and the Run File option is not 
enabled for _any_ class in the src module of my j2seproject. I 
installed RC1 (build 200411231853) and imported my settings, and 
same thing. Everything under the Run Other menu is disabled.

Works fine for Source Packages. You have to select the java file which
has the class with main method.

Sorry, I meant j2eeproject, not j2seproject.

Don't know about Run File in j2eeproject but feel free to file an RFE
(component: j2ee).

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

Quick recap of (my) #57277 use case - in addition to my JUnit tests for
correctness, I have some other (Main) classes which do various timings to
compare two alternative algorithms in the code being developed.  If I include
them under "Source Packages" then they automatically get included in the built
jar, which I don't want as they're purely for testing.  But if I include them
under "Test Packages" it tries to run them as JUnit tests even though they're
not named *Test.java (they're *Timer.java), don't extend TestCase, and don't
have any setup/teardown/test* methods.

There's a couple of alternative workarounds - put them under Source and use the
Packaging "Exclude from JAR File" filter to stop them being included in the jar,
or (as Jesse suggested previously) convert to JUnit tests which call the
main(String[]) method.  From the perspective of a NB user, however, I don't see
why either workaround should be necessary.  Jesse, you say that you are "mainly
concerned about users attempting to run real JUnit test classes via the main
method".  However, the fact these bug reports are being raised would suggest
that the current behaviour is equally confusing - users are attempting to
execute Main classes via the JUnit runner...

If I create a project using an existing Ant script, I can specify classpath
settings for each folder of packages.  Perhaps the answer is to allow something
similar in the other project types (hidden behind an Advanced Settings checkbox
if you like) i.e. allow the Compile & Run classpaths and Ant targets to be
specified for each folder, rather than the type as a whole?  That way we could
create additional folders for other test types which call
dbunit/httpunit/jemmy/main() etc. as appropriate.

Re. last paragraph - it's possible, but there's no one to work on it for the
time being.

Another use-case: stress tests. I have tried to put them under "Sources" and exclude the classes from the Jar, but that
also leads to the classes not being displayed in the projects window. This is really test code and should go under test
packages. Ideally it should even be possible to start the stress test in its own JVM.

Looks like this was already fixed under a different issue.

*** This issue has been marked as a duplicate of 119922 ***