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 :-)
Rick
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 <[email protected]> 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
