Salut,
Sahoo wrote:
> We are currently exporting every package, which is not desirable. The
> attached zip file contains a file called bundles.xml, which lists
> packages being exported by each module. Please take some time to analyze
> your module and come up with the appropriate package list. It does not
> give a good picture of modularity when we have so many packages
> exported. If we can reduce the number of exported packages, the system
> will not only boot faster, it will also run a lot faster.
Hum..can you elaborate why we will run faster if we reduce the number of
exported package? Is it because of our classloader architecture?
Thanks
-- Jeanfrancois
This is in
> addition to improving the overall design of the modules.
>
> To identify the packages to be exported, you may like to use wires.xml
> file in the same zip file to get an idea of current package
> dependencies. Copy wires.xml and wires.xsl into the same folder and open
> wires.xml in any XSL aware editor (like firefox). If you see a package
> is imported only by the module that exports it, then that's likely to be
> removed from exported package list. Please note, this may not always be
> true, so use your own judgment. I am hoping that this should reduce the
> total number of exported packages drastically. Then we need to take the
> second step which is to identify the real module boundaries as per the
> module's design goals. The two steps can be done as one or more check-ins.
>
> Once you have identified correct set of exported package names, please
> *update* pom.xml of your module. We are investigating the possibility of
> adding some package level annotation to automatically generate this list
> during build, but until then when you add or remove any package, please
> also update the pom.xml.
>
> You may be tempted to ask why we are currently exporting every package.
> Well, without knowing what each module does, I had little choice but to
> export all the packages. It's not that big a problem when every module
> owner takes care of their individual modules.
>
> Thanks,
> Sahoo
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net