You can either

1. Use a freeform project and use your existing build.xml.

2. Make a project with existing sources and place it into a relative location
(should not interfere with CVS usage).

I actually think this is a valid request - reopening as an enhancement (I agree
this is not a "defect"). When importing an existing web project it already works
this way - it lets you specify another name for the NetBeans build script, by
default it suggests name 'nbbuild.xml', I think. Please check it out to see what
I mean.

I don't think we have any plans to do this for other project types, sorry.

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

For an NB user to know about the workaround of putting your project files in a different place, to me, is ignoring the
real issue at hand.  

I opened up 109917 and didn't realize this issue was already here.  I feel this is a valid request, and I feel it's bad
design to use standard file names that your users will inevitably use on their own.  It's only asking for trouble.  

Ticket 109917 was closed, but the heart of my problem is the fact that you're not allowed to have your own build.xml
script in the same place that NB wants to create one.  I only suggested a project property as a possible fix, *not the
definitive way to go about fixing it*.

I am hoping by re-opening this issue someone on the NB team will consider changing the name of the NB build file to
nb-build.xml so that we can use NB along side an existing build.xml file. This affects Subversion since I cannot use NB
to manage all of my files when using "a project with existing sources". Using the Favorites window is not an option here
since our projects are embedded to ease configuration problems.

build.xml is the correct name for a new project (from scratch or with just Java sources and no Ant script), since that
is the default name expected by Ant (e.g. if you just "cd projdir; ant"); and for such projects it would be misleading
the characterize the NB-generated script as only applicable to NB, when it is a generally usable build script (barring
bugs or unrelated RFEs).

So regarding the proper handling by the New Project wizard of the situation where the user selects New Project with
Existing Sources and picks a project directory which already has a build.xml in it, there are several possible approaches:

1. Generate a different $name.xml to be called from NB, with the filename kept in project.properties.

2. Prompt the user to create a freeform project instead. (If we cleaned up and improved support for adding missing
targets to build scripts for freeform projects, which is an area which needs to be improved a lot independently).

3. Prompt the user to import build-impl.xml from the existing build.xml, which might work for most scenarios (TBD).

4. Detect the situation in the wizard and offer to just create the NB project metadata in a dedicated subdir. This is
the recommended approach for users of current IDE versions, so the change would simply be to have NB suggest it rather
than stopping the wizard with an error message.

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

Agree with Jesse, point 4 is the best one.

I think #4 would work great as a short-term solution, but #1 sounds much better for a long term solution.  Given the
fact that the build file can be named virtually anything, I don't see why the NB project should keept sticking to the
"build.xml" file name convention when something like "nb-build.xml," as suggested by dafreels@netbeans.org, is just as
useful and will elminate all of these issues.

The point 1 is also possible, but by default should be used build.xml since it's an Ant default.

I highly disagree.  What kind of an argument is that?

Just because "build.xml" is the default ANT build file name when you run the ANT utility, doesn't logically make it
inherently better or worse than any other clear and understandable build file name.

If one were to argue that it's "too much work" adding a property to the tool to store a differnt build file name, then
that would make at little more sense.  If the web project is coded to recognize a conflict, then that means that there
is a recognition that there can be build.xml conficts, and a code-fix was added to solve the problem.  

I would argue that because so many people use the default ant script name, i.e., "Build.xml," then that is *precisely*
the reason NetBeans should not use that name.  I think it would be wise to avoid conflicts with the way users set up
their projects, if at all possible, in order to make NetBeans as flexible as possible.

I still don't see a reason why NetBeans shouldn't use by default build.xml and only in case when there is a conflict
(the build.xml exists) it should use something different like nb-build.xml.

  Many of us work on large projects with complicated ant scripts to build multiple ear and war files.  On the project I
work on we have several sub-projects integrated with ant.  Our build tree is 5 years old and contains over 5000 java
classes contained under configuration management.  It is well organized and modular but it is large.  An IDE should be
able to adapt to our existing web projects with minimal intrusion.  It would be tough sell to ask our customer to pay
for us to modify ant scripts just to use a different IDE.  Especially since we have existing software releases in the
field.  This is why we still work with JBuilder 2006 and are heavily focusing on JDeveloper.  They do not dictate
changes to our existing build.  Netbeans has some unique features namely the JSF GUI builder and EJB 3.0 generation that
we are seriously interested in. But, if it can not integrate it with our existing completely J2EE complient project then
we will look elsewhere for our IDE.  Netbeans looks promising that is why I am posting this.  Ant scripts with the name
build.xml is a standard that most existing projects are using.  Please don't cripple NetBeans so it only works well with
small toy projects.  

Since build.xml is the default ant build file name, conflicts with this name are inevitable with existing projects. If 
you want NetBeans adopted for sizable projects, be flexible. Since all the build.xml file does is reference the build-
impl.xml file that does the actual work,this should not be an issue. nb-build.xml is a good choice to name the build 
file. Or just use the build-impl.xml, and skip the build.xml altogether.

