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

Jesse, don't you see a little dangerous to delete *.class from user's
directory? Should I find all *.class in project's src and delete them?
Shouldn't we add a check box to decide Yes/No to delete?

"Jesse, don't you see a little dangerous to delete *.class from user's
directory?" - slightly, but I think *.class files are generally
treated as disposable.

"Should I find all *.class in project's src and delete them?" - right.
Ideally just those *.class which correspond to a known *.java, though
this is hard to do accurately in the case of top-level private
classes. (You would need to scan the actual bytecode to find the
source attribute.) So I would just recommend all ${src.dir}/**/*.class
and ${test.src.dir}/**/*.class.

"Shouldn't we add a check box to decide Yes/No to delete?" - only if
necessary. I guess only if there are some to delete, otherwise it
should be disabled or invisible?

IMO user must be explicitly warned about deleting any classes from the
folder in any cases. Invisible deletion of anything doesn't seem right
to me at all.

There can be situation when user might unjar required jar file into
src folder where he keeps sources and classes (not using nb yet) and
those classes will be deleted. If user exactly follows new-nb-project
workflow classes look disposable but it's not the only workflow. I'm
sure users will have another cases where deleting their classes won't
be good idea.

OK, but this is more important for D than for E, because of users with
existing 3.6 projects.

Re. "There can be situation when user might unjar required jar file into
src folder where he keeps sources and classes (not using nb yet) and
those classes will be deleted."

How does the user perform the clean build then?

Anyway, we should probably warn the user that we delete the class files as it doesn't seem 
to be very safe. But I don't think the checkbox is the right approach. I think we should 
show a question alert (after clicking the Finish button) saying something like:

------
*The provided source folder contain class files (compiled java sources).*

The class files should be deleted because NetBeans keeps the class files in a separate 
output folder. Do you want to delete the class files?

[ Delete Class Files ] [ Keep Class Files ]
------

Or similar wording. If you agree with this solution, I will work with John on the right 
wording.

Re "How does the user perform the clean build then?"
Classes can be in different packages and e.g. NB 3.6 allows user to do
clean rebuild of selected folder and its sub folders, so there can
easily live untouched classes with user sources/classes.

Re. question alert (appearing only in case there are some *.class): I
like this.

Re. user keeping unpacked *.class in special folders that he/she
carefully avoids cleaning: we should probably throw a
StupidUserException in this case.

"Re. user keeping unpacked *.class in special folders that he/she
carefully avoids cleaning: we should probably throw a
StupidUserException in this case."

I must disagree here. Not every single developer is senior experinced
developer using VCS, junit, EJBs ... and I don't know what else.
Remembering me when I saw Java first time, had no idea about jar files
and classpaths - so I simply unpacked required jars together with my
code and hapilly compile and run everything together. In that case I
didn't need/want any special project management systems that pretended
being more clever than me. -- This was just example how somebody could
think.

So if somebody has different setup than we can understand doesn't mean
it's a stupid user.

I'm going try implement it, before commit I'll consult with Jano.

Created attachment 17752 [details]
proposed patch

Jano. please consult the texts in Bundle with documentors. Thanks

I guess in PanelSourceFolders,

//deleteClassFiles (folder);

should not be commented out.

The URL field contains link to the spec.

implemented in
src/org/netbeans/modules/java/j2seproject/ui/wizards/Bundle.properties;
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/wizards/Bundle.properties,v
 <--  Bundle.properties
new revision: 1.36; previous revision: 1.35
done
Checking in
src/org/netbeans/modules/java/j2seproject/ui/wizards/PanelConfigureProject.java;
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/wizards/PanelConfigureProject.java,v
 <--  PanelConfigureProject.java
new revision: 1.9; previous revision: 1.8
done
Checking in
src/org/netbeans/modules/java/j2seproject/ui/wizards/PanelConfigureProjectVisual.java;
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/wizards/PanelConfigureProjectVisual.java,v
 <--  PanelConfigureProjectVisual.java
new revision: 1.14; previous revision: 1.13
done
Checking in
src/org/netbeans/modules/java/j2seproject/ui/wizards/PanelOptionsVisual.java;
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/wizards/PanelOptionsVisual.java,v
 <--  PanelOptionsVisual.java
new revision: 1.17; previous revision: 1.16
done
Checking in
src/org/netbeans/modules/java/j2seproject/ui/wizards/PanelProjectLocationVisual.java;
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/wizards/PanelProjectLocationVisual.java,v
 <--  PanelProjectLocationVisual.java
new revision: 1.26; previous revision: 1.25
done
Checking in
src/org/netbeans/modules/java/j2seproject/ui/wizards/PanelSourceFolders.java;
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/wizards/PanelSourceFolders.java,v
 <--  PanelSourceFolders.java
new revision: 1.29; previous revision: 1.28
done
Checking in
src/org/netbeans/modules/java/j2seproject/ui/wizards/SettingsPanel.java;
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/wizards/SettingsPanel.java,v
 <--  SettingsPanel.java
new revision: 1.2; previous revision: 1.1
done