I'm surprised to discover that the subsystem-core dependency on testsupport-unit is not necessary but am not complaining. Everything compiles, all tests pass, and I am able to run/debug both itests and subsystem-core unit tests in Eclipse without issue. It solves the issue nicely and makes this discussion moot.
> From: Christian Schneider <[email protected]> > To: [email protected] > Date: 08/14/2015 04:38 PM > Subject: Re: Fw: [DISCUSS] Release Aries Testsupport Unit 2.0.0 > Sent by: Christian Schneider <[email protected]> > > I generally have no issue with a testsupport release. > In this case I think we can simply remove the dependency to testsupport > from subsystem core. I just committed a change. > > Btw. The problem below is caused by the old pax exam dependencies > testsupport 1.0.0 still has. > > Christian > > On 14.08.2015 20:53, John W Ross wrote: > > I've got a line on how to reproduce the issue now. > > > > (1) Point subsystem-itests/pom.xml to testsupport-unit version > > 2.0.0-SNAPSHOT. > > (2) Point subsystem-core/pom.xml to testsupport-unit version 1.0.0. > > (3) From the main subsystem directory, mvn eclipse:clean eclipse:eclipse. > > (4) Refresh all of the subsystem projects in the Eclipse workspace (that > > were imported as existing Maven projects). > > (5) From the main subsystem directory, mvn clean install -DskipTests=true. > > (6) From Eclipse Luna, attempt to Run As or Debug As one of the tests in > > subsystem-itests (this works when running a test in subsystem-core). > > > > You will receive the following. > > > > java.lang.NoSuchMethodError: > > org.ops4j.pax.exam.CoreOptions.url(Ljava/lang/String;)Lorg/ops4j/ > pax/exam/options/UrlProvisionOption; > > at > > org.ops4j.pax.exam.spi.PaxExamRuntime.defaultTestSystemOptions > (PaxExamRuntime.java:103) > > at > > org.ops4j.pax.exam.spi.PaxExamRuntime.createTestSystem > (PaxExamRuntime.java:91) > > at > > org.ops4j.pax.exam.spi.reactors.ReactorManager.createExamSystem > (ReactorManager.java:215) > > at > > org.ops4j.pax.exam.spi.reactors.ReactorManager.<init> > (ReactorManager.java:147) > > at > > org.ops4j.pax.exam.spi.reactors.ReactorManager.getInstance > (ReactorManager.java:163) > > at > > org.ops4j.pax.exam.junit.PaxExam.createDelegate(PaxExam.java:77) > > at org.ops4j.pax.exam.junit.PaxExam.<init>(PaxExam.java:73) > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > > Method) > > at > > sun.reflect.NativeConstructorAccessorImpl.newInstance > (NativeConstructorAccessorImpl.java:57) > > at > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance > (DelegatingConstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > > at > > org.junit.internal.builders.AnnotatedBuilder.buildRunner > (AnnotatedBuilder.java:31) > > at > > org.junit.internal.builders.AnnotatedBuilder.runnerForClass > (AnnotatedBuilder.java:24) > > at > > org.junit.runners.model.RunnerBuilder.safeRunnerForClass > (RunnerBuilder.java:57) > > at > > > org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass > (AllDefaultPossibilitiesBuilder.java:29) > > at > > org.junit.runners.model.RunnerBuilder.safeRunnerForClass > (RunnerBuilder.java:57) > > at > > org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24) > > at > > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init> > (JUnit4TestReference.java:33) > > at > > > org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init> > (JUnit4TestClassReference.java:25) > > at > > org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest > (JUnit4TestLoader.java:48) > > at > > org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests > (JUnit4TestLoader.java:38) > > at > > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests > (RemoteTestRunner.java:444) > > at > > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests > (RemoteTestRunner.java:675) > > at > > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run > (RemoteTestRunner.java:382) > > at > > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main > (RemoteTestRunner.java:192) > > > > I believe this is due to the pax-exam version conflicts between > > subsystem-core and subsystem-itests. The solution is to point > > subsystem-core to version 2.0.0-SNAPSHOT of testsupport-unit. > > > > Again, my preference would be to proceed with the subsystems release > > without doing a testsupport-unit release. I would point subsystem-core > > back to 2.0.0-SNAPSHOT in trunk after the release. I don't see what harm > > this issue will have on the subsystems release itself. > > > > > >> To: [email protected] > >> Date: 08/13/2015 02:46 PM > >> Subject: Re: [DISCUSS] Release Aries Testsupport Unit 2.0.0 > >> > >> My preference would be to not have to do a testsupport-unit release. > >> I can simply point subsystem-core back to 1.0.0 for the release and > >> change it to 2.0.0-SNAPSHOT for trunk. > >> > >>> From: Christian Schneider <[email protected]> > >>> To: [email protected] > >>> Date: 08/13/2015 02:12 PM > >>> Subject: Re: [DISCUSS] Release Aries Testsupport Unit 2.0.0 > >>> Sent by: Christian Schneider <[email protected]> > >>> > >>> I think subsystems can be released without a release of testsupport. > > As > >>> it is still released per bundle we do not release the itests. > >>> If we switch it to a per subproject release at some point then it will > >>> be different. > >>> > >>> For jpa and transaction I replaced testsupport completely. Most of its > >>> functionality can be done with either tinybundles or easmock / > > mockito. > >>> I planned to do the same for subsystems but it is a big chunk of work. > >>> See https://issues.apache.org/jira/browse/ARIES-1258 > >>> > >>> Christian > >>> > >>> > >>> On 13.08.2015 19:52, John W Ross wrote: > >>>> Sorry if this ends up being a duplicate due to the ongoing email > > issues, > >>>> but all other messages that I sent out since yesterday morning have > > now > >>>> come through in the right order except this one which was the very > > first. > >>>> So I'm assuming it got lost. > >>>> > >>>> I'm considering doing a 2.0.0 release of > > org.apache.aries.testsupport.unit > >>>> as a prerequisite to a new subsystems release but am not sure it's > > really > >>>> necessary. The subsystem-core module uses the last released > >>>> testsupport-unit version of 1.0.0. Attempting to debug > > subsystem-core code > >>>> while running an itest is not possible apparently due to the > > pax-exam > >>>> version conflicts. Pointing subsystem-core to the testsupport-unit > >>>> 2.0.0-SNAPSHOT version fixes the issue. Since we've never released > >>>> subsystem-itest, and there are no plans to do so this time, it'snot > > clear > >>>> to me if leaving subsystem-core pointing to the 1.0.0 version will > > hurt > >>>> anything. > >>>> > >>>> Thoughts? > >>>> > >>>> The last release of testsupport-unit is version 1.0.0: > >>>> http://search.maven.org/#search|gav|1|g%3A% > >>> 22org.apache.aries.testsupport%22%20AND%20a%3A% > >>> 22org.apache.aries.testsupport.unit%22 > >>>> The release tag is here: > >>>> http://svn.apache.org/viewvc/aries/tags/ > >>> org.apache.aries.testsupport.unit-1.0.0/ > >>>> > >>>> You can do "svn diff -r 1352338" from trunk to see the changes since > > the > >>>> last release. > >>>> > >>>> The only related JIRA I could find is > >>>> https://issues.apache.org/jira/browse/ARIES-1188. > >>>> > >>> > >>> -- > >>> Christian Schneider > >>> http://www.liquid-reality.de > >>> > >>> Open Source Architect > >>> http://www.talend.com > >>> > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
