Bug 138433 - A new cluster webcommon proposal
A new cluster webcommon proposal
Status: RESOLVED FIXED
Product: javascript
Classification: Unclassified
Component: -- Other --
6.x
All All
: P1 (vote)
: 6.x
Assigned To: apireviews
issues@javascript
http://wiki.netbeans.org/WebCommonClu...
: API_REVIEW_FAST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-27 00:10 UTC by Ch Nguyen
Modified: 2009-02-27 14:45 UTC (History)
6 users (show)

See Also:
Issue Type: TASK
:


Attachments
diff of the changes I'm planning to make (8.23 KB, text/plain)
2008-06-30 21:30 UTC, Ch Nguyen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ch Nguyen 2008-06-27 00:11:00 UTC
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
Comment 1 Ch Nguyen 2008-06-27 23:29:43 UTC
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.


Comment 2 Ch Nguyen 2008-06-30 21:22:31 UTC
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,\
Comment 3 Ch Nguyen 2008-06-30 21:30:22 UTC
Created attachment 63711 [details]
diff of the changes I'm planning to make
Comment 4 Ch Nguyen 2008-06-30 21:43:58 UTC
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.
Comment 5 dlipin 2008-07-02 19:32:55 UTC
Chau, which pack this cluster would be placed to?
Comment 6 Ch Nguyen 2008-07-02 19:38:38 UTC
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).
Comment 7 Ch Nguyen 2008-07-02 19:41:03 UTC
This cluster should be included in all the web distributions (packs) such as j2ee, php, ruby.

Comment 8 dlipin 2008-07-02 19:58:40 UTC
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
Comment 9 Ch Nguyen 2008-07-02 20:31:10 UTC
Well, so for installer context, this cluster should be included in web&javaEE, ruby and php packs. Does that make sense?
Comment 10 Ch Nguyen 2008-07-02 20:39:04 UTC
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?
Comment 11 Jesse Glick 2008-07-02 22:31:13 UTC
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.
Comment 12 dlipin 2008-07-03 14:55:33 UTC
> 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.
Comment 13 Jesse Glick 2008-07-03 15:10:03 UTC
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.
Comment 14 dlipin 2008-07-03 15:25:47 UTC
> 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.

Comment 15 Pavel Buzek 2008-07-03 19:03:50 UTC
The cluster is included in Java SE distribution (and I suspect also ME and C/C++) and it should not.
Comment 16 Ch Nguyen 2008-07-03 19:31:17 UTC
Can you please elaborate on how you discovered that this cluster exists in Java SE distribution?
Comment 17 Pavel Buzek 2008-07-03 19:38:16 UTC
I downloaded Java SE build 200807030007 and the webcommon1 is part of it.
Comment 18 dlipin 2008-07-03 20:05:52 UTC
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.
Comment 19 Ch Nguyen 2008-07-03 21:44:12 UTC
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.)
Comment 20 dlipin 2008-07-07 10:57:58 UTC
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.
Comment 21 _ sandipchitale 2008-07-07 19:12:04 UTC
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?
Comment 22 Jesse Glick 2008-07-07 21:25:27 UTC
You can close this issue but you need to open a separate defect in "nbbuild/RE queue" requesting that nbbuild/newbuild
be updated.
Comment 23 _ sandipchitale 2008-07-07 22:32:58 UTC
Closing.

Filed another issue # 139180 as per Jesse's suggestion.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo