[jboss-as7-dev] Modules and hidden packages

Wed Apr 3 11:57:25 EDT 2013

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" <david.lloyd at redhat.com> 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 at redhat.com> 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 at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >>>>>
> >>>>> _______________________________________________
> >>>>> jboss-as7-dev mailing list
> >>>>> jboss-as7-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >>>>
> >>>>
> >>>> --
> >>>> - DML
> >>>> _______________________________________________
> >>>> jboss-as7-dev mailing list
> >>>> jboss-as7-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >>
> >>
> >> --
> >> - DML
> >> _______________________________________________
> >> jboss-as7-dev mailing list
> >> jboss-as7-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> 
> 
> -- 
> - DML
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev