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!

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.

The problem is compatibility - because such packages are shared today, making them suddenly be unshared on a global basis would likely break things. I would however be in favor of adding *._private.* support, or using another unlikely-to-exist option (_internal was suggested). The reason for the underscore is twofold: first, "private" is a reserved word in Java so it can't be used from Java programs; second, it is not used by any projects that I am aware of at the moment, so the likelihood of breakage is basically zero. On 04/02/2013 11:29 AM, Emmanuel Bernard wrote: > A few projects already use *.impl.* or *.private.* packages. Any reasons to use this unnatural (for Java) _private prefix? Could that be made a customizable Glob or regexp like pattern in the xml dd. > > On 2 avr. 2013, at 18:14, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > >> Our logging IDs are already in the wild and are keys to knowledge base >> entries and google results. Is changing these a case where we are >> imposing pain on users in order to solve our own internal process problems? >> >> On 4/2/13 10:47 AM, David M. Lloyd wrote: >>> There is a mechanism in JBoss Modules to support packages which are not >>> visible to consumers of a module. The idea is to come up with an easy >>> convention so that we can put module-private APIs and classes in one >>> place that is visible from multiple packages, without exposing or >>> documenting these packages. >>> >>> Until 1.2, the only way available to do this for statically defined >>> modules was to add an export filter in your module.xml via the <exports> >>> element to exclude the specific package directories that are hidden. >>> >>> Starting in 1.2, you can also create a series of packages whose first >>> segment is "_private". These packages will automatically be excluded >>> from the exported paths list. >>> >>> What I'd like to propose is: >>> >>> 1) For any given module, all generated JavaDoc should exclude packages >>> under the _private hierarchy. >>> 2) For any module which does i18n logging, all logging messages should >>> be consolidated in one or more (but preferably one) interface(s) stored >>> in a public _private.org.yourproject.YourInterface. >>> 3) Once the new name is announced, I think we should break up our main >>> logging IDs into per-subsystem categories. For example, "XXEE" for EE, >>> "XXEJB" for EJB, etc., each with their own numerical space and message >>> interface. These two changes should put an end to our log message ID >>> fragmentation problems and give us a (one-time only!) chance to clean up >>> this mess. >>> 4) Projects that wish to exploit this mechanism can do so, noting that >>> they should use "_private.org.yourproject" as a package prefix instead >>> of just putting things directly under "_private" (to avoid conflicts >>> when JARs are used on a flat class path). >>> >>> Flame on! >>> >> >> >> -- >> Brian Stansberry >> Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >

