Hi Bartek,
Looks good, however the tests fail for me. It comes down to a
dependency that PaxExam is looking for but can't find exactly in my
.m2 repo [1].
Looking in my .m2\repository\org\apache\aries\org.apache.aries.util I
see the following versions:
0.1-incubating
0.1-incubating-20100329
0.2-incubating-SNAPSHOT
Also locally building util didn't help...
Best regards,
David
[1]
-------------------------------------------------------------------------------
Test set: org.apache.aries.spifly.SPIBundleTrackerCustomizerTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.777
sec <<< FAILURE!
testProvidersWithandWithoutSpiHeader
[equinox/3.5.0](org.apache.aries.spifly.SPIBundleTrackerCustomizerTest)
Time elapsed: 0.75 sec <<< ERROR!
java.lang.RuntimeException: URL
[mvn:org.apache.aries/org.apache.aries.util/0.2-incubating-20100717.020505-16]
could not be resolved.
at
org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195)
at java.net.URL.openStream(URL.java:1010)
at
org.ops4j.pax.runner.platform.internal.StreamUtils.streamCopy(StreamUtils.java:112)
at
org.ops4j.pax.runner.platform.internal.PlatformImpl.download(PlatformImpl.java:631)
at
org.ops4j.pax.runner.platform.internal.PlatformImpl.downloadBundles(PlatformImpl.java:407)
at
org.ops4j.pax.runner.platform.internal.PlatformImpl.start(PlatformImpl.java:186)
at org.ops4j.pax.runner.Run.startPlatform(Run.java:671)
at org.ops4j.pax.runner.Run.start(Run.java:220)
at org.ops4j.pax.runner.Run.start(Run.java:176)
at
org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer.start(PaxRunnerTestContainer.java:264)
at
org.ops4j.pax.exam.junit.internal.JUnit4TestMethod.invoke(JUnit4TestMethod.java:142)
at
org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
at
org.ops4j.pax.exam.junit.internal.JUnit4MethodRoadie.runBeforesThenTestThenAfters(JUnit4MethodRoadie.java:60)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
at
org.ops4j.pax.exam.junit.JUnit4TestRunner.invokeTestMethod(JUnit4TestRunner.java:246)
at
org.ops4j.pax.exam.junit.JUnit4TestRunner.runMethods(JUnit4TestRunner.java:196)
at
org.ops4j.pax.exam.junit.JUnit4TestRunner$2.run(JUnit4TestRunner.java:186)
at
org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
at
org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
at
org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:182)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1005)
On 16 July 2010 18:04, Bartosz Kowalewski <[email protected]> wrote:
> Hi David,
>
> Thanks for applying the patch. Here goes another one... :)
> I've just created ARIES-363. This JIRA introduces an itests
> subproject. It also contains a Pax Exam test that checks if the
> existing SPI-Fly mechanisms work okay.
>
> Thanks,
> Bartek
>
> 2010/7/16 David Bosschaert <[email protected]>:
>> Hi Bartek,
>>
>> I have applied your changes in ARIES-353.
>>
>> Many thanks,
>>
>> David
>>
>> On 15 July 2010 16:59, David Bosschaert <[email protected]> wrote:
>>> Hi Bartosz,
>>>
>>> No I didn't have time to look at ARIES-353 yet. Will do so soon :)
>>>
>>> Cheers,
>>>
>>> David
>>>
>>> On 14 July 2010 09:17, Bartosz Kowalewski <[email protected]>
>>> wrote:
>>>> David,
>>>>
>>>> Have you had chance to take a look at the changes mentioned in ARIES-353?
>>>>
>>>> I can rename the main SPI-Fly project to something else than
>>>> spi-fly-core/org.apache.aries.spifly.core and send updated pom.xml
>>>> files if you like :).
>>>>
>>>> Thanks,
>>>> Bartek
>>>>
>>>> 2010/7/8 Bartosz Kowalewski <[email protected]>:
>>>>> Hi David,
>>>>>
>>>>> I've just created ARIES-353. It covers initial changes to be applied
>>>>> to to the SPI-Fly project structure. These changes transform SPI-Fly
>>>>> into a multi-module project. Once these changes are in SVN, I'll start
>>>>> contributing itests and other improvements.
>>>>>
>>>>> Thanks,
>>>>> Bartek
>>>>>
>>>>> 2010/6/29 David Bosschaert <[email protected]>:
>>>>>> Hi Bartek,
>>>>>>
>>>>>> On 25 June 2010 22:32, Bartosz Kowalewski <[email protected]>
>>>>>> wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> I managed to make Eclipse Aspects/Weaving work inside a Pax Exam test.
>>>>>>> I can contribute this simple project with integration tests (of course
>>>>>>> after applying some clean-up) if you find it useful. I think that
>>>>>>> SPI-Fly requires a change in project structure anyway - it needs a
>>>>>>> parent project and a second subproject - spifly-itests.
>>>>>>
>>>>>> That would be greatly appreciated!
>>>>>>
>>>>>>> Some more comments on the SPI-Fly + AOP topic:
>>>>>>> 1. My understanding is that there's no single uniform mechanism for
>>>>>>> supporting AspectJ load-time weaving that would work in all OSGi
>>>>>>> containers. Due to the specifics of the OSGi world, container-specific
>>>>>>> mechanism are required. Am I right? For Equinox it's Equinox
>>>>>>> Aspects/Weaving and there's no such mechanism for Felix. This seems to
>>>>>>> be a really important disadvantage of using LTW in SPI-Fly.
>>>>>>
>>>>>> Yes - there is currently no general mechanism to support load-time
>>>>>> weaving in OSGi but this is something being worked on in the OSGi
>>>>>> Alliance so I expect that it will be possible in a standardized way in
>>>>>> the future.
>>>>>>
>>>>>>> 2. The problem with adding aspects to bundles is still unresolved. I'm
>>>>>>> not sure if there's a clean solution for adding aspects to consumer
>>>>>>> bundles (or bundles that provide the API). Of course some ugly
>>>>>>> solutions can be applied (like my original headache causing fragment
>>>>>>> based one), but these are more intrusive that we might wish.
>>>>>>
>>>>>> Yes, this is still an open question. Maybe something for the AspectJ
>>>>>> mailing list. I will post there.
>>>>>>
>>>>>>> 3. I started implementing support for SPI-Consumer and SPI-Provider
>>>>>>> headers that contain some data helpful whne running the aspect, i.e.
>>>>>>> api name and provider name/version for the Provider header, and some
>>>>>>> mechanism to define consumer constraints/hints in the SPI-Consumer
>>>>>>> header that would help the aspect that will tweak the thread context
>>>>>>> classloader to make decisions about providers. These mechanisms are
>>>>>>> similar to the ones that you described in one of your e-mails.
>>>>>>> However, I feel that we should first solve #1 and #2 above and only
>>>>>>> then it makes sense to continue with the implementation.
>>>>>>
>>>>>> cool stuff - looking forward to your contributions :)
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> David
>>>>>>
>>>>>
>>>>
>>>
>>
>
