aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Re: Licensing problem with the transaction component?
Date Thu, 22 Oct 2009 09:33:18 GMT
Sorry about the false alarm.  I had the same problem Joe did....since I 
didn't see a dependency on a spec jar in the build, I falsely concluded 
it had to be picking up the JRE versions.  I was also sent down a wrong 
path by the change in naming with the spec jar.  All of the projects I 
had looked at were named "*-transaction", so when I checked to see if 
Geronimo even had a spec version of these classes, I didn't think to 
check for "*-jta" in the name.  It is good to be certain though that the 
correct classes are getting picked up :-)


Joe Bohn wrote:
> It seems to me that classes included match those in the geronimo jta 
> spec.  However, I'm not sure how these are getting included the 
> aries/transaction bundle.  The pom in aries/transaction only includes 
> a dependency on geronimo-transaction 2.1.2.  Perhaps the dependency on 
> geronimo-transactions results in a transitive dependency on the 
> geronimo jta spec that is including the javax.transaction classes.
> Joe
> Guillaume Nodet wrote:
>> I wasn't aware that there was any problem with redistributing those
>> classes.   You're right, we embed those classes from the geronimo spec
>> jar, so I guess the problem is the same as in geronimo.
>> On Wed, Oct 21, 2009 at 16:50, Rick McGuire <> wrote:
>>> I was looking at how the transaction component was building to 
>>> figure out
>>> how the javax.transaction classes.  If I understand what the build 
>>> is doing,
>>> then it appears that the bundle is getting built by directly 
>>> embedding the
>>> javax.transaction and javax.transaction.xa from the jvm used to 
>>> build the
>>> bundle.  I'm nervous that this would cause copyright issues since these
>>> classes are Sun copyrighted IP and I'm not sure that Apache is in 
>>> the clear
>>> with redistributing those classes that way.  We've got a similar 
>>> issue in
>>> Geronimo right now, and I was trying to figure out how this had been 
>>> solved
>>> here when I discovered this.  Am I interpreting what's going on with 
>>> the
>>> build correctly?
>>> Rick

View raw message