[jboss-as7-dev] Modules and hidden packages

[Emmanuel Bernard]

A few projects already use *.impl.* or *.private.* packages. Any reasons to use this unnatural (for Java) _private prefix? Could that be made a customizable Glob or regexp like pattern in the xml dd. 

On 2 avr. 2013, at 18:14, Brian Stansberry <brian.stansberry at redhat.com> wrote:

> 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
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev