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

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 >