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.
As we bring more javascript support functionality into NetBeans, it becomes apparent that we will increase the download size, especially the 3rd party javascript libraries. In addition, this functionality is web-specific and only makes sense to be included in the web-releated distros such as J2EE, Ruby and PHP distributions but not in Java SE or C++ distributions. Therefore, we need a new cluster. We propose that this new cluster name is 'webcommon'. Initially it only has: * javascript libraries * javascript debugger * JMaki * there might more such as glassfish.common, common server apis in the future releases per Petr Jiricka
Just to clarify that the specific modules to be included for 'javascript libraries' are marked as "Main" in the table http://wiki.netbeans.org/JavaScriptBundledLibraries.
Below is the proposed changes in the cluster.properties: diff --git a/nbbuild/cluster.properties b/nbbuild/cluster.properties --- a/nbbuild/cluster.properties +++ b/nbbuild/cluster.properties @@ -61,7 +61,8 @@ nb.cluster.profiler,\ nb.cluster.mobility,\ nb.cluster.visualweb,\ - nb.cluster.identity + nb.cluster.identity,\ + nb.cluster.webcommon clusters.config.full.list=\ ${clusters.config.standard.list},\ @@ -78,7 +79,8 @@ nb.cluster.harness,\ nb.cluster.ide,\ nb.cluster.gsf,\ - nb.cluster.php + nb.cluster.php,\ + nb.cluster.webcommon clusters.config.groovy.list=\ nb.cluster.nb,\ @@ -95,7 +97,9 @@ nb.cluster.harness,\ nb.cluster.ide,\ nb.cluster.gsf,\ - nb.cluster.ruby + nb.cluster.ruby,\ + nb.cluster.webcommon + clusters.config.cnd.list=\ nb.cluster.nb,\ @@ -117,7 +121,8 @@ ${clusters.config.java.list},\ nb.cluster.j2ee,\ nb.cluster.gsf,\ - nb.cluster.profiler + nb.cluster.profiler,\ + nb.cluster.webcommon clusters.config.soa.list=\ ${clusters.config.java.list},\ @@ -1128,14 +1133,7 @@ contrib/tasklist.usertasks,\ contrib/visualweb.samples.postrel,\ contrib/whichproject,\ - contrib/xtc,\ - javascript.libraries,\ - javascript.libraries.dojo,\ - javascript.libraries.jquery,\ - javascript.libraries.prototype,\ - javascript.libraries.scriptaculous,\ - javascript.libraries.woodstock,\ - javascript.libraries.yahooui + contrib/xtc nb.cluster.javafx.dir=javafx nb.cluster.javafx.depends=${clusters.config.full.list} @@ -1165,6 +1163,20 @@ nb.cluster.javafx # need to build j2ee and gsf to build profiler +# webcommon cluster +nb.cluster.webcommon.dir=webcommon1 +nb.cluster.webcommon.depends=\ + nb.cluster.platform,\ + nb.cluster.ide +nb.cluster.webcommon=\ + javascript.libraries,\ + javascript.libraries.dojo,\ + javascript.libraries.jquery,\ + javascript.libraries.kit,\ + javascript.libraries.prototype,\ + javascript.libraries.scriptaculous + javascript.libraries.woodstock,\ + javascript.libraries.yahooui # Unbuildable against new java/source: # contrib/importcruncher,\
Created attachment 63711 [details] diff of the changes I'm planning to make
I'd like to give a time out on this review in a day or so. So if I don't hear any objections by COB Tuesday 7/1/08 PST, I will take that this proposal is approved and I will proceed with the changes then. Thanks.
Chau, which pack this cluster would be placed to?
Since there are no objections, I've just now pushed the changes for adding this new cluster: changeset: 86871:1e080e9a7573 (the main changes in cluster.properties) changeset: 86872:dfba49b4711c changeset: 86870:9a64112d903 I'm now closing this issue as resolved (considered it as approved).
This cluster should be included in all the web distributions (packs) such as j2ee, php, ruby.
Chau, please don`t mix distribution and packs: - each distribution (column at the download page) is a unique set of packs. - each pack (row at the download page) is a unique set of clusters - in other words, each particular cluster can belong only to one pack (and to continue...) - each cluster is a unique set of modules (even though modules can move from one cluster to another during development process) - in other words, module can belong only to one cluster. This hierarchy has been created by NetBeans architects and we cannot violate it so easy. Dmitry
Well, so for installer context, this cluster should be included in web&javaEE, ruby and php packs. Does that make sense?
Let me try again, I'm not sure what you mean by each cluster can only belong to 1 pack. This cluster is included in multiple cluster configs in the cluster.properties file. Perhaps, I'm missing something. I believe that after the changes I made I was able to build netbeans with or without this cluster based on which config I want. For example, if I just want java config, ant -D"cluster.config=java" and it would build only the modules needed for this config, e.g. without the webcommon1 cluster. If I just want j2ee, ant -D"cluster.config=j2ee" will produce a build that contains all the modules needed for j2ee including this webcommon1 cluster, and so on. Is there a problem?
I'm not sure what dlipin is referring to exactly; has to do with the installer, nothing to do with the IDE itself, nor with nbbuild. We want the webcommon cluster to be present in the web-oriented distributions but not the Java SE distribution. Perhaps this means that webcommon has to be a "pack" all by itself; perhaps it means some assumptions made by the installer devs need to change. I don't see any particular significance to the rows in the download page, anyway; the footnote "you can add or remove packs later using the IDE's Plugin Manager" is misleading because the Plugin Manager operates at the module level (albeit hiding most modules), not the cluster level, much less the "pack" level. It is true that (visible) modules in the standard distribution are assigned display categories which happen to match row labels in the download page, but this has no deeper significance.
> I'm not sure what dlipin is referring to exactly; You can think of the pack as the "Category" of the plugin (in IDE) though it is not absolutely the same. > has to do with the installer, nothing to do with the IDE itself, nor with nbbuild. Yep. > We want the webcommon cluster to be present in the web-oriented distributions but not the Java SE distribution. That`s clear. BTW, why just not "web" but "webcommon" ? > Perhaps this means that webcommon has to be a "pack" all by itself; I think it is the only possible solution at the moment.. we`ll hide it from the d/l page, certainly. > perhaps it means some assumptions made by the installer devs need to change. Well... the "pack" (installable component) were proposed by Trung, it is not installer assumption. http://wiki.netbeans.org/NB6DownloadOptions http://wiki.netbeans.org/NB6InstallableComponents > I don't see any particular significance to the rows in the download page, anyway; xDesign wants to make this table simple and strictly against adding new rows at this moment. > the footnote "you can add or remove packs later using the IDE's Plugin Manager" is misleading because the Plugin Manager operates at the module level (albeit hiding most modules), not the cluster level, much less the "pack" level. I think that main reason for this wording is that when user is located at this page, it can be not clear for him what "plugin" is, but he has the obvious understanding what "pack" is what is offered by each pack (as it is listed on the d/ l page together with short description). > It is true that (visible) modules in the standard distribution are assigned display categories which happen to match row labels in the download page, but this has no deeper significance.
I don't think there was ever a rule that a cluster must belong to only one pack. But anyway, if you can have "hidden packs" then I guess that works too. The desired end result should be clear, right? Regarding the cluster name: "webcommon" maybe makes it clearer that this is only for "common" parts of web infrastructure, in particular not containing the bulk of the web application support which is in the enterprise cluster.
> I don't think there was ever a rule that a cluster must belong to only one pack. There is no special rule, but the reason is hackneyed. If we include the cluster in, say, three packs, then it would be included 3 times in the full installer. That significantly affects the size.. The other reason is that if one pack is uninstalled (possibly, not used now) then the cluster would be missing so the other clusters would have broken dependencies (and thus not all modules would start). > But anyway, if you can have "hidden packs" then I guess that works too. The desired end result should be clear, right? Right. > Regarding the cluster name: "webcommon" maybe makes it clearer that this is only for "common" parts of web infrastructure, in particular not containing the bulk of the web application support which is in the enterprise cluster. Thanks, clear.
The cluster is included in Java SE distribution (and I suspect also ME and C/C++) and it should not.
Can you please elaborate on how you discovered that this cluster exists in Java SE distribution?
I downloaded Java SE build 200807030007 and the webcommon1 is part of it.
Zip packaging of any kind (clusters/distributions) is usually handled by Build Engineering (CC-ing Robert and Michal). I`ll take care of installers once the cluster zip file is ready.
We need to find out how the zips for Java SE and other C/C++, etc. distributions are generated. Just FYI, when I did: ant -D"cluster.config=java", I don't see the 'webcommon1' cluster in my nbbuild/netbeans output directory. (BTW, this is the last email you see from me on this issue. Quy or Sandip will keep an eye on this issue going forward.)
Chau, In brief, zips are generated by BE using a special script which is located in main repo (nbbuild/newbuild/pack-all- components.sh). It is not updated automatically and does not depend on cluster.properties file.
I installed Java SE Download bundle today and I still see that webcommon1 cluster is installed. Is there some ction we (owners of modules in the webcommon1 cluster) need to take to handle this?
You can close this issue but you need to open a separate defect in "nbbuild/RE queue" requesting that nbbuild/newbuild be updated.
Closing. Filed another issue # 139180 as per Jesse's suggestion.