Modules and hidden packages

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

Modules and hidden packages

David Lloyd-2
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!

--
- 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
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
Reply | Threaded
Open this post in threaded view
|

Re: Modules and hidden packages

Emmanuel Bernard
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
Reply | Threaded
Open this post in threaded view
|

Re: Modules and hidden packages

Jeff Mesnil

Le 2 avr. 2013 à 18:29, Emmanuel Bernard <[hidden email]> a écrit :

> 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.

Eclipse uses .internal.* for internal implementation packages[1]. This looks more readable than _private.

As a personal preference, I prefer to have a suffix for internal impl package rather than a prefix: this makes the API and its implementation siblings in IDE or file hierarchy.


jeff

[1] http://wiki.eclipse.org/Naming_Conventions#Internal_Implementation_Packages

--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
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

David Lloyd-2
In reply to this post by Emmanuel Bernard
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
Reply | Threaded
Open this post in threaded view
|

Re: Modules and hidden packages

David Lloyd-2
In reply to this post by Brian Stansberry
The grim fact is that our logging ID scheme in the AS project is simply
not sustainable.  We have to change it or we will start running into
major problems, especially as we fork and branch things over time, and
even more so as we move towards finer-grained components and start
phasing components in and out.  The rename gives us an opportunity to do
so in a way that *is* sustainable.

We will not break any existing searches/KB keys, and it would be easy
enough (essential really) to provide a one-time, one-way mapping from
existing codes to future codes (the reverse would be impossible of
course, and undesirable in any case) which would be easy to publish.

It's painful, and awkward, but I believe this is something we must do,
so we should be sure to do it right.

On 04/02/2013 11:14 AM, Brian Stansberry 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!
>>
>
>


--
- 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

David Lloyd-2
In reply to this post by David Lloyd-2
Like I mentioned earlier though, there is a mechanism to exclude
arbitrary packages on a per-module basis; being non-global this
obviously avoids any general breakage, but it also requires explicit
modification of module.xml in the distribution environment.  This is
definitely an option for some cases though.

On 04/02/2013 11:37 AM, David M. Lloyd 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
Reply | Threaded
Open this post in threaded view
|

Re: Modules and hidden packages

Max Rydahl Andersen
In reply to this post by David Lloyd-2

On Tue, Apr 02, 2013 at 11:37:05AM -0500, David M. Lloyd 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).

Isn't the best combo something like *._internal.* is default and if you
do specify a filter in modules.xml (I assume that is possible) then
you have to explicitly exclude *._internal.* ?

btw. +1 for me to use _internal since private is related to a specific scope
and _internal is different kind of scope than private.

/max

>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
_______________________________________________
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

Emmanuel Bernard
In reply to this post by David Lloyd-2
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

_______________________________________________
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
In reply to this post by David Lloyd-2
On 4/2/13 11:40 AM, David M. Lloyd wrote:

> The grim fact is that our logging ID scheme in the AS project is simply
> not sustainable.  We have to change it or we will start running into
> major problems, especially as we fork and branch things over time, and
> even more so as we move towards finer-grained components and start
> phasing components in and out.  The rename gives us an opportunity to do
> so in a way that *is* sustainable.
>
> We will not break any existing searches/KB keys, and it would be easy
> enough (essential really) to provide a one-time, one-way mapping from
> existing codes to future codes (the reverse would be impossible of
> course, and undesirable in any case) which would be easy to publish.
>

Beyond "essentially really", I'd say required as part of the change, and
no change patch related to this is accepted unless this is part of it.
Then we are getting somewhere. If it's a task to do later it won't get
done, or it will become a crap task that some poor unlucky soul is stuck
with.

I also think any logging id conversion should be an AS 9 task. We don't
have the bandwidth now.

> It's painful, and awkward, but I believe this is something we must do,
> so we should be sure to do it right.
>
> On 04/02/2013 11:14 AM, Brian Stansberry 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
Reply | Threaded
Open this post in threaded view
|

Re: Modules and hidden packages

David Lloyd-2
On 04/02/2013 12:03 PM, Brian Stansberry wrote:

