RE: [jboss-dev] Public vs. Private APIs

-----Original Message----- From: jboss-development-bounces(a)lists.jboss.org [mailto:jboss- development-bounces(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development