[jboss-as7-dev] Modules and hidden packages

[Jason Greene]

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