[jboss-as7-dev] IMPORTANT!: I NEED FINALS LIST

[David M. Lloyd]

On 02/06/2012 03:00 AM, Carlo de Wolf wrote:
> On 02/04/2012 07:29 PM, David M. Lloyd wrote:
>> On 02/04/2012 04:52 AM, Carlo de Wolf wrote:
>>> On 02/03/2012 12:40 PM, Carlo de Wolf wrote:
>>>> On 02/02/2012 06:22 PM, Jason T. Greene wrote:
>>>>> org.jboss.ejb3.ext-api                2.0.0-beta-3
>>>>> org.jboss.metadata                    7.0.0.Beta35
>>>>>
>>>> Branch https://github.com/wolfc/metadata/tree/dependencies is waiting on:
>>>> - jboss-logging
>>> Upgraded to 3.1.0.GA.
>>>
>>>> - https://github.com/jboss/jboss-ejb-api_spec/pull/1
>>> I see it has been merged, but rolled back.
>>> What is the issue here?
>>> (Note that it can be viewed as a regression from 1.0.0 to 1.0.1.)
>> It can also be viewed as not a regression.  These dependencies should be
>> provided as they are only required if you actually reference those
>> classes.  Compile scope dependencies should only be used in APIs when
>> the API is completely unusable without the dependency.
>
> It is a known deficiency on the EG that EJB API has dependencies on JTA
> API and JAX-RPC API.
> Unfortunately there is nothing that can be done to change that.
>
> I think we should not make it any harder on consumers of the EJB API,
> because having the JTA API or JAX-RPC API through EJB API should not
> imply those functions are available.

I don't think it's particularly onerous at all.  At compile-time, if you 
don't use JTA or JAX-RPC then there is absolutely no benefit to having 
them on your compile class path.  It's not about available 
functionality.  It's about opting in to the features that you use, 
instead of opting out of features that the user probably isn't even 
aware of, and avoiding pointless class path explosion and all the 
problems that come with it.

> In fact the EJB container is obliged to have JAX-RPC API available even
> in lite mode, because else you would run into a problem with
> SessionContext.getMessageContext. The method itself however will throw
> an IllegalStateException.

Good thing Maven dependencies have absolutely nothing to do with the EJB 
container run time.

> In other words having EJB API provided, implies JTA API and JAX-RPC API
> are provided as well.

Not at all.  When something is "provided" in Maven, that doesn't mean 
that the dependency is provided.  The scope was named on the assumption 
of the run time disposition of the JAR, which is pretty silly given that 
Maven is a compile-time tool.  Think of "provided" as "import" and 
"compile" as "re-export" and you're a lot closer to reality (though of 
course Maven is very sloppy when it comes to actually assembling the 
artifacts since they're all flattened into one class path, so it's not 
perfectly identical to the corresponding modular terms).

The rule is this.  Given APIs named A and B, and B depends on A, the 
dependency should always be "provided" unless B is completely unusable 
without A, in which case the default "compile" is acceptable.
-- 
- DML