[jsr294-modularity-eg] Nested superpackages
Andreas.Sterbenz at Sun.COM
Thu Apr 26 03:27:29 EDT 2007
Eugene Vigdorchik wrote:
> Nice explanation, Andreas. Still what happens if a superpackage is
> nested in more than one enclosing superpackage? As far as I understand,
> several deployment units may exist that will each include the classes
> from nested superpackage.While Strawman says: "it is expected that a
> superpackage and all its nested superpackages will form one deployment
> unit", it could be more specific to say that classes from nested
> superpackages could be included in other deployment units as well or
> form a separate deployment unit by themselves.
A superpackage cannot be nested in more than one enclosing superpackage.
Let me explain.
It is useful to think of a top level superpackage as one unit. Although it
is internally structured into packages and/or nested superpackages, they
are not meant to be detached from the enclosing superpackage.
As a bad analogy, think of a nested class and its enclosing class. The
nested class cannot live on its own. The same goes for a nested
superpackage, which is nested within one particular superpackage. It
should not be moved elsewhere or distributed on its own.
What you seem to suggest is that you would like some piece of code X to be
be a reusable component that can referenced from several different places.
If that is the case, X is a use case for deployment modules (i.e. JSR 277,
OSGi, etc.) and well addressed by those solutions. In other words, X would
become a top level superpackage packaged using the appropriate deployment
solution, and then referenced as a dependency by other deployment modules.
Nested superpackage have a different goal, which is information hiding
between subsystems within a project.
More information about the jsr294-modularity-eg