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.
I've noticed that the build files for the NetBeans clusters and modules do not have consistent semantics and capabilities with the build files generated for NetBeans projects. I started off the discussion on the platform developers mailing list here: http://netbeans-org.1045718.n5.nabble.com/Towards-a-Faster-Development-Cycle-for-NetBeans-Platform-Applications-tc4452169.html#none I find the build semantics with the NetBeans projects very nice. If I associate a project with a parent project, both projects get built. If I want to override a step or add a pre/post compile step for instance, it is very easy to do this in the project's build.xml file. If I associate a NetBeans cluster as a project with a parent NetBeans cluster, the child cluster does not get compiled. I wouldn't expect the dependent cluster to be rebuilt if I added it using "add cluster", but do if it was added using "add project" to the available libraries for the cluster. Even nicer would be to have a checkbox indicating whether the child cluster should be recompiled to deal with cases where there are dozens of dependent clusters. Furthermore, the cluster build scripts don't have the nice predefined steps like "-pre-compile" to make it easy for the developer to customize the build process for a given cluster. I was going to modify the ant build.xml file to force a build of the dependent clusters but then I thought that NetBeans must have an alternative way to build all of the clusters in the correct order without having to manually setup the dependencies. The NetBeans IDE has dozens of clusters or more that are built to support the IDE. A given cluster may depend on a few other clusters and each cluster needs to be built in the correct order. So does the NetBeans build process take a list of clusters and then automagically figure out which one needs to be built first using some predefined Ant task or is this done manually? Is this dependency analysis step defined somewhere in the build scripts? Another chronic issue with the build system is with dependent clusters that is a library wrapper module that points to a NetBeans project. NetBeans does not currently support automatic builds of the dependent NetBeans project in the case of the library wrapper module which forces developers to manually update the build process to do that in the usual way using method 2 of this reference: http://wiki.netbeans.org/DevFaqWrapperModules. In summary, I'd like to see the NetBeans platform build system be as intuitive and user-friendly as the NetBeans project build system.
They don't. Copy/move the project sources from one suite to netbeans.org or vice/versa however converts the format appripriatelly.
Jaroslav, I don't understand how your comment addresses this bug. Would you please elucidate? Thanks, Rob
(In reply to comment #0) > If I associate a NetBeans cluster as a project with a parent NetBeans cluster, > the child cluster does not get compiled. Correct. There are no plans to implement such a dependent build for Ant-based NBM development. Maven is recommended for complex builds. > the cluster build scripts don't have the nice predefined steps > like "-pre-compile" to make it easy for the developer to customize the build > process for a given cluster. None are needed. Override the standard target; to call the standard impl before, add it to the dependencies list; to call it after, use <antcall>. > The NetBeans IDE has dozens of clusters or more that are > built to support the IDE. A given cluster may depend on a few other > clusters and each cluster needs to be built in the correct order. So > does the NetBeans build process take a list of clusters and then > automagically figure out which one needs to be built first using some > predefined Ant task or is this done manually? Mostly manually. > Another chronic issue with the build system is with dependent clusters that is > a library wrapper module that points to a NetBeans project. NetBeans does not > currently support automatic builds of the > dependent NetBeans project in the case of the library wrapper module This is already filed separately. No immediate plans to fix. Again this comes "for free" with Maven-based projects. (In reply to comment #2) > I don't understand how your comment addresses this bug. It does not address it; I think jtulach was just misinterpreting the report.
This is not an acceptable answer. The current implementation is Ant. That solution should be supported until all of the build files from all clusters and modules can be migrated to maven (or whatever flavor-of-the-month build system becomes popular in the future.) I'll answer the rest in-line.
(In reply to comment #3) > (In reply to comment #0) > > If I associate a NetBeans cluster as a project with a parent NetBeans cluster, > > the child cluster does not get compiled. > > Correct. There are no plans to implement such a dependent build for Ant-based > NBM development. Maven is recommended for complex builds. This is not a complex build. When you add a cluster dependency via the "Add Project", it should build the dependent project just like the NetBeans projects build files do. Consistency is the #1 rule in programming guys. I'm just asking for consistency across your system. > > > the cluster build scripts don't have the nice predefined steps > > like "-pre-compile" to make it easy for the developer to customize the build > > process for a given cluster. > > None are needed. Override the standard target; to call the standard impl > before, add it to the dependencies list; to call it after, use <antcall>. If its so simple, why not just add this step to the build generation process so that every NB platform developer doesn't need to learn how to do this? The platform build files are much easier to customize. > > > The NetBeans IDE has dozens of clusters or more that are > > built to support the IDE. A given cluster may depend on a few other > > clusters and each cluster needs to be built in the correct order. So > > does the NetBeans build process take a list of clusters and then > > automagically figure out which one needs to be built first using some > > predefined Ant task or is this done manually? > > Mostly manually. That's a pity. If NetBeans would use the NetBeans generated build system to build NetBeans perhaps some of these usability issues would've been solved long ago! > > Another chronic issue with the build system is with dependent clusters that is > > a library wrapper module that points to a NetBeans project. NetBeans does not > > currently support automatic builds of the > > dependent NetBeans project in the case of the library wrapper module > > This is already filed separately. No immediate plans to fix. Again this comes > "for free" with Maven-based projects. Yes Bug# 179142 and Bug# 70894 first reported in 2006. I've performed the manual steps outlined in method 2 here http://wiki.netbeans.org/DevFaqWrapperModules many times. These could be automated without a lot of trouble. I know I could solve this myself with a custom script, but it'd be nice to have a solution that saves all of the developer's time. I don't see any options for generating Maven-based projects from a NetBeans module or cluster. Are you implying that I hand edit a Maven project to perform the build? Don't you all ever create multiple GUIs with shared clusters that are all in development? Its almost like you all don't use NetBeans to generate applications, otherwise these problems wouldn't exist. One reason I use NetBeans is that it generates the build files for me, which is a big time savings and allows developers to concentrate on what matters, the delivered code. The build is just a means to an end. The customer doesn't care how the code was built. By forcing developers to customize the build files through a manual process or by their own custom scripts further reduces the value of NetBeans. I recommend that the NetBeans team solve a few real-world problems with NetBeans from setting up clusters with dependent shared clusters, wrapping multiple NetBeans projects as module libraries, creating nightly builds to final installation on a Windows box for instance to see all of the glaring missing steps in the process.
(In reply to comment #5) > The platform build files are much easier to customize. > This should read "The NB project build files are much easier to customize."
(In reply to comment #5) > When you add a cluster dependency via the "Add Project", > it should build the dependent project Of course it _should_; what I said was that there was no _plan_ to implement it. Can leave this issue open to track that in case someone wants to work on it. (Other items are either already filed elsewhere, or are unrelated and should not be discussed in the same issue.) >> Override the standard target; to call the standard impl >> before, add it to the ✹dependencies list; to call it after, use <antcall>. > > why not just add this step to the build generation process I do not follow your question. There is a straightforward way to override behavior of _any_ imported Ant script, including calling the "super" implementation before or after your own. No special hooks are needed in the imported script. (For historical reasons j2seproject's have some.) > bug #70894 That is it. > I don't see any options for generating Maven-based projects from a NetBeans > module or cluster. There is no wizard for this yet. It has been mentioned as a possibility. > ... to see all of the glaring missing steps in the process. These are well known, but there are few resources to work on the Ant-based harness. Bear in mind that adding a feature to the harness is often much more work than adding the same feature to a particular application build. If the feature is optional, then at least a property is needed to control it, ideally with a matching GUI. If the feature involves performing zero or more similar steps - such as building subprojects - then since the Ant distribution includes no iteration facility beyond the very limited <subant> (except perhaps <script language="js">, which makes assumptions about the JRE), generally the steps need to be generated using XSLT, which also involves a project.xml schema change and the corresponding compatibility work; or a new task needs to be added. Any XML script fragments are susceptible to space-in-path or file separator problems which can evade initial testing. Many things have to be tested against unusual configurations such as external build directories.
I have no plans to work on a general concept like this. You can modify your own build script to do what you want including pre-building chained suites.
So are you saying that you don't agree that adding a project implies a dependency (consistent with the NetBeans project concept) or you just don't want to take time to do this? To limit the many hours your users will have to spend trying to figure out how to correctly add the dependency, I'd recommend at least putting a commented template of the ant code in the generated ant scripts so that the users can modify it similar to what is done with the NetBeans projects ant files. (I think consistency across the NetBeans build systems should be a goal.)
(In reply to comment #9) > So are you saying that you don't agree that adding a project implies a > dependency (consistent with the NetBeans project concept) or you just don't > want to take time to do this? The time is the issue (I am trying to use WONTFIX for valid problems that we don't have time to solve, otherwise I would close the problem as INVALID). If there is somebody in community who wants to donate a patch, feel free to do so and re-open any of my WONTFIX issues.