[jboss-as7-dev] Modules and hidden packages

Wed Apr 3 12:39:53 EDT 2013

Could this or a package-level annotation be used at build time?

We already "automate" adding in the resource stuff for our module.xml 
files. I know, I know, it's via ant, but could we create a maven plugin 
instead?

On 4/3/13 11:25 AM, Jason Greene wrote:
> If that doesn't turn out another idea would be to use manifest attributes.
>
> That can then easily be placed in your project's pom file.
>
> On Apr 3, 2013, at 10:57 AM, "David M. Lloyd" <david.lloyd at redhat.com> wrote:
>
>> 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
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> --
> Jason T. Greene
> JBoss AS Lead / EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat