Hi, what I think could help is the following:

- install the IDE on the other machine
- start the IDE
- open the project checked out from CVS
- shut down the IDE
- run the build from command line

Does that fix this problem? Thanks.

Hi,

I followed your instruction step by step. It does fix the problem if I
execute the instruction with daily-build, but not with beta2.

However, this is not a solution regardless, if we want to use the
generated script on our Unix server: We only have console access to
the Unix box, and are not allowed to use any "X-Window" software to
install/run anything on it. A real solution to this matter would be
really really appreciated.

Thanks!!

If you cannot open the project after check out here is another simple
workaround. You can set user.properties.file to point to location of
netbeans userdir. Or you can only take the copyfiles.jar and set the
copyfiles.classpath property to point to it.

More info at: http://projects.netbeans.org/buildsys/design.html#headless

The copyfiles library will hopefully be removed in future.

Thanks for the suggestions. It's sort of sad, though, to read the link
you send where it implies customized Ant stuff seems to be un-avoidable.

I do have a suggestion: The IDE should have a standard way of bundle
NB specific build stuff into the "nbproject" folder, such that the NB
add-ons are transparent to the "headless builder".

In this case, for example, the IDE could copy the entire "ant/extra"
folder that contains the NB jar files needed for the build, into the
"nbproject" folder, and specify the "copyfile.classpath" property in
the "project.properties" file using RELATIVE path pointing to
"nbproject/ant/extra/copyfiles.jar". That way, a non-NB user can still
checks out from the CVS and run "$ant dist" without even knowing
what's going on under the hood.

Just my two cents.

Thanks again!

It is interesting that you are raising this again. I had raised this a
whole lot earlier in the Netbeans 4.0 dev cycle and here is a trace of
what i heard from them:

http://www.netbeans.org/issues/show_bug.cgi?id=45283

And then they filed another issue at:

http://www.netbeans.org/issues/show_bug.cgi?id=45284

Navneet- I was just using this issue to ask a more general question,
not to "raise it again". Since the issue applies only to web/j2ee
project in nb4.0, not j2se project, I am concerned that it will become
a general trend in nb4.1, wherein more and more j2ee project scripts
are not runnable outside of NB "the way they are".

QA agrees that it should be fixed in 4.1 in both (web/j2ee project).

Setting correct Version, resetting TM to TBD and increasing priority.

I totally agree with your view point, and that is the reason i too had
raised this.

Its good that QA now agrees with the view points of all of us and has
decided to fix this in the next release. I just hope it is sooner than
4.1 ( maybe 4.0.1 ).

The closest release after 4.0 is 4.1. No chance to build another one,
sorry.

Changing Version to 4.1 - it's legitimate P2 in 4.1, but as designed
(= at most P3) in 4.0.

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

See duplicate issue 45284 for Jesse's and Yarda's comments on solution.

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

The fix will be: removing copyfiles task, it can't stay in 4.1 projects.

The copyfiles is doing 2 things: works for multiple files/folders and
distinguishes between files and folders.

The solution is to add: lib.foo.classpath.libfileX,
lib.foo.classpath.libdirX (X=0..number of files in library) into
private.properties when adding a library or additional war content,
update this when the library changes; the <library> tag in project.xml
will have attributes files=A and/or dirs=B. The build-impl.xml will
generate <copy file="${lib.foo.classpath.libfileX} ..> or <copy
..><fileset dir="${lib.foo.classpath.libdirX}>..
The version of web project will have to be increased to contain the
attribute for number of files/dirs in library tag. If the project does
not have this the build-impl.xml will have to be generated the old
way, ie. with copyfiles.

fixed

When will the fix be available? It's not in 4.1 beta. Should I look for it in
daily builds? Thanks. -Qingtian

Yes, it is fixed in daily builds.

I checked in Mar-15-2005 qbuild. The copy functionality works only for files,
but not directories. i.e. It won't work if you specify an entire folder to be
copied to the WAR file in the "packaging" node of the project properties. -Qingtian

There were some additional fixes after Q-build branching. Please try build
200503172015 or later (as soon as it will be downloadable). It works fine for me
there.
If it won't work for you, please file a new issue, thanks.

This issue is verified.