The problem is compatibility - because such packages are shared today, making them suddenly be unshared on a global basis would likely break things. I would however be in favor of adding *._private.* support, or using another unlikely-to-exist option (_internal was suggested). The reason for the underscore is twofold: first, "private" is a reserved word in Java so it can't be used from Java programs; second, it is not used by any projects that I am aware of at the moment, so the likelihood of breakage is basically zero. On 04/02/2013 11:29 AM, Emmanuel Bernard wrote: > A few projects already use *.impl.* or *.private.* packages. Any reasons to use this unnatural (for Java) _private prefix? Could that be made a customizable Glob or regexp like pattern in the xml dd. > > On 2 avr. 2013, at 18:14, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > >> Our logging IDs are already in the wild and are keys to knowledge base >> entries and google results. Is changing these a case where we are >> imposing pain on users in order to solve our own internal process problems? >> >> On 4/2/13 10:47 AM, David M. Lloyd wrote: >>> There is a mechanism in JBoss Modules to support packages which are not >>> visible to consumers of a module. The idea is to come up with an easy >>> convention so that we can put module-private APIs and classes in one >>> place that is visible from multiple packages, without exposing or >>> documenting these packages. >>> >>> Until 1.2, the only way available to do this for statically defined >>> modules was to add an export filter in your module.xml via the <exports> >>> element to exclude the specific package directories that are hidden. >>> >>> Starting in 1.2, you can also create a series of packages whose first >>> segment is "_private". These packages will automatically be excluded >>> from the exported paths list. >>> >>> What I'd like to propose is: >>> >>> 1) For any given module, all generated JavaDoc should exclude packages >>> under the _private hierarchy. >>> 2) For any module which does i18n logging, all logging messages should >>> be consolidated in one or more (but preferably one) interface(s) stored >>> in a public _private.org.yourproject.YourInterface. >>> 3) Once the new name is announced, I think we should break up our main >>> logging IDs into per-subsystem categories. For example, "XXEE" for EE, >>> "XXEJB" for EJB, etc., each with their own numerical space and message >>> interface. These two changes should put an end to our log message ID >>> fragmentation problems and give us a (one-time only!) chance to clean up >>> this mess. >>> 4) Projects that wish to exploit this mechanism can do so, noting that >>> they should use "_private.org.yourproject" as a package prefix instead >>> of just putting things directly under "_private" (to avoid conflicts >>> when JARs are used on a flat class path). >>> >>> Flame on! >> >> >> -- >> Brian Stansberry >> Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev -- - DML _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Like I said we already support private packages for the cases where the user (or integrator rather) doesn't mind spelling out those packages in the module.xml. I'm just talking about doing this on an automatic basis for certain specially named packages so that this part is not necessary. It's sounding like a lot of folks don't care for the idea though. I had wanted to support the use of a package-level annotation but there seems to be no way to do this that doesn't kill perf... oh well. I don't think this is something that would really impact customers or end users in any way though, unless we use a common package name segment. Is that what you're getting at? On 04/02/2013 11:55 AM, Emmanuel Bernard wrote: > For "my" modules I am more than happy to talk to customers if they use private / impl packages. We did categorize them for that very reason and it took us a lot of effort. I imagine we would enforce it in a major version shift anyways, so it worked be nice for modules to support that even if for your modules you would not want to use the feature. > > On 2 avr. 2013, at 18:37, "David M. Lloyd" <david.lloyd(a)redhat.com&gt; wrote: > >> The problem is compatibility - because such packages are shared today, >> making them suddenly be unshared on a global basis would likely break >> things. I would however be in favor of adding *._private.* support, or >> using another unlikely-to-exist option (_internal was suggested). >> >> The reason for the underscore is twofold: first, "private" is a reserved >> word in Java so it can't be used from Java programs; second, it is not >> used by any projects that I am aware of at the moment, so the likelihood >> of breakage is basically zero. >> >> On 04/02/2013 11:29 AM, Emmanuel Bernard wrote: >>> A few projects already use *.impl.* or *.private.* packages. Any reasons to use this unnatural (for Java) _private prefix? Could that be made a customizable Glob or regexp like pattern in the xml dd. >>> >>> On 2 avr. 2013, at 18:14, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: >>> >>>> Our logging IDs are already in the wild and are keys to knowledge base >>>> entries and google results. Is changing these a case where we are >>>> imposing pain on users in order to solve our own internal process problems? >>>> >>>> On 4/2/13 10:47 AM, David M. Lloyd wrote: >>>>> There is a mechanism in JBoss Modules to support packages which are not >>>>> visible to consumers of a module. The idea is to come up with an easy >>>>> convention so that we can put module-private APIs and classes in one >>>>> place that is visible from multiple packages, without exposing or >>>>> documenting these packages. >>>>> >>>>> Until 1.2, the only way available to do this for statically defined >>>>> modules was to add an export filter in your module.xml via the <exports> >>>>> element to exclude the specific package directories that are hidden. >>>>> >>>>> Starting in 1.2, you can also create a series of packages whose first >>>>> segment is "_private". These packages will automatically be excluded >>>>> from the exported paths list. >>>>> >>>>> What I'd like to propose is: >>>>> >>>>> 1) For any given module, all generated JavaDoc should exclude packages >>>>> under the _private hierarchy. >>>>> 2) For any module which does i18n logging, all logging messages should >>>>> be consolidated in one or more (but preferably one) interface(s) stored >>>>> in a public _private.org.yourproject.YourInterface. >>>>> 3) Once the new name is announced, I think we should break up our main >>>>> logging IDs into per-subsystem categories. For example, "XXEE" for EE, >>>>> "XXEJB" for EJB, etc., each with their own numerical space and message >>>>> interface. These two changes should put an end to our log message ID >>>>> fragmentation problems and give us a (one-time only!) chance to clean up >>>>> this mess. >>>>> 4) Projects that wish to exploit this mechanism can do so, noting that >>>>> they should use "_private.org.yourproject" as a package prefix instead >>>>> of just putting things directly under "_private" (to avoid conflicts >>>>> when JARs are used on a flat class path). >>>>> >>>>> Flame on! >>>> >>>> >>>> -- >>>> Brian Stansberry >>>> Principal Software Engineer >>>> JBoss by Red Hat >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> >> -- >> - DML >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev -- - DML _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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" <david.lloyd(a)redhat.com&gt; wrote: >>> >>>> The problem is compatibility - because such packages are shared today, >>>> making them suddenly be unshared on a global basis would likely break >>>> things. I would however be in favor of adding *._private.* support, or >>>> using another unlikely-to-exist option (_internal was suggested). >>>> >>>> The reason for the underscore is twofold: first, "private" is a reserved >>>> word in Java so it can't be used from Java programs; second, it is not >>>> used by any projects that I am aware of at the moment, so the likelihood >>>> of breakage is basically zero. >>>> >>>> On 04/02/2013 11:29 AM, Emmanuel Bernard wrote: >>>>> A few projects already use *.impl.* or *.private.* packages. Any reasons to use this unnatural (for Java) _private prefix? Could that be made a customizable Glob or regexp like pattern in the xml dd. >>>>> >>>>> On 2 avr. 2013, at 18:14, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: >>>>> >>>>>> Our logging IDs are already in the wild and are keys to knowledge base >>>>>> entries and google results. Is changing these a case where we are >>>>>> imposing pain on users in order to solve our own internal process problems? >>>>>> >>>>>> On 4/2/13 10:47 AM, David M. Lloyd wrote: >>>>>>> There is a mechanism in JBoss Modules to support packages which are not >>>>>>> visible to consumers of a module. The idea is to come up with an easy >>>>>>> convention so that we can put module-private APIs and classes in one >>>>>>> place that is visible from multiple packages, without exposing or >>>>>>> documenting these packages. >>>>>>> >>>>>>> Until 1.2, the only way available to do this for statically defined >>>>>>> modules was to add an export filter in your module.xml via the <exports> >>>>>>> element to exclude the specific package directories that are hidden. >>>>>>> >>>>>>> Starting in 1.2, you can also create a series of packages whose first >>>>>>> segment is "_private". These packages will automatically be excluded >>>>>>> from the exported paths list. >>>>>>> >>>>>>> What I'd like to propose is: >>>>>>> >>>>>>> 1) For any given module, all generated JavaDoc should exclude packages >>>>>>> under the _private hierarchy. >>>>>>> 2) For any module which does i18n logging, all logging messages should >>>>>>> be consolidated in one or more (but preferably one) interface(s) stored >>>>>>> in a public _private.org.yourproject.YourInterface. >>>>>>> 3) Once the new name is announced, I think we should break up our main >>>>>>> logging IDs into per-subsystem categories. For example, "XXEE" for EE, >>>>>>> "XXEJB" for EJB, etc., each with their own numerical space and message >>>>>>> interface. These two changes should put an end to our log message ID >>>>>>> fragmentation problems and give us a (one-time only!) chance to clean up >>>>>>> this mess. >>>>>>> 4) Projects that wish to exploit this mechanism can do so, noting that >>>>>>> they should use "_private.org.yourproject" as a package prefix instead >>>>>>> of just putting things directly under "_private" (to avoid conflicts >>>>>>> when JARs are used on a flat class path). >>>>>>> >>>>>>> Flame on! >>>>>> >>>>>> >>>>>> -- >>>>>> Brian Stansberry >>>>>> Principal Software Engineer >>>>>> JBoss by Red Hat >>>>>> _______________________________________________ >>>>>> jboss-as7-dev mailing list >>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>> >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>>> >>>> -- >>>> - DML >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> >> -- >> - DML >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev -- - DML _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

