[jboss-as7-dev] Modules and hidden packages

Wed Apr 3 11:57:19 EDT 2013

That's an interesting idea.  The problem though is that it requires the 
resource loader to be accessed during linking (as opposed to just 
scanning the string).  That might have a lesser performance impact than 
reading package-info.class, but I suspect it would still be 
non-negligible.  I'd have to test it and see what the impact is for sure 
though - it could be a viable solution.

On 04/03/2013 10:50 AM, Jason Greene wrote:
> 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 at 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 at 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 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
>>
>>
>> --
>> - DML
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

-- 
- DML