Modules and hidden packages

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Modules and hidden packages

David Lloyd-2
Anything is possible!  Requiring build time steps is historically
unpopular among certain... elements... but there is no technical reason
why it would not work.

On 04/03/2013 11:39 AM, Brian Stansberry wrote:

> 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" <[hidden email]> 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" <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
>>>>>>>>> [hidden email]
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> jboss-as7-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> - DML
>>>>>>> _______________________________________________
>>>>>>> jboss-as7-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>>
>>>>> --
>>>>> - DML
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
>


--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Modules and hidden packages

Brian Stansberry
Yes, a build time step would only make sense if the impact of any
runtime-only solution was prohibitive.

On 4/3/13 11:54 AM, David M. Lloyd wrote:

> Anything is possible!  Requiring build time steps is historically
> unpopular among certain... elements... but there is no technical reason
> why it would not work.
>
> On 04/03/2013 11:39 AM, Brian Stansberry wrote:
>> 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" <[hidden email]> 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" <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
>>>>>>>>>> [hidden email]
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> jboss-as7-dev mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> - DML
>>>>>>>> _______________________________________________
>>>>>>>> jboss-as7-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>
>>>>>>
>>>>>> --
>>>>>> - DML
>>>>>> _______________________________________________
>>>>>> jboss-as7-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>>
>>>> --
>>>> - DML
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>
>>
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12