What about sticking a market file in the package (e.g. "PRIVATE")? On Apr 3, 2013, at 10:40 AM, "David M. Lloyd" <david.lloyd(a)redhat.com&gt; wrote: > Like I said we already support private packages for the cases where the > user (or integrator rather) doesn't mind spelling out those packages in > the module.xml. > > I'm just talking about doing this on an automatic basis for certain > specially named packages so that this part is not necessary. It's > sounding like a lot of folks don't care for the idea though. > > I had wanted to support the use of a package-level annotation but there > seems to be no way to do this that doesn't kill perf... oh well. > > I don't think this is something that would really impact customers or > end users in any way though, unless we use a common package name > segment. Is that what you're getting at? > > On 04/02/2013 11:55 AM, Emmanuel Bernard wrote: >> For "my" modules I am more than happy to talk to customers if they use private / impl packages. We did categorize them for that very reason and it took us a lot of effort. I imagine we would enforce it in a major version shift anyways, so it worked be nice for modules to support that even if for your modules you would not want to use the feature. >> >> On 2 avr. 2013, at 18:37, "David M. Lloyd" <david.lloyd(a)redhat.com&gt; wrote: >> >>> The problem is compatibility - because such packages are shared today, >>> making them suddenly be unshared on a global basis would likely break >>> things. I would however be in favor of adding *._private.* support, or >>> using another unlikely-to-exist option (_internal was suggested). >>> >>> The reason for the underscore is twofold: first, "private" is a reserved >>> word in Java so it can't be used from Java programs; second, it is not >>> used by any projects that I am aware of at the moment, so the likelihood >>> of breakage is basically zero. >>> >>> On 04/02/2013 11:29 AM, Emmanuel Bernard wrote: >>>> A few projects already use *.impl.* or *.private.* packages. Any reasons to use this unnatural (for Java) _private prefix? Could that be made a customizable Glob or regexp like pattern in the xml dd. >>>> >>>> On 2 avr. 2013, at 18:14, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: >>>> >>>>> Our logging IDs are already in the wild and are keys to knowledge base >>>>> entries and google results. Is changing these a case where we are >>>>> imposing pain on users in order to solve our own internal process problems? >>>>> >>>>> On 4/2/13 10:47 AM, David M. Lloyd wrote: >>>>>> There is a mechanism in JBoss Modules to support packages which are not >>>>>> visible to consumers of a module. The idea is to come up with an easy >>>>>> convention so that we can put module-private APIs and classes in one >>>>>> place that is visible from multiple packages, without exposing or >>>>>> documenting these packages. >>>>>> >>>>>> Until 1.2, the only way available to do this for statically defined >>>>>> modules was to add an export filter in your module.xml via the <exports> >>>>>> element to exclude the specific package directories that are hidden. >>>>>> >>>>>> Starting in 1.2, you can also create a series of packages whose first >>>>>> segment is "_private". These packages will automatically be excluded >>>>>> from the exported paths list. >>>>>> >>>>>> What I'd like to propose is: >>>>>> >>>>>> 1) For any given module, all generated JavaDoc should exclude packages >>>>>> under the _private hierarchy. >>>>>> 2) For any module which does i18n logging, all logging messages should >>>>>> be consolidated in one or more (but preferably one) interface(s) stored >>>>>> in a public _private.org.yourproject.YourInterface. >>>>>> 3) Once the new name is announced, I think we should break up our main >>>>>> logging IDs into per-subsystem categories. For example, "XXEE" for EE, >>>>>> "XXEJB" for EJB, etc., each with their own numerical space and message >>>>>> interface. These two changes should put an end to our log message ID >>>>>> fragmentation problems and give us a (one-time only!) chance to clean up >>>>>> this mess. >>>>>> 4) Projects that wish to exploit this mechanism can do so, noting that >>>>>> they should use "_private.org.yourproject" as a package prefix instead >>>>>> of just putting things directly under "_private" (to avoid conflicts >>>>>> when JARs are used on a flat class path). >>>>>> >>>>>> Flame on! >>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Principal Software Engineer >>>>> JBoss by Red Hat >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> >>> -- >>> - DML >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > > -- > - DML > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

