I was going to start a thread on one of the design forums but there isn't an overall AS design forum, so I'm posting to the dev list instead. We have been having a discussion within the TDM's about documenting the public vs. "private" API's. The problem we continue to have is customers start using API's that are usually, but not always, third-party libraries that are used as implementation details for an API we do mean for them to use. Of course, then they start asking for support of that usage. 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. What do you guys think? Is this even possible? Andy

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...

This is music to my ears... > -----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 _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development