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.
Is it possible to make the netbeans project ant script be usable on other computers without the netbeans IDE installed? I'm having trouble sharing version controlled projects with others who use different IDEs exclusively because the project build script would not run properly due to dependencies on the netbeans IDE. A related issue is the use of Libraries. Although this is a very nice feature, it also means that everyone sharing the project need to manually setup their libraries in the same way. It would be nice to incorporate ideas on library management from Maven. If netbeans could setup a centralized libary (or interface with maven's), and this library could be managed and synchronized from a revamped Library Manager, it would really improve netbeans' team collaboration.
That'd be great! Many of my team members use eclipse and they aksed me several times if i could use the netbeans ant script, but it didn't seem to work ...
Re. usability of script on other machines: should work as is, not sure what you mean. If you are referring to the default state of $userdir/build.properties being used to point to the NB platform, please read harness/README re. specifying a relative path for the platform (not yet supported directly thru GUI, possibly planned for a future release). For other problems, please use dev@openide.netbeans.org unless you think you have found a specific IDE bug. Re. libraries, Maven - off topic. We are looking at new library management GUIs for the next major NB release.
I build my module suite from the command line all the time. I've documented all the tricks I do with the harness build file in my blog. Take a look at http://weblogs.java.net/blog/richunger/archive/2005/12/module_suite_bu.html for an explanation of how to set your suite up with a canonical netbeans target image.
Thanks for the quick response guys. I'm really like the improvements in the 5.x release. But I guess you've overlooked my point - I don't have any problems running the build scripts from the command line because I have netbeans installed on my machine. But when my colleagues who don't have netbeans installed on their machines try using the NB-generated build scripts, the projects fail to build. The team that I have originally started with Eclipse and I'm the only one using netbeans. Although I would love to have them switch to netbeans, it is something that cannot be forced. I've created some projects using netbeans and checked in our VCS that they could not utilize properly since they don't have netbeans installed (and they refuse to install it). I understand that it might be hard to implement a generic build system that would be compatible with machines without NB installed. Maybe some sort of project export can be done so that it creates a zip bundle that includes all jar files specified in the Libraries plus any other jar dependencies that the build script needs to work. Something that "flattens" the project dependencies so that the exported build is self-contained. Thank you so much for your understanding.
No, what I've described works on a machine without netbeans installed.
I got your original point but I think you might not have read the relevant sections on the README on using a relative path and you didn't include details of your build failure, so I am assuming this is just a FAQ entry in the making rather than a full bug. What you describe about "flattening" of project dependencies is in fact under planning for a future NB release. But it is at the GUI layer, as a convenience; you can already express relative paths in the relevant properties files. In the case of NBM projects, the Library Manager is not used at all, so the only relevant path which might need to be flattened is that of the NB platform reference, which as mentioned can be set as a relative path (you need to manually edit .properties files for the time being). In the 5.0 update 1 release of the module development support, there is also the possibility of an explicit (non-default) JDK (as per Java Platform Manager) being set for a module/suite; again the build scripts permit this to be set to a relative path, though not yet via the GUI. To recap: any NB-created project (of any type) should be buildable on any machine after you check in the non-private portions of the project; in some cases you may need to first adjust .properties files (not build scripts) to supply relative paths to needed resources; a GUI to fully automate this kind of setup for the existing project types is in the planning stages.
I think I now know the reason why some of the NB projects fail to build properly: They were checked in using the beta/release-candidate versions of NB 5.0. The problems are indeed resolved in the final release of NB 5.0. :) I guess the only remaining issue is the use of the Library Manager in projects - the workaround of editing the project.properties file is easy to do anyway. But it is worth noting that if you really want your project to be portable, it is important to make it self-contained. Avoid the Library Manager for the time being. Thank you for clearing this up guys. And thanks for the useful tip for automated builds. This issue is fixed (it didn't actually need fixing to begin with).