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.
Summary: | get rid of custom copyfiles task | ||
---|---|---|---|
Product: | javaee | Reporter: | Pavel Buzek <pbuzek> |
Component: | Web Project | Assignee: | Pavel Buzek <pbuzek> |
Status: | CLOSED DUPLICATE | ||
Severity: | blocker | CC: | geertjan, jglick, jtulach, navneet |
Priority: | P3 | ||
Version: | 4.x | ||
Hardware: | PC | ||
OS: | Windows ME/2000 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 42524 | ||
Attachments: | example of xslt |
Description
Pavel Buzek
2004-06-21 14:16:01 UTC
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. |