[jboss-dev] Public vs. Private APIs

[Ales Justin]

Music to everybodys ears ...

Sent from my iPhone

On Dec 16, 2008, at 23:19, "Sacha Labourey" <sacha.labourey at jboss.com>  
wrote:

> 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
>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development