What about sticking a market file in the package (e.g. "PRIVATE")?
On Apr 3, 2013, at 10:40 AM, "David M. Lloyd" <david.lloyd(a)redhat.com>
wrote:
Like I said we already support private packages for the cases where
the
user (or integrator rather) doesn't mind spelling out those packages in
the module.xml.
I'm just talking about doing this on an automatic basis for certain
specially named packages so that this part is not necessary. It's
sounding like a lot of folks don't care for the idea though.
I had wanted to support the use of a package-level annotation but there
seems to be no way to do this that doesn't kill perf... oh well.
I don't think this is something that would really impact customers or
end users in any way though, unless we use a common package name
segment. Is that what you're getting at?
On 04/02/2013 11:55 AM, Emmanuel Bernard wrote:
> 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
--
- DML
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev