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.
A grep of NB sources reveals that a certain "Ant-ipattern" recurs in visualweb modules: programmatically creating the a 'release' subdir during the build. This is incorrect; release dirs may be part of sources for static (fixed) content only. As I hope is documented in harness/README, the 'release' dir is just a shortcut for modules with simple static content which would otherwise need to (1) copy files into ${cluster} as part of the 'netbeans-extra' target, (2) add entries to ${extra.module.files}. Trying to modify or create the contents of this dir during the build can lead to erratic results such as files being sometimes copied and sometimes not, and I am not sure if it could break correct NBM generation as well. Please fix, e.g. <target name="netbeans-extra" depends="init"> <mkdir dir="${cluster}/docs"/> <copy file="whatever..." todir="${cluster}/docs"/> <!-- or <jar> etc. --> </> extra.module.files=docs/whatever,modules/ext/something.jar,... Offending modules I found (visualweb/rowset I had found earlier): visualweb/appbase/build.xml: <mkdir dir="release/modules/ext"/> visualweb/appbase/build.xml: <mkdir dir="release/docs"/> visualweb/appbase/build.xml: <mkdir dir="release/docs"/> visualweb/designtime/build.xml: <mkdir dir="release/modules/ext"/> visualweb/designtimeext/build.xml: <mkdir dir="release/modules/ext"/> visualweb/rowset/build.xml: <mkdir dir="release/modules/ext"/> visualweb/rowset/build.xml: <mkdir dir="release/docs"/> visualweb/rowset/build.xml: <mkdir dir="release/docs"/> visualweb/dataprovider/runtime/build.xml: <mkdir dir="release/modules/ext"/> visualweb/dataprovider/runtime/build.xml: <mkdir dir="release/docs"/> visualweb/dataprovider/runtime/build.xml: <mkdir dir="release/docs"/> visualweb/designer/html/build.xml: <mkdir dir="release/modules/ext"/> visualweb/designtime/rave/build.xml: <mkdir dir="release/modules/ext"/> visualweb/errorhandler/client/build.xml: <mkdir dir="release/modules/ext"/> visualweb/jsfsupport/runtime/build.xml: <mkdir dir="release/modules/ext"/> visualweb/jsfsupport/runtime/build.xml: <mkdir dir="release/docs"/> visualweb/jsfsupport/runtime/build.xml: <mkdir dir="release/docs"/> visualweb/propertyeditors/api/build.xml: <mkdir dir="release/modules/ext"/> visualweb/propertyeditors/resolver/build.xml: <mkdir dir="release/modules/ext"/> visualweb/ravelibs/batik/build.xml: <mkdir dir="release/modules/ext"/> visualweb/ravelibs/jsf-metadata/build.xml: <mkdir dir="release/modules/ext"/> visualweb/ravelibs/jtidy/build.xml: <mkdir dir="release/modules/ext"/> visualweb/ravelibs/rowset/build.xml: <mkdir dir="release/docs"/> visualweb/webui/runtime/build.xml: <mkdir dir="release/modules/ext"/> visualweb/webui/runtime/build.xml: <mkdir dir="release/docs"/> visualweb/webui/runtime/build.xml: <mkdir dir="release/docs"/>
I'll look into this.
Checking in nbbuild/cluster.properties; /cvs/nbbuild/cluster.properties,v <-- cluster.properties new revision: 1.341; previous revision: 1.340 done Checking in visualweb/rowset/build.xml; /cvs/visualweb/rowset/build.xml,v <-- build.xml new revision: 1.3; previous revision: 1.2 done Checking in visualweb/rowset/nbproject/project.properties; /cvs/visualweb/rowset/nbproject/project.properties,v <-- project.properties new revision: 1.2; previous revision: 1.1 done Checking in visualweb/rowset/nbproject/project.xml; /cvs/visualweb/rowset/nbproject/project.xml,v <-- project.xml new revision: 1.4; previous revision: 1.3 done Checking in visualweb/ravelibs/rowset/build.xml; /cvs/visualweb/ravelibs/rowset/build.xml,v <-- build.xml new revision: 1.3; previous revision: 1.2 done
First patch looks right to me. You can confirm simply by running the nbm target (beware of issue #105378) and checking its contents; or even just run the regular netbeans target and check the update_tracking/*.xml file.
Some details you forgot: Checking in build.xml; /shared/data/ccvs/repository/visualweb/rowset/build.xml,v <-- build.xml new revision: 1.4; previous revision: 1.3 done Removing release/modules/ext/.cvsignore; /shared/data/ccvs/repository/visualweb/rowset/release/modules/ext/.cvsignore,v <-- .cvsignore new revision: delete; previous revision: 1.1 done
Thanks Jesse. I've run into some compile error when applied similar changes to the designtime and designtime/rave modules, I'm not sure how many more as I go through the list one by one. So I'm skipping thoses for now. If you know what's causing, I can appreciate some suggestions there. Also, these modules' (designtime & designtime/rave content look fine in an NBM to me. More update for appbase & designtimeext: Checking in visualweb/appbase/build.xml; /cvs/visualweb/appbase/build.xml,v <-- build.xml new revision: 1.4; previous revision: 1.3 done Checking in visualweb/appbase/nbproject/project.properties; /cvs/visualweb/appbase/nbproject/project.properties,v <-- project.properties new revision: 1.2; previous revision: 1.1 done Checking in visualweb/appbase/nbproject/project.xml; /cvs/visualweb/appbase/nbproject/project.xml,v <-- project.xml new revision: 1.3; previous revision: 1.2 done Checking in visualweb/designtimeext/build.xml; /cvs/visualweb/designtimeext/build.xml,v <-- build.xml new revision: 1.4; previous revision: 1.3 done Checking in visualweb/designtimeext/nbproject/project.properties; /cvs/visualweb/designtimeext/nbproject/project.properties,v <-- project.properties new revision: 1.2; previous revision: 1.1 done Checking in visualweb/designtimeext/nbproject/project.xml; /cvs/visualweb/designtimeext/nbproject/project.xml,v <-- project.xml new revision: 1.7; previous revision: 1.6 done
What compile errors? Does project.xml correctly specify the <class-path-extension>?
I cannot reproduce the undefined symbol compile error after updating, cleaning and rebuilding. Checking in build.xml; /cvs/visualweb/designtime/build.xml,v <-- build.xml new revision: 1.4; previous revision: 1.3 done Checking in nbproject/project.properties; /cvs/visualweb/designtime/nbproject/project.properties,v <-- project.properties new revision: 1.2; previous revision: 1.1 done Checking in nbproject/project.xml; /cvs/visualweb/designtime/nbproject/project.xml,v <-- project.xml new revision: 1.9; previous revision: 1.8 done Checking in rave/build.xml; /cvs/visualweb/designtime/rave/build.xml,v <-- build.xml new revision: 1.4; previous revision: 1.3 done Checking in rave/nbproject/project.properties; /cvs/visualweb/designtime/rave/nbproject/project.properties,v <-- project.properties new revision: 1.2; previous revision: 1.1 done Checking in rave/nbproject/project.xml; /cvs/visualweb/designtime/rave/nbproject/project.xml,v <-- project.xml new revision: 1.4; previous revision: 1.3 done
The build error was masked if you left the unversioned release/ dir on disk. Checking in visualweb/designtime/rave/library/nbproject/project.properties; /shared/data/ccvs/repository/visualweb/designtime/rave/library/nbproject/project.properties,v <-- project.properties new revision: 1.3; previous revision: 1.2 done
Thanks a lot Jesse. Yes, it must've been that I didn't remove the release directories and still got the stale binaries in my local build. So I didn't see the failure that I saw earlier. I waited for the build on deadlock and saw that it passed with my integration before I left the office. Unfortunately, that build got a stale release directory just like what I had.
Remaining fix: Checking in dataprovider/runtime/build.xml; /cvs/visualweb/dataprovider/runtime/build.xml,v <-- build.xml new revision: 1.4; previous revision: 1.3 done Checking in dataprovider/runtime/nbproject/project.properties; /cvs/visualweb/dataprovider/runtime/nbproject/project.properties,v <-- project.properties new revision: 1.2; previous revision: 1.1 done Checking in dataprovider/runtime/nbproject/project.xml; /cvs/visualweb/dataprovider/runtime/nbproject/project.xml,v <-- project.xml new revision: 1.5; previous revision: 1.4 done Checking in designer/html/build.xml; /cvs/visualweb/designer/html/build.xml,v <-- build.xml new revision: 1.3; previous revision: 1.2 done Checking in designer/html/nbproject/project.properties; /cvs/visualweb/designer/html/nbproject/project.properties,v <-- project.properties new revision: 1.2; previous revision: 1.1 done Checking in designer/html/nbproject/project.xml; /cvs/visualweb/designer/html/nbproject/project.xml,v <-- project.xml new revision: 1.4; previous revision: 1.3 done Checking in errorhandler/client/build.xml; /cvs/visualweb/errorhandler/client/build.xml,v <-- build.xml new revision: 1.4; previous revision: 1.3 done Checking in errorhandler/client/nbproject/project.properties; /cvs/visualweb/errorhandler/client/nbproject/project.properties,v <-- project.properties new revision: 1.2; previous revision: 1.1 done Checking in errorhandler/client/nbproject/project.xml; /cvs/visualweb/errorhandler/client/nbproject/project.xml,v <-- project.xml new revision: 1.4; previous revision: 1.3 done Checking in jsfsupport/runtime/build.xml; /cvs/visualweb/jsfsupport/runtime/build.xml,v <-- build.xml new revision: 1.4; previous revision: 1.3 done Checking in jsfsupport/runtime/nbproject/project.properties; /cvs/visualweb/jsfsupport/runtime/nbproject/project.properties,v <-- project.properties new revision: 1.2; previous revision: 1.1 done Checking in jsfsupport/runtime/nbproject/project.xml; /cvs/visualweb/jsfsupport/runtime/nbproject/project.xml,v <-- project.xml new revision: 1.4; previous revision: 1.3 done Checking in propertyeditors/api/build.xml; /cvs/visualweb/propertyeditors/api/build.xml,v <-- build.xml new revision: 1.4; previous revision: 1.3 done Checking in propertyeditors/api/nbproject/project.properties; /cvs/visualweb/propertyeditors/api/nbproject/project.properties,v <-- project.properties new revision: 1.2; previous revision: 1.1 done Checking in propertyeditors/api/nbproject/project.xml; /cvs/visualweb/propertyeditors/api/nbproject/project.xml,v <-- project.xml new revision: 1.3; previous revision: 1.2 done Checking in propertyeditors/resolver/build.xml; /cvs/visualweb/propertyeditors/resolver/build.xml,v <-- build.xml new revision: 1.4; previous revision: 1.3 done Checking in propertyeditors/resolver/nbproject/project.properties; /cvs/visualweb/propertyeditors/resolver/nbproject/project.properties,v <-- project.properties new revision: 1.2; previous revision: 1.1 done Checking in propertyeditors/resolver/nbproject/project.xml; /cvs/visualweb/propertyeditors/resolver/nbproject/project.xml,v <-- project.xml new revision: 1.3; previous revision: 1.2 done Checking in ravelibs/batik/build.xml; /cvs/visualweb/ravelibs/batik/build.xml,v <-- build.xml new revision: 1.3; previous revision: 1.2 done Checking in ravelibs/batik/nbproject/project.properties; /cvs/visualweb/ravelibs/batik/nbproject/project.properties,v <-- project.properties new revision: 1.2; previous revision: 1.1 done Checking in ravelibs/batik/nbproject/project.xml; /cvs/visualweb/ravelibs/batik/nbproject/project.xml,v <-- project.xml new revision: 1.3; previous revision: 1.2 done Checking in ravelibs/jsf-metadata/build.xml; /cvs/visualweb/ravelibs/jsf-metadata/build.xml,v <-- build.xml new revision: 1.4; previous revision: 1.3 done Checking in ravelibs/jsf-metadata/nbproject/project.properties; /cvs/visualweb/ravelibs/jsf-metadata/nbproject/project.properties,v <-- project.properties new revision: 1.2; previous revision: 1.1 done Checking in ravelibs/jtidy/build.xml; /cvs/visualweb/ravelibs/jtidy/build.xml,v <-- build.xml new revision: 1.3; previous revision: 1.2 done Checking in ravelibs/jtidy/nbproject/project.properties; /cvs/visualweb/ravelibs/jtidy/nbproject/project.properties,v <-- project.properties new revision: 1.2; previous revision: 1.1 done Checking in ravelibs/jtidy/nbproject/project.xml; /cvs/visualweb/ravelibs/jtidy/nbproject/project.xml,v <-- project.xml new revision: 1.3; previous revision: 1.2 done Checking in webui/runtime/build.xml; /cvs/visualweb/webui/runtime/build.xml,v <-- build.xml new revision: 1.7; previous revision: 1.6 done Checking in webui/runtime/library/nbproject/project.properties; /cvs/visualweb/webui/runtime/library/nbproject/project.properties,v <-- project.properties new revision: 1.6; previous revision: 1.5 done Checking in webui/runtime/nbproject/project.properties; /cvs/visualweb/webui/runtime/nbproject/project.properties,v <-- project.properties new revision: 1.2; previous revision: 1.1 done Checking in webui/runtime/nbproject/project.xml; /cvs/visualweb/webui/runtime/nbproject/project.xml,v <-- project.xml new revision: 1.3; previous revision: 1.2 done
Don't forget to delete obsolete .cvsignore files, if applicable (I have not yet checked).
I didn't find any obsolete .cvsignore in the modules directories that I modified. Is there any value in updating the .cvsignore that still reference the "release" directory in the module location (e.g. visualweb/dataprovider/runtime/.cvsignore)? I didn't update those yet since I'm not clear on the benefit for that. BTW, there is one module visualweb/ravelibs/rowset that I didn't make any changes to because its release directory contains the static binaries. The target rowset-doc-zip to generate the javadoc zip and place it in the release directory for this library is not being called and since we don't modify this library, I don't see any need to activate this target since we don't intend to modify this library anytime. Just a general comment on this whole exercise, I think it's a lot easier to understand and manage to place all the binaries in a release directory and in multiple places like copying the binaries to the nbbuild/netbeans directly, list the specific binaries in the modules' nbproject's project.properties, fix the binary-origin, etc. I can see that if there are changes to the binaries, it's very likely that I might not remember to update so many different places. In addition, we haven't yet experienced any problems doing it the "incorrect" way so far.
Yes you need to update .cvsignore files mentioning obsolete files or directories which should no longer be created during a build. Otherwise the stale .cvsignore can mask the presence of a file which should no longer be there and could potentially break the build - as happened before. For visualweb/ravelibs/rowset, it is fine to keep the release/ so dir so long as its contents are CVS-controlled and not created/updated by the regular build. Maybe you have not experienced the problems with the incorrect build setup, but I have (or I would not have noticed the problems in visualweb and filed this bug report). Files get copied or not depending on whether you do an incremental build, NBMs arbitrarily have the wrong contents, etc. I set up this system and designed the release dir to handle only fixed contents which do not vary during the lifecycle of the build, as a simplified shortcut for the general case of NBM contents which must be created dynamically.
Remove "release" from the .cvsignore files since they no longer exist: Checking in appbase/.cvsignore; /cvs/visualweb/appbase/.cvsignore,v <-- .cvsignore new revision: 1.2; previous revision: 1.1 done Checking in dataprovider/runtime/.cvsignore; /cvs/visualweb/dataprovider/runtime/.cvsignore,v <-- .cvsignore new revision: 1.3; previous revision: 1.2 done Checking in designer/html/.cvsignore; /cvs/visualweb/designer/html/.cvsignore,v <-- .cvsignore new revision: 1.2; previous revision: 1.1 done Checking in designtime/.cvsignore; /cvs/visualweb/designtime/.cvsignore,v <-- .cvsignore new revision: 1.3; previous revision: 1.2 done Checking in designtime/rave/.cvsignore; /cvs/visualweb/designtime/rave/.cvsignore,v <-- .cvsignore new revision: 1.2; previous revision: 1.1 done Checking in designtimeext/.cvsignore; /cvs/visualweb/designtimeext/.cvsignore,v <-- .cvsignore new revision: 1.2; previous revision: 1.1 done Checking in errorhandler/client/.cvsignore; /cvs/visualweb/errorhandler/client/.cvsignore,v <-- .cvsignore new revision: 1.2; previous revision: 1.1 done Checking in jsfsupport/runtime/.cvsignore; /cvs/visualweb/jsfsupport/runtime/.cvsignore,v <-- .cvsignore new revision: 1.2; previous revision: 1.1 done Checking in propertyeditors/api/.cvsignore; /cvs/visualweb/propertyeditors/api/.cvsignore,v <-- .cvsignore new revision: 1.2; previous revision: 1.1 done Checking in propertyeditors/resolver/.cvsignore; /cvs/visualweb/propertyeditors/resolver/.cvsignore,v <-- .cvsignore new revision: 1.2; previous revision: 1.1 done Checking in ravelibs/batik/.cvsignore; /cvs/visualweb/ravelibs/batik/.cvsignore,v <-- .cvsignore new revision: 1.2; previous revision: 1.1 done Checking in ravelibs/jsf-metadata/.cvsignore; /cvs/visualweb/ravelibs/jsf-metadata/.cvsignore,v <-- .cvsignore new revision: 1.3; previous revision: 1.2 done Checking in ravelibs/jtidy/.cvsignore; /cvs/visualweb/ravelibs/jtidy/.cvsignore,v <-- .cvsignore new revision: 1.2; previous revision: 1.1 done Checking in webui/runtime/.cvsignore; /cvs/visualweb/webui/runtime/.cvsignore,v <-- .cvsignore new revision: 1.5; previous revision: 1.4 done
I think I'm done with this bug for now. I'm sure you'll let me know if that's not true :-).