[jboss-as7-dev] Modules and hidden packages

[Max Rydahl Andersen]

On Tue, Apr 02, 2013 at 11:37:05AM -0500, David M. Lloyd wrote:
>The problem is compatibility - because such packages are shared today,
>making them suddenly be unshared on a global basis would likely break
>things.  I would however be in favor of adding *._private.* support, or
>using another unlikely-to-exist option (_internal was suggested).

Isn't the best combo something like *._internal.* is default and if you 
do specify a filter in modules.xml (I assume that is possible) then 
you have to explicitly exclude *._internal.* ?

btw. +1 for me to use _internal since private is related to a specific scope
and _internal is different kind of scope than private.

/max

>The reason for the underscore is twofold: first, "private" is a reserved
>word in Java so it can't be used from Java programs; second, it is not
>used by any projects that I am aware of at the moment, so the likelihood
>of breakage is basically zero.
>
>On 04/02/2013 11:29 AM, Emmanuel Bernard wrote:
>> 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
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
>
>-- 
>- DML
>_______________________________________________
>jboss-as7-dev mailing list
>jboss-as7-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/jboss-as7-dev