i agree with curtis
>javac -versionjavac 1.8.0_40
<!-- unless otherwise stated assume scope is 'compile' -->
<project><modelVersion>4.0.0</modelVersion><groupId>test</groupId><artifactId>Test</artifactId><version>1.0</version><dependencies><!--
this is the first and only dependency I had in pom.xml --> <dependency>
<groupId>org.jboss.jbossts</groupId>
<artifactId>jbossjts-integration</artifactId> <version>4.16.6</version>
</dependency> <!-- then I got this error which forced me to add
jbossjts --> <!-- [ERROR] /ShaddahTest/src/main/java/test/Test.java:[3,38]
package com.arjuna.ats.jta.transaction does not exist --> <dependency>
<groupId>org.jboss.jbossts</groupId> <artifactId>jbossjts</artifactId>
<version>4.16.6.Final</version> </dependency> <!-- then I got
this error which forced me to add jta --> <!-- [ERROR]
/ShaddahTest/src/main/java/test/Test.java:[23,69] cannot find symbol[ERROR]
symbol: class SystemException [ERROR] location: package javax.transaction -->
<dependency> <groupId>javax.transaction</groupId>
<artifactId>jta</artifactId> <version>1.1</version> </dependency>
<!-- and finally i got missing interface TransactionLocalDelegate which forced
me to add jboss-transaction-spi --> <!--[ERROR]
/ShaddahTest/src/main/java/test/Test.java:[10,67] cannot access
org.jboss.tm.TransactionLocalDelegate[ERROR] class file for
org.jboss.tm.TransactionLocalDelegate not found --> <dependency>
<groupId>org.jboss.integration</groupId>
<artifactId>jboss-transaction-spi</artifactId> <version>6.0.0</version>
</dependency></dependencies></project>
when scope=compile none of the Base Classes or Interfaces are 'automatically
resolved' and I am forced to add the dependencies
Can you please illustrate a 'automatic resolution behaviour for interface'
with a non jboss example?
Thanks,
Martin
______________________________________________
> From: ctrue...@wisc.edu
> Date: Thu, 4 Feb 2016 08:22:31 -0600
> Subject: Re: Way Java 8 resolves interface dependencies seems to play havoc
> To: users@maven.apache.org
>
> 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
> >
> >
