11:55 a.m.
For "my" modules I am more than happy to talk to customers if they use private /
impl packages. We did categorize them for that very reason and it took us a lot of effort.
I imagine we would enforce it in a major version shift anyways, so it worked be nice for
modules to support that even if for your modules you would not want to use the feature.
On 2 avr. 2013, at 18:37, "David M. Lloyd" <david.lloyd(a)redhat.com>
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).
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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
- DML
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev