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
