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

[David M. Lloyd]

On 02/06/2012 09:29 AM, Carlo de Wolf wrote:
> On 02/06/2012 02:58 PM, David M. Lloyd wrote:
>> 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.
>
> I agree with that.
>>
>>> 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.
>
> Not entirely true, whenever I fire up surefire my class path is dictated
> by Maven. Should I then use EJB Embeddable the EJB container runs on
> that class path as per spec. (I think we both agree that this is ugly as
> hell, but the spec is as such.)
>
> EJB 3.1 22.1
> "Embeddable usage requirements allow client code to instantiate an EJB
> container that runs within its
> own JVM and classloader."

This has no bearing on including JTA.

>>> 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).
>
> As long as you don't run surefire, then yes, Maven is a compile-time tool.
> Once you go into surefire, you get that sloppy one class path.
> I don't like Maven in this respect as well, but it is how it is.

This also has no bearing on including JTA.

>> 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.
> 'completely unusable' is non-definitive. It either works, or it does
> not. I've shown that it does not.

Untrue.  It works for many use cases; it just doesn't work in the case 
that you actually use the JTA dependency.  The solution is fortunately 
obvious: the user adds the JTA API to their project.

To make it even more clear, there are two options.  The first is that we 
automatically pull in the JTA API and the user must exclude it if they 
don't want it.  The second is that we exclude it by default and the user 
must include it if they _do_ want it.

The difference between these two is that the user will not exclude the 
dependency since they will tend to not know that it has been included 
for them.  This becomes a problem when the transitive dependency graph 
becomes large (which happens very quickly because this is unfortunately 
the default).  Explicit inclusion of non-essential dependencies is the 
superior option.

As I said the rule is quite clear - if the API is usable without the 
dependency then the dependency API should not automatically be included. 
  Specs do not enter into the equation.  It is only when the API cannot 
be used in any useful way that the dependency should be automatic.  I do 
not think there is really any gray here.  "Does not work sometimes" is 
not sufficient to justify a compile scope dependency.
-- 
- DML