> On 4/2/13 11:40 AM, David M. Lloyd wrote:
>> The grim fact is that our logging ID scheme in the AS project is simply
>> not sustainable.  We have to change it or we will start running into
>> major problems, especially as we fork and branch things over time, and
>> even more so as we move towards finer-grained components and start
>> phasing components in and out.  The rename gives us an opportunity to do
>> so in a way that *is* sustainable.
>>
>> We will not break any existing searches/KB keys, and it would be easy
>> enough (essential really) to provide a one-time, one-way mapping from
>> existing codes to future codes (the reverse would be impossible of
>> course, and undesirable in any case) which would be easy to publish.
>>
>
> Beyond "essentially really", I'd say required as part of the change, and
> no change patch related to this is accepted unless this is part of it.
> Then we are getting somewhere. If it's a task to do later it won't get
> done, or it will become a crap task that some poor unlucky soul is stuck
> with.

Agreed.

> I also think any logging id conversion should be an AS 9 task. We don't
> have the bandwidth now.

Sounds fine, with the caveat that once the name is announced, any *new*
subsystems or components should start with the new scheme to avoid
needless conversion later on.
--
- 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
On 4/2/13 12:05 PM, David M. Lloyd wrote:

> On 04/02/2013 12:03 PM, Brian Stansberry wrote:
>> On 4/2/13 11:40 AM, David M. Lloyd wrote:
>>> The grim fact is that our logging ID scheme in the AS project is simply
>>> not sustainable.  We have to change it or we will start running into
>>> major problems, especially as we fork and branch things over time, and
>>> even more so as we move towards finer-grained components and start
>>> phasing components in and out.  The rename gives us an opportunity to do
>>> so in a way that *is* sustainable.
>>>
>>> We will not break any existing searches/KB keys, and it would be easy
>>> enough (essential really) to provide a one-time, one-way mapping from
>>> existing codes to future codes (the reverse would be impossible of
>>> course, and undesirable in any case) which would be easy to publish.
>>>
>>
>> Beyond "essentially really", I'd say required as part of the change, and
>> no change patch related to this is accepted unless this is part of it.
>> Then we are getting somewhere. If it's a task to do later it won't get
>> done, or it will become a crap task that some poor unlucky soul is stuck
>> with.
>
> Agreed.
>
>> I also think any logging id conversion should be an AS 9 task. We don't
>> have the bandwidth now.
>
> Sounds fine, with the caveat that once the name is announced, any *new*
> subsystems or components should start with the new scheme to avoid
> needless conversion later on.
>

Sounds good.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Modules and hidden packages

David Lloyd-2
In reply to this post by Emmanuel Bernard
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
Reply | Threaded
Open this post in threaded view
|

Re: Modules and hidden packages

Emmanuel Bernard
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" <[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
_______________________________________________
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

Jason T. Greene
In reply to this post by David Lloyd-2
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

_______________________________________________
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

David Lloyd-2
In reply to this post by Emmanuel Bernard
We do support globs in the module.xml export filter list as well, like this:

   <exports>
       <exclude name="**/impl/**"/>
   </exports>

So: I grant your wish. :)

On 04/03/2013 10:48 AM, Emmanuel Bernard wrote:

> 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" <[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
Reply | Threaded
Open this post in threaded view
|

Re: Modules and hidden packages

David Lloyd-2
In reply to this post by Jason T. Greene
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
Reply | Threaded
Open this post in threaded view
|

Re: Modules and hidden packages

Emmanuel Bernard
In reply to this post by David Lloyd-2
Ah awesome, then you've got my blessing on _whatever ;)

On Wed 2013-04-03 10:53, David M. Lloyd wrote:

> We do support globs in the module.xml export filter list as well, like this:
>
>    <exports>
>        <exclude name="**/impl/**"/>
>    </exports>
>
> So: I grant your wish. :)
>
> On 04/03/2013 10:48 AM, Emmanuel Bernard wrote:
> > 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" <[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
_______________________________________________
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

jtgreene
Administrator
In reply to this post by David Lloyd-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Modules and hidden packages

Brian Stansberry
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