Created attachment 15884 [details]
example of xslt

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

Please rethink the importance of this for promoD (if does not qualify,
move to tbd again). But if you once release promoD that contains the
custom ant tasks you will hardcode a reference to NetBeans class
inside of user build scripts. As you cannot simply break these user
files you may be required to maintain these classes even if you
implement this issue later. If this was true, I would suggest to
implement better XSLT for promoD.

I was thinking about this, and does the attached XSLT script actually
solve this issue? The goal is to:

- Have a property in the per-user build.properties file which lists
all library files as a semicolon-delimited list (of absolute paths).
- Have a target in build-impl.xml which copies the files specified in
this list to some location (directory). 

XSLT is used to generate build-impl.xml, but this would mean that the
generated build-impl.xml would contain the hardcoded locations of
these files, right? So when the user changes the properties file, the
build-impl.xml would have to be regenerated to make the changes effective.

(I hope I'll be proven wrong.)

Adding Jesse to cc:, as I saw some good comments from him about this.

Right, the drawback of using the suggested XSLT is that any kind of
change to the lib path requires build-impl.xml to be regenerated,
which is not terrible but not great.

By comparison, in j2seproject adding or removing a subproject to the
classpath requires a build-impl.xml regeneration, though changing the
actual path to the subproject does not.

Note: if all of the paths were relative, you could do tricks with
<pathconvert> and <fileset> using standard Ant tasks. Unfortunately
this does not work with absolute paths since Ant's <fileset> does not
currently support absolute includes.

Having hardcoded local paths in CVS is not good idea at all. But why
not try indirect reference to copied files:

private/build.properties:
copy.number.of.files=2
copy.1=...
copy.2=...

build-impl.xml
<copy file="${copy.1}" todir="..." />
<copy file="${copy.2}" todir="..." />

so you would need to regerate the build-impl.xml only if the number of
files changes, the number of files would need to be the same for all
users (maybe copy.number.of.files belongs to
nbprojecft/build.properties) but the actual locations would be private
to any user.

Yarda's suggestion is similar to what j2seproject's do for building
subprojects: the number (and actually also the nature) of the
subprojects is stored in project.xml and regenerated build-impl.xml,
but the actual paths are stored in project.properties. Certainly you
should not consider keeping actual file paths hardcoded in
build-impl.xml, as this would make it impossible to rearrange projects
on disk locally by adding overrides to private.properties (among other
things).

I have no strong opinion on this. Both alternatives are mildly
unpleasant but workable.

Probably too late to change it for D.

I think it's good candidate for release notes. Users probably don't
expect that there is an internal NetBeans JAR file needed for external
ant compilation.

Workaround is: 'Make web project compilable without NetBeans installed'
1) Distribute copyfiles.jar from $NETBEANS_INST/ide4/ant/extra with
project (e.g. copy it to $PROJECT_DIR/nbproject/lib)
2) Override -pre-init target in your build.xml and set
copyfiles.classpath property value to copyfiles.jar location, e.g.:
  <target name="-pre-init">
     <property name="copyfiles.classpath"
value="nbproject/lib/copyfiles.jar"/>
 </target>

CCing Geertjan for comments.

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

Is it really duplicate of issue 50676? That talks about the class of 
the task not being found, but this one asks for the task to be 
completely removed. 
 
I am afraid if this one will be closed as duplicate, the issue 50676 
will be solved in another way and the task still stays that. That is 
why I am reopening this one. If my worries are false, then please 
excuse me. 

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

OK, after talking to Yarda I have modified issue 50676 summary and
added comment, that copyfiles task has to be removed. No other
workarounds (like copying it to each project) are allowed.
I hope it is now clear, sorry for the confusion before.