If that doesn't turn out another idea would be to use manifest attributes. That can then easily be placed in your project's pom file. On Apr 3, 2013, at 10:57 AM, "David M. Lloyd" <david.lloyd(a)redhat.com&gt; wrote: > That's an interesting idea. The problem though is that it requires the > resource loader to be accessed during linking (as opposed to just > scanning the string). That might have a lesser performance impact than > reading package-info.class, but I suspect it would still be > non-negligible. I'd have to test it and see what the impact is for sure > though - it could be a viable solution. > > On 04/03/2013 10:50 AM, Jason Greene wrote: >> What about sticking a market file in the package (e.g. "PRIVATE")? >> >> On Apr 3, 2013, at 10:40 AM, "David M. Lloyd" <david.lloyd(a)redhat.com&gt; wrote: >> >>> Like I said we already support private packages for the cases where the >>> user (or integrator rather) doesn't mind spelling out those packages in >>> the module.xml. >>> >>> I'm just talking about doing this on an automatic basis for certain >>> specially named packages so that this part is not necessary. It's >>> sounding like a lot of folks don't care for the idea though. >>> >>> I had wanted to support the use of a package-level annotation but there >>> seems to be no way to do this that doesn't kill perf... oh well. >>> >>> I don't think this is something that would really impact customers or >>> end users in any way though, unless we use a common package name >>> segment. Is that what you're getting at? >>> >>> On 04/02/2013 11:55 AM, Emmanuel Bernard wrote: >>>> For "my" modules I am more than happy to talk to customers if they use private / impl packages. We did categorize them for that very reason and it took us a lot of effort. I imagine we would enforce it in a major version shift anyways, so it worked be nice for modules to support that even if for your modules you would not want to use the feature. >>>> >>>> On 2 avr. 2013, at 18:37, "David M. Lloyd" <david.lloyd(a)redhat.com&gt; wrote: >>>> >>>>> The problem is compatibility - because such packages are shared today, >>>>> making them suddenly be unshared on a global basis would likely break >>>>> things. I would however be in favor of adding *._private.* support, or >>>>> using another unlikely-to-exist option (_internal was suggested). >>>>> >>>>> The reason for the underscore is twofold: first, "private" is a reserved >>>>> word in Java so it can't be used from Java programs; second, it is not >>>>> used by any projects that I am aware of at the moment, so the likelihood >>>>> of breakage is basically zero. >>>>> >>>>> On 04/02/2013 11:29 AM, Emmanuel Bernard wrote: >>>>>> A few projects already use *.impl.* or *.private.* packages. Any reasons to use this unnatural (for Java) _private prefix? Could that be made a customizable Glob or regexp like pattern in the xml dd. >>>>>> >>>>>> On 2 avr. 2013, at 18:14, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: >>>>>> >>>>>>> Our logging IDs are already in the wild and are keys to knowledge base >>>>>>> entries and google results. Is changing these a case where we are >>>>>>> imposing pain on users in order to solve our own internal process problems? >>>>>>> >>>>>>> On 4/2/13 10:47 AM, David M. Lloyd wrote: >>>>>>>> There is a mechanism in JBoss Modules to support packages which are not >>>>>>>> visible to consumers of a module. The idea is to come up with an easy >>>>>>>> convention so that we can put module-private APIs and classes in one >>>>>>>> place that is visible from multiple packages, without exposing or >>>>>>>> documenting these packages. >>>>>>>> >>>>>>>> Until 1.2, the only way available to do this for statically defined >>>>>>>> modules was to add an export filter in your module.xml via the <exports> >>>>>>>> element to exclude the specific package directories that are hidden. >>>>>>>> >>>>>>>> Starting in 1.2, you can also create a series of packages whose first >>>>>>>> segment is "_private". These packages will automatically be excluded >>>>>>>> from the exported paths list. >>>>>>>> >>>>>>>> What I'd like to propose is: >>>>>>>> >>>>>>>> 1) For any given module, all generated JavaDoc should exclude packages >>>>>>>> under the _private hierarchy. >>>>>>>> 2) For any module which does i18n logging, all logging messages should >>>>>>>> be consolidated in one or more (but preferably one) interface(s) stored >>>>>>>> in a public _private.org.yourproject.YourInterface. >>>>>>>> 3) Once the new name is announced, I think we should break up our main >>>>>>>> logging IDs into per-subsystem categories. For example, "XXEE" for EE, >>>>>>>> "XXEJB" for EJB, etc., each with their own numerical space and message >>>>>>>> interface. These two changes should put an end to our log message ID >>>>>>>> fragmentation problems and give us a (one-time only!) chance to clean up >>>>>>>> this mess. >>>>>>>> 4) Projects that wish to exploit this mechanism can do so, noting that >>>>>>>> they should use "_private.org.yourproject" as a package prefix instead >>>>>>>> of just putting things directly under "_private" (to avoid conflicts >>>>>>>> when JARs are used on a flat class path). >>>>>>>> >>>>>>>> Flame on! >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Brian Stansberry >>>>>>> Principal Software Engineer >>>>>>> JBoss by Red Hat >>>>>>> _______________________________________________ >>>>>>> jboss-as7-dev mailing list >>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>> >>>>>> _______________________________________________ >>>>>> jboss-as7-dev mailing list >>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>> >>>>> >>>>> -- >>>>> - DML >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> >>> -- >>> - DML >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > > -- > - DML > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev -- Jason T. Greene JBoss AS Lead / EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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" <david.lloyd(a)redhat.com&gt; wrote: >> >>> That's an interesting idea. The problem though is that it requires the >>> resource loader to be accessed during linking (as opposed to just >>> scanning the string). That might have a lesser performance impact than >>> reading package-info.class, but I suspect it would still be >>> non-negligible. I'd have to test it and see what the impact is for sure >>> though - it could be a viable solution. >>> >>> On 04/03/2013 10:50 AM, Jason Greene wrote: >>>> What about sticking a market file in the package (e.g. "PRIVATE")? >>>> >>>> On Apr 3, 2013, at 10:40 AM, "David M. Lloyd" <david.lloyd(a)redhat.com&gt; wrote: >>>> >>>>> Like I said we already support private packages for the cases where the >>>>> user (or integrator rather) doesn't mind spelling out those packages in >>>>> the module.xml. >>>>> >>>>> I'm just talking about doing this on an automatic basis for certain >>>>> specially named packages so that this part is not necessary. It's >>>>> sounding like a lot of folks don't care for the idea though. >>>>> >>>>> I had wanted to support the use of a package-level annotation but there >>>>> seems to be no way to do this that doesn't kill perf... oh well. >>>>> >>>>> I don't think this is something that would really impact customers or >>>>> end users in any way though, unless we use a common package name >>>>> segment. Is that what you're getting at? >>>>> >>>>> On 04/02/2013 11:55 AM, Emmanuel Bernard wrote: >>>>>> For "my" modules I am more than happy to talk to customers if they use private / impl packages. We did categorize them for that very reason and it took us a lot of effort. I imagine we would enforce it in a major version shift anyways, so it worked be nice for modules to support that even if for your modules you would not want to use the feature. >>>>>> >>>>>> On 2 avr. 2013, at 18:37, "David M. Lloyd" <david.lloyd(a)redhat.com&gt; wrote: >>>>>> >>>>>>> The problem is compatibility - because such packages are shared today, >>>>>>> making them suddenly be unshared on a global basis would likely break >>>>>>> things. I would however be in favor of adding *._private.* support, or >>>>>>> using another unlikely-to-exist option (_internal was suggested). >>>>>>> >>>>>>> The reason for the underscore is twofold: first, "private" is a reserved >>>>>>> word in Java so it can't be used from Java programs; second, it is not >>>>>>> used by any projects that I am aware of at the moment, so the likelihood >>>>>>> of breakage is basically zero. >>>>>>> >>>>>>> On 04/02/2013 11:29 AM, Emmanuel Bernard wrote: >>>>>>>> A few projects already use *.impl.* or *.private.* packages. Any reasons to use this unnatural (for Java) _private prefix? Could that be made a customizable Glob or regexp like pattern in the xml dd. >>>>>>>> >>>>>>>> On 2 avr. 2013, at 18:14, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: >>>>>>>> >>>>>>>>> Our logging IDs are already in the wild and are keys to knowledge base >>>>>>>>> entries and google results. Is changing these a case where we are >>>>>>>>> imposing pain on users in order to solve our own internal process problems? >>>>>>>>> >>>>>>>>> On 4/2/13 10:47 AM, David M. Lloyd wrote: >>>>>>>>>> There is a mechanism in JBoss Modules to support packages which are not >>>>>>>>>> visible to consumers of a module. The idea is to come up with an easy >>>>>>>>>> convention so that we can put module-private APIs and classes in one >>>>>>>>>> place that is visible from multiple packages, without exposing or >>>>>>>>>> documenting these packages. >>>>>>>>>> >>>>>>>>>> Until 1.2, the only way available to do this for statically defined >>>>>>>>>> modules was to add an export filter in your module.xml via the <exports> >>>>>>>>>> element to exclude the specific package directories that are hidden. >>>>>>>>>> >>>>>>>>>> Starting in 1.2, you can also create a series of packages whose first >>>>>>>>>> segment is "_private". These packages will automatically be excluded >>>>>>>>>> from the exported paths list. >>>>>>>>>> >>>>>>>>>> What I'd like to propose is: >>>>>>>>>> >>>>>>>>>> 1) For any given module, all generated JavaDoc should exclude packages >>>>>>>>>> under the _private hierarchy. >>>>>>>>>> 2) For any module which does i18n logging, all logging messages should >>>>>>>>>> be consolidated in one or more (but preferably one) interface(s) stored >>>>>>>>>> in a public _private.org.yourproject.YourInterface. >>>>>>>>>> 3) Once the new name is announced, I think we should break up our main >>>>>>>>>> logging IDs into per-subsystem categories. For example, "XXEE" for EE, >>>>>>>>>> "XXEJB" for EJB, etc., each with their own numerical space and message >>>>>>>>>> interface. These two changes should put an end to our log message ID >>>>>>>>>> fragmentation problems and give us a (one-time only!) chance to clean up >>>>>>>>>> this mess. >>>>>>>>>> 4) Projects that wish to exploit this mechanism can do so, noting that >>>>>>>>>> they should use "_private.org.yourproject" as a package prefix instead >>>>>>>>>> of just putting things directly under "_private" (to avoid conflicts >>>>>>>>>> when JARs are used on a flat class path). >>>>>>>>>> >>>>>>>>>> Flame on! >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Brian Stansberry >>>>>>>>> Principal Software Engineer >>>>>>>>> JBoss by Red Hat >>>>>>>>> _______________________________________________ >>>>>>>>> jboss-as7-dev mailing list >>>>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jboss-as7-dev mailing list >>>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> - DML >>>>>>> _______________________________________________ >>>>>>> jboss-as7-dev mailing list >>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>> >>>>> >>>>> -- >>>>> - DML >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> >>> -- >>> - DML >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> -- >> Jason T. Greene >> JBoss AS Lead / EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > >

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

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.