Re: [jboss-as7-dev] Modules and hidden packages

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