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 51097 - Not obvious how to set up unusual default excludes rules for compilation
Summary: Not obvious how to set up unusual default excludes rules for compilation
Status: RESOLVED DUPLICATE of bug 49026
Alias: None
Product: projects
Classification: Unclassified
Component: Ant Project (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jesse Glick
Depends on:
Reported: 2004-11-02 19:13 UTC by Jim Hazen
Modified: 2010-02-16 12:11 UTC (History)
1 user (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jim Hazen 2004-11-02 19:13:34 UTC
A 3.6 filesystem option was to ignore files based
on regular expression.  This expression has been
moved to a project wide setting under IDE
Configuration/System/System Settings.

The problem is that even though the display may
ignore some *.java files, ant will still attempt
to compile them via project's default build task.

This is functionally inconsistant with previous
versions of Netbeans.

I've submitted this at P2 because my project is
currently unbuildable in 4.0 due to problem *.java
Comment 1 Milan Kubec 2004-11-03 09:59:17 UTC
I think that 'Ignore Files' wasn't intended as exclude from
compilation by ant. It's just about displaying files.
Comment 2 David Konecny 2004-11-03 10:22:22 UTC
Agreed with Milan.

You can customize your build script to omit some files from compilation.

If you think it is important feature then please provide compelling
Comment 3 David Konecny 2004-11-03 10:28:32 UTC
Please, check also issue 49026 which is very close to this one and
feel free to comment there. Thanks.
Comment 4 Jim Hazen 2004-11-03 15:52:35 UTC
An important feature in any build system is the ability to exclude
files (or enumerate all include files).  This was recognized as an
important feature and 'Ignored Files' was added as a filesystem
option.  In my opinion removal of this feature is a regression in
functionality.  That is why I've filed this as a defect and not an

I use a revision control system based off of SCCS.  This means that I
have numerous files of the form s.<filename>.java.  Default *.java
glob include rules cause my project to horribly fail.

I applaud efforts to move to ant internally.  However a huge selling
point of 4.0 is that although Netbeans is based on ant, users aren't
forced to use or know about ant if they don't want to.  This promise
is now broken for folks like me who depend on the 'ignored files' 
filesystem semantics of 3.6 and earlier.  In 4.0, it would be
impossible for an SCCS project to be built using only options
available within the IDE.

I don't see the hesitation for this.  Ant supports an exclude option.
 You have the setting stored within the IDE.  Set an environment
variable like single-file compile.  That way if folks use the option
it's supported, everyone else probably won't notice the difference.

Please give me back functionality that is critical to my acceptance of
Comment 5 David Konecny 2004-11-03 16:36:27 UTC

    <target name="-pre-init">
        <defaultexcludes add="**/s.*.java"/>

to build.xml file in the root of your project should solve the problem.

We know that current project should be more customizable in UI and
that we should not keep answering "customize your Ant script", but it
is a matter of priorities. We cannot do everything in first release,
we need to get it out of the door to get some feedback. We already
started work on 4.1 in which we would like to remedy some of these

Please try the workaround and let me know if it works for you and is
acceptable for 4.0.
Comment 6 Jim Hazen 2004-11-03 20:41:39 UTC
This does work for me, thank you.

However, that's only half the point.  You say you want feedback but
don't have the bandwidth to deal with the feedback you're getting from
your Beta.

From what I've read on TSS, JavaLobby and others, 4.0 will mark a
significant marketing push by Sun/Netbeans to try and displace the
IBM/Elipse machine.

It does you no good to ship a product with only a half finished
project system.  Ant may be a great foundation, but what's built on
top isn't ready for prime time.  Based on what I've seen, with the
current issues, 4.0 is setting itself up to be a flop.

I personally am looking for the ability to:
 - Exclude single files, and exclude files by glob or preferably
regular expression.  (Available in 3.6)
 - Register non Java compilers with the system.  Support for
configurable Jikes, Acj and others.  (Available in 3.6)
 - Register multiple JVMs.  1.3, 1.4, 1.5 VMs.  With some files being
compiled/executed by one VM and others by another.  I have several
codebases where some code is 1.3 and some requires 1.4.  Same project,
different compilers/packaging reqs.  (Available in 3.6)
 - Ability to generate multiple project jars (with different
recipies), and place them in any location.  (Available in 3.6)
 - Ability to work on project source that depends on source in another
location.  (Available in 3.6. Maybe available in 4.0 with required
projects, but I'm not sure.  Would still require the overhead of
creating a new project just to include)
 - Ability to compile JSPs in any project.

That's for starters.  These issues have been reported elsewhere in the
system by other developers.

I expect 4.0 to be functionally better than 3.6.  I also expect
Netbeans to keep it's promise that ant hackery won't be required to
achieve 3.6 functionality.  I expect that other developers will agree.
 I don't mind that 4.0 beta is in this state.  I think you have a good
starting point and I'm beta testing to try and help the 4.0 release,
not rag on you guys.  I'm in development too and understand the
problems and pressures the project is under.  

I do think that I and other beta testers have raised some serious
issues.  Ant as a foundation is fine, but you need to finish building
on top of it.  4.2 may indeed be a good product.  However the current
codebase as 4.0 will generate significant negative press.  I'm not
compelled to upgrade.  In fact I think that Netbeans' priorities are
very different from my own if they're willing to dish out a product
they know has serious issues, just to generate feedback and buzz.  If
that's the way the project is going to treat it's older userbase,
maybe we should start looking at alternatives.

Instead, hold off on the release.  Incorporate the constructive
feedback you've received from the beta testers and release and market
a solid product.  This way buzz is positive and other developers and
contributers return to Netbeans.  This means more plugins and greater
support for all users.  Otherwise I fear the slow and ugly demise of
the IDE I currently enjoy.
Comment 7 David Konecny 2004-11-04 14:37:54 UTC
"I use a revision control system based off of SCCS" - I know very
little about SCCS, but as I undestand it the s.* files are special
files with all the revisions of file? Such a file should be stored in
special subfolder like SCCS, right? I'm asking because Ant by default
ignores both **/SCCS and **/SCCS/** (see end of
<>) so from this point of
view everything should work fine for SCCS. Is the problem in "based
off of SCCS"?

Re. your general comments about NB4.0: I'm not right audience for them
nor this issue. Please, post your opinion on mailing list.

" ship a product with only a half finished project system" - I
disagree that it is half finished. Looking at the abilities you are
personally looking for it seems to me that they are very specialized
and that Ant script customized by hand is in your case the best for
your own good. NB36 supports some of these, but had so many other
problems that I personally would not dare to rely on it. With Ant
script you now have absolute control and can get 100% reproducible
builds and everything can be stored in your versioning system. Re. how
much of these should be supported in UI is question for UI experts,
but I personally doubt NB projects should be ever customizable in UI
in such a detail. Some things might even not work correctly and you
might end up helping user to shoot their own leg, for example "some
files being compiled/executed by one VM and others by another",
"exclude single files" - javac as part of its dependency check can
decide to compile other files which you perhaps wanted to exclude or
compile with different JDK.

Anyway, I suggested simple workaround for your problem and it works.
The NB4.0 is already in high resistence mode what means that only
serious problems can be fixed now. I can see two solutions: downgrade
priority to P3 (that's what I would like to do) and discuss how to fix
it in 4.1 or keep it as P2 but ask for WAIVER.
Comment 8 Jim Hazen 2004-11-04 16:15:57 UTC
I'll bump down to P3.  The work around works well.  I had some SCCS
files outside the typical location.  I think the default **/SCCS/**
exclude rules work by default.  I also had some non SCCS, but other
SCCS like rules for excluding files.  They were easy to eliminate in
3.6, needs ant hackery in 4.0.

The ant hackery was pretty elegant, and effective.  If 4.0 isn't going
to eliminate ant hackery I think it would be nice to give a lot of
examples of common fixes for advanced issues.  I think in general a
Netbean/ant primer, or a few ant snipits to fix common issues would be
very nice.
Comment 9 David Konecny 2004-11-04 16:47:16 UTC
Re. docs - agreed. However, I do not know about any concrete
action/plan in this area.
Comment 10 Jesse Glick 2004-11-06 00:18:23 UTC
Changing summary/status/etc. to reflect last few comments. The default
excludes list that comes with Ant is intended to do what the great
majority of people want. If you're one of the people for whom it
doesn't, it is not too hard to correct it if you know what to do, but
this sort of thing certainly belongs in a set of tips of some sort. I
expect that such a "cookbook" should start to grow (Wiki??) after the
release, with the most popular items being addressed directly by the
GUI as time permits.

Note that we do have under consideration an RFE to include only
portions of a source tree, primarily for performance reasons on
massive source trees. This would affect the Ant script (which you do
yourself) and classpath scanning (which you couldn't do otherwise).
However I think that is a somewhat different case. Here in this issue
the question is ignoring certain kinds of files, rather than picking
portions of a package tree to work on. *Possibly* both cases could be
handled by a single GUI but I am not sure if this works well in
combination with classpath scanning etc. Generally we need to take
care when setting up any kind of excludes lists for Java sources,
because unlike e.g. C/C++, calling javac on a list of sources does not
guarantee that other sources will *not* be compiled anyway if they are
referred to statically.

It may be the case that /^s\./ is a reasonable addition to Ant's own
default excludes, but I was under the impression that SCCS normally
expects these files to be in an SCCS/ subdirectory to begin with. Also
such a pattern is a little too close to a "real" filename to be
comfortable for a default exclude; e.g. "s.txt" may be a plausible
Comment 11 Irina Filippova 2010-02-16 12:00:30 UTC
Since the version mentioned in this issue, a lot of things mentioned were implemented, such as those in the original request (excluding files from compilation). The current NetBeans documentation (up to 6.8) covers the issues mentioned: exclude files from compilation (javahelp and, Ant, etc.

So, unless further requests to docs are specified more specifically, I believe that the issue from the docs side is resolved. 

However, I am not sure about other RFEs mentioned in the discussion. So, reassigning to another component.
Comment 12 Jesse Glick 2010-02-16 12:11:48 UTC

*** This bug has been marked as a duplicate of bug 49026 ***