I understand that when the build.xml is already in the project NetBeans should use a different name. But when there is
no build.xml file or you create a new project from scratch why it should not use build.xml? It doesn't conflict with
anything.

The new project wizard should do:
if projectFolder/build.xml exists => buildFile = "nb-build.xml";
else buildFile = "build.xml";
projectProperties.put ("build.file",buildFile);
createBuildXML (buildFile);

  Flexibility!  Why not avoid future limitations/collisions with other tools.  Your ant script will not just be used to
build and test the war you are working on.  It might be called from other ant scripts to perform a full project build
and possibly combine your war with others for a release.  The Netbeans build may include jars that you only need at
development time.  It makes it easy to tell the difference from a Netbeans ant script from others.  My favorite --> "I
have to type "ant mybuildScriptName" every time I do a build because the stupid Netbeans IDE used build.xml"  This is
such an easy thing to implement from the IDE perspective that it seems like a no brainer.  

This is no question of how hard is it to implement it (the conditional name of build file is more work than fixed
nb-build.xml). But I bet you if I change the build.xml to nb-build.xml there will be at least the same number of user
complaining about it since they need to call ant -f nb-build.xml instead of simple ant which worked in previous version
of the IDE, which is regression in behavior for them. And it's even API change, the project layout is an exported API.

  Good point.  Then it seems it would be best to make the IDE flexible with build names.  Let the user decide.  Allow
them to change the build script name if they want.  The IDE should support new projects and existing projects so it
seems flexibility is key.

Sounds as a reasonable compromise for me, works for both use cases.

Also raised at: http://www.netbeans.org/servlets/ReadMsg?list=nbusers&msgNo=100878

I very strongly support an enhancement to NetBeans that permits the system to use an alternative build file. I am trying
to introduce NetBeans into an organisation that already has an extensive source tree using many "build.xml" files. Any
attempt to modify the build scripts must be approved by the buildmeister. Renaming the existing scripts is out of the
question.

My preference is to add the build file name as a project property. I would be happy if the default values was
"build.xml", just so long as the user can override the default if required.

I will try to do it for j2se project, with no UI, and attach the diff.

It was suggested I check out the project and have a different directory for the sources, rather than setting a property.
Is it possible to do this and at the same time have a fresh checkout of the project automatically be a valid NetBeans
project? Maybe the source directory can be ../.. ?

I tried putting the netbeans project in a subdirectory of my real project. This will let me commit the NetBeans project
to revision control (which I can't really do if I have to re-name my existing build.xml), but it still sucks because the
NetBeans 'Files' tab no longer helps me to get at files that are part of my project (e.g. README) but aren't on the
build path.

When I set up my project this way, NetBeans' built in revision control can't see those files either.

Issue also referenced at: http://www.netbeans.org/servlets/ReadMsg?list=nbusers&msgNo=108870

The comment posted by rkite (Wed Jul 18 14:30:49 +0000 2007) in my opinion is a killer argument. Imagine you're a new
Netbeans user and you try to create a new project from an existing real-world project (existing build.xml, no option or
interest to change the name). As soon as you realize you cannot create the project you will USE A DIFFERENT IDE. 

Freeform projects support is mediocre and I believe a new user would probably fail at setting one up properly so this is
not a real option!

The benefit of fixing this issue is way bigger than the cost.

Will be addressed in the 6.1

Here comes the patch for j2seproject allowing solution 1. When you create a new project from existing source you can specify different name of the build 
script. Tomas can you look at it? This changes will be needed also for the web project.
The J2SEProjectAntArtifact which is nearly a copy of the SimpleAntArtifact will be replaced by factory method in the ant/project API, for now it's in j2seproject.

Created attachment 57518 [details]
Patch file

> This changes will be needed also for the web project.

I don't think this should be needed in a web project - it already works this way, see #desc3

Fixed in: 89dace4eb5e3

I had to clean up after this commit because the production build was failing as a result of it:

changeset:   71375:99ffc9f0d839
user:        Jesse Glick <jglick@netbeans.org>
date:        Tue Mar 04 10:11:34 2008 -0500
files:       java.j2seproject/manifest.mf
description:
Marking 89dace4eb5e3 (#75644) as incompatible for those with impl deps.


changeset:   71376:fc30a0c8b84b
tag:         tip
user:        Jesse Glick <jglick@netbeans.org>
date:        Tue Mar 04 10:13:42 2008 -0500
files:       projectimport.jbuilder/src/org/netbeans/modules/projectimport/j2seimport/ImportUtils.java
projectimport/src/org/netbeans/modules/projectimport/eclipse/Importer.java
description:
Fixing compilability after 89dace4eb5e3 (#75644).