Hi,
I was working through a problem where my local build of a project, using
Maven 3.2.2 and JDK 1.8.0_71 (Win64) was continually hitting a
dependency problem. Whilst our continuous integration server was not.
The continuous integration server is running JDK 1.7.0_80.
The problem being encountered was:
[ERROR] C:\Users\shaddy\workarea\...\FooBean.java:[72,45] error: cannot
access TransactionLocalDelegate
Before I dive head first into my investigation into the problem, I
am fairly certain the problem is because there has been a change to how
javac in Java 8 resolves interface dependencies; in contrast to previous
versions.
My understanding is pre Java 8, you did not need to include in the
classpath to javac, paths to the interfaces that are dependencies of
precompiled classes.
According to https://bugs.openjdk.java.net/browse/JDK-8055048, this has
changed (my understanding, due to a language spec change) with Java 8.
I know this seems late in the game, but considering how I encountered
the problem, how it seems so obscure and random, I thought it important
to have something on record about how Java 8's changed behaviour may
have been potentially crippling user experience of Maven. Through no
fault of Maven, or artifact creators themselves. But through a change in
the goal-posts.
To illustrate my point, if you can follow this. The code in question is:
import com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate;
import com.arjuna.ats.jta.transaction.Transaction;
...
TransactionManagerDelegate tx = (TransactionManagerDelegate)
TransactionManager.transactionManager();
try {
Transaction transaction = (Transaction)
tx.getTransaction();
Tracing this to see where there was a reference to
TransactionLocalDelegate, I found that it was in a base class
com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate extends:
public class com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate
extends com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate
implements javax.naming.spi.ObjectFactory {
public com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate();
public int getTransactionTimeout() throws
javax.transaction.SystemException;
Now this base class implements interface
org.jboss.tm.TransactionLocalDelegate:
public abstract class
com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate implements
javax.transaction.TransactionManager,org.jboss.tm.TransactionLocalDelegate,org.jboss.tm.TransactionTimeoutConfiguration
With Java 1.7 and below, javac would not chase down the definition of
this interface (confirmed with javac -verbose). But with Java 1.8 it
does.
Now the artifact is:
<dependency>
<groupId>org.jboss.jbossts.jts</groupId>
<artifactId>jbossjts-integration</artifactId>
</dependency>
and the pom.xml for this artifact has this section:
<dependency>
<groupId>org.jboss</groupId>
<artifactId>jboss-transaction-spi</artifactId>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging-spi</artifactId>
</exclusion>
</exclusions>
</dependency>
Artifact jboss-transaction-spi would have provided the definition to
interface org.jboss.tm.TransactionLocalDelegate. But innocently (and
perhaps for greatest efficiency), the pom.xml definition has it scoped
provided.
This is now really really problematic. Maven will not provide it, but
Java 1.8 now requires that it does.
Without any sample of data (or even being in a position to take such)
I have to speculate that many pom.xml authors have taken the same
measures. And following on from that, users building projects that
depend on similarly defined artifacts, are unable to build with Java 8
javac. And potentially putting it down to Maven/artifact problems.
I'm not sure what the solution is. Is it as significant a change in
behaviour as I think it, for pom.xml authors to update their definitions
to no longer specify that interfaces are "provided"? It's going to make
Maven seem slightly slower and bloated. Through no fault of its own.
One last note. Running Java 8 javac with something like -target 1.6
-source 1.6 won't change the dependency resolution behaviour.
--
Regards,
Shaddy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
