Hi Shaddy, > 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"?
Personally, I have never heard of interface/API JARs being scoped as provided in this manner, until you pointed out the jboss example. I would be surprised if this is a common practice, especially since it seems like a hack: in this case, the interfaces are _not_ actually "provided" at runtime, right? They just end up not actually being needed with Java 7 or earlier runtime? Anyway, it seems very dangerous to me to rely on class loading subtleties like that when scoping Maven artifacts -- I would always put these things at compile or runtime scope in my own projects, to maximize compatibility. The fact is that those interfaces _are_ dependencies. I would call this a "bug" in the JBoss BOM. Regards, Curtis -- Curtis Rueden LOCI software architect - http://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden Did you know ImageJ has a forum? http://forum.imagej.net/ On Wed, Feb 3, 2016 at 11:07 PM, Shaddy Baddah < beryllium-b...@shaddybaddah.name> wrote: > 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 > >
