I got confused for a while but here what I understand now:
- you do support internal packages by explicitly listing them in the
module.xml
- you would like a fully convention base solution (like _internal) to
mark a package as private to avoid the maintenance of this manual list
- I think I'd prefer a feature allowing me to define a glob or similar
pattern in the module.xml to signal the list of private packages in a
concise, maintainable and portable way
My proposal is a tiny bit more costly (you need to define the glob in
module.xml once) but is more portable across the technologies we
integrate with.
Emmanuel
On Wed 2013-04-03 10:37, David M. Lloyd 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