Hello, Yes you have to provide interfaces for Java 8 compiler which you did not need before. If your dependencies do not provide these artifacts you get the compiler error. You then basically have the option to include it in the upstream dependency or in your own project as a compile time deoendency (and changes are high that you have depoyed that artifact at runtime anyway).
I dont think the typical maven plugins can make anything differently (and not even the bundle plugin I guess needs to do something else). Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Curtis Rueden <ctrue...@wisc.edu> To: Maven Users List <users@maven.apache.org> Sent: Do., 04 Feb. 2016 15:23 Subject: Re: Way Java 8 resolves interface dependencies seems to play havoc 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
