DevFaqSuitesVsClusters

(Difference between revisions)
m
Line 39: Line 39:
----
----
-
Applies to: NetBeans 6.5
+
Applies to: NetBeans 6.8 and above

Revision as of 15:05, 2 December 2009

What is the difference between a suite and a cluster?

Suite

A suite is a container project used to group external module projects into a unit whose members can refer to one another as well as to a NB platform. If you only have one module project, you can treat it as "standalone" and you do not need a suite, but using a suite is advisable for serious projects since it offers you more options, such as adding library wrapper modules, or creating a complete application based on your module.

Since NetBeans 6.7 a suite can depend either on another suite, standalone module or even external binary cluster, see DevFaq How To Reuse Modules. If you use version earlier than 6.7 a suite S2 cannot directly depend on another suite S1. But if S1 uses NB platform P1, you could create a derived platform P2 by building S1 on top of P1, and then select P2 as the NB platform for S2. Then S2 can refer to all the modules in P1 as well as the modules built from S1.

The NB IDE build (from sources on hg.netbeans.org) does not use suites. It uses a historical build infrastructure which partially overlaps the external module/suite build harness introduced in 5.0, but which has different requirements (and is considerably more complex). Module projects physically inside the netbeans.org source tree cannot be "standalone" modules nor "suite component" modules - they are simply netbeans.org modules, and as such use a (slightly) different format for metadata, and have access to somewhat different facilities specific to netbeans.org practices.

Cluster

A cluster is simply a subdirectory of a NB-based-app's binary installation; every module in the installation falls into one cluster. The installation is divided into clusters for purposes of:

  1. Conceptual clarity.
  2. Possible mapping to native packaging systems such as RPM.

The NB team has a policy of treating inter-cluster module dependencies as more significant than intra-cluster module dependencies with respect to backward compatibility, with the aim of making it possible for product teams building on top of the NB IDE to select a subset of the IDE to use with cluster granularity rather than with module granularity, which may be simpler to grasp and integrate with native packaging. But there is nothing preventing you from reusing a subset with module granularity.

The NB launcher (nbexec) accepts a list of cluster directories to load modules from - basically a search path. There are no further semantics to clusters.

The suite project type has a standard build target to assemble a complete application. For simplicity, it simply places all modules built from suite sources into their own cluster named in accordance with the suite's name.

NBMs may specify a cluster. The netbeans/ subdirectory of the NBM (which is a ZIP file) has a file layout which matches the layout of files within a single cluster. Each cluster managed by Auto Update has an update_tracking/ subdirectory with one XML file per module, enumerating the files which that module contributes to the cluster.

Currently the "NB Platform" is just the platform* cluster from the IDE, though the choice of modules may not be exactly what you want for every "platform" application.

Clusters are supposed to be medium-grained or coarse-grained, unlike modules which are generally fine-grained units.

References:


Applies to: NetBeans 6.8 and above

Not logged in. Log in, Register

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