[jboss-as7-dev] Modules and hidden packages
Brian Stansberry
brian.stansberry at redhat.com
Tue Apr 2 12:14:04 EDT 2013
Our logging IDs are already in the wild and are keys to knowledge base
entries and google results. Is changing these a case where we are
imposing pain on users in order to solve our own internal process problems?
On 4/2/13 10:47 AM, David M. Lloyd wrote:
> There is a mechanism in JBoss Modules to support packages which are not
> visible to consumers of a module. The idea is to come up with an easy
> convention so that we can put module-private APIs and classes in one
> place that is visible from multiple packages, without exposing or
> documenting these packages.
>
> Until 1.2, the only way available to do this for statically defined
> modules was to add an export filter in your module.xml via the <exports>
> element to exclude the specific package directories that are hidden.
>
> Starting in 1.2, you can also create a series of packages whose first
> segment is "_private". These packages will automatically be excluded
> from the exported paths list.
>
> What I'd like to propose is:
>
> 1) For any given module, all generated JavaDoc should exclude packages
> under the _private hierarchy.
> 2) For any module which does i18n logging, all logging messages should
> be consolidated in one or more (but preferably one) interface(s) stored
> in a public _private.org.yourproject.YourInterface.
> 3) Once the new name is announced, I think we should break up our main
> logging IDs into per-subsystem categories. For example, "XXEE" for EE,
> "XXEJB" for EJB, etc., each with their own numerical space and message
> interface. These two changes should put an end to our log message ID
> fragmentation problems and give us a (one-time only!) chance to clean up
> this mess.
> 4) Projects that wish to exploit this mechanism can do so, noting that
> they should use "_private.org.yourproject" as a package prefix instead
> of just putting things directly under "_private" (to avoid conflicts
> when JARs are used on a flat class path).
>
> Flame on!
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
More information about the jboss-as7-dev
mailing list