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

[Carlo de Wolf]

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

Carlo