[jboss-dev] Public vs. Private APIs

Sacha Labourey sacha.labourey at jboss.com
Tue Dec 16 17:19:12 EST 2008


This is music to my ears...

> -----Original Message-----
> From: jboss-development-bounces at lists.jboss.org [mailto:jboss-
> development-bounces at lists.jboss.org] On Behalf Of Jason T. Greene
> Sent: mardi, 16 décembre 2008 20:53
> To: JBoss.org development list
> Subject: Re: [jboss-dev] Public vs. Private APIs
> 
> David M. Lloyd wrote:
> > On 12/05/2008 09:33 AM, Andrig Miller wrote:
> > ...
> >> As this discussion took place internally, we starting batting around
> >> the idea of separately all the things we would like to be private
> into
> >> its own lib directory.  So having one lib directory where have all
> the
> >> API's that we intend to have customers/users use, and one where we
> >> have everything else, so we can clearly communicate what should be
> >> used and what shouldn't be used directly.
> >
> > We should make *everything* private in my opinion.  Then, in *each*
> > deployer we decide what capabilities are implicitly imported (JavaEE
> > deployments will bring in the JavaEE classes for example) and use
> that
> > information to build classloading metadata for that module.
> >
> > Then we decide what other third-party capabilities we want to make
> > available to users by default, should they *explicitly* request them
> > (things like log4j/slf4j, quartz, hibernate, commons-crap, etc.
> spring
> > to mind).
> >
> > This would mean packaging up libraries with a wrapper JAR or
> something
> > and including a jboss-classloading.xml for each one.  There was a
> thread
> > in the MC development forum (I think) about this specifically, but I
> > can't find it...
> >
> 
> Exactly, in addition to isolating internal classes, we really need to
> have "API jars" for all of our proprietary APIs we support.
> 
> --
> Jason T. Greene
> JBoss, a division of Red Hat
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development





More information about the jboss-development mailing list