Thanks for the info. I had seen "mvnlive" mentioned, but I was unclear
on how it is to be used. I think you just cleared that up for me.
Toni Menzel wrote:
> one more thing:
> the need for "complete" bundles for paxdrone to work with is relative:
> Thanks to url handlers there are already efforts that you can add a project
> folder as a dependency like so:
> addBundle("mvnlive:org.ops4j.sample/mysample-bundle");
> the only difference to the normal mvn handler is that this one is for lazy
> people:
> Trying to locate the project around your current base dir, building it using
> "mvn clean install" and hand out the result to the callee. This way you still
> need the project/test separation but can develope logic and run tests in
> parallel.
> Currently you just need a fast machine because of permanent builds prior
> running the test.
> This approach offers IDE independent integrated OSGi support. (how cool is
> that)
> Its all in the current branch of pax-url (in an outcommented sub project
> currently).
> Keep in mind i just ran this on a mac - so some file/directory checks may
> need some tuning before it runs on windows.
>
>
>
> -------- Original-Nachricht --------
>
>> Datum: Mon, 28 Jul 2008 15:58:22 +0200
>> Von: "Toni Menzel" <[EMAIL PROTECTED]>
>> An: General OPS4J <[email protected]>
>> Betreff: Re: Pax Drone
>>
>
>
>> ok,
>>
>> i already checked you laboratory.
>> well, the problem is by design: you just load an empty osgi framework.
>> Thus, you service (ExampleService) will not be found.
>> Short answer to "your manifest": No, it does not recognize your manifest.
>>
>> The faq ansers this like so:
>> By design the drone will be built using the wrap approach solely on
>> classes found inside the current project.
>> Every dependency will be declared as an optional import-package.
>> This constrains the usage of the drone. But by intention.
>> The drone contains just the recipe host and its direct dependencies (like
>> helper classes just for testing purpose).
>> Everything you want to test should be build by someone who really knows
>> about it: maven-bundle-plugin or similar.
>> This way you orchestrate the final artifacts and no hybrid bundles that
>> blur the test outcome.
>> ---
>>
>> PaxDrone just takes complete bundles and provides a method to quickly set
>> them and write some test code (called recipes) against this.
>>
>> So, its a decision that might lead to unexpected results (like your case)
>> but should be clear once you know about this.
>> There are some things that might help here in future:
>> - support paxdrone somehow in a paxconstruct setup directly in a way that
>> those "integration test projects" you need for paxdrone are automatically
>> pre-build (stubs) if wanted.
>>
>> Will keep you in touch.
>>
>> Toni
>>
>> -------- Original-Nachricht --------
>>
>>> Datum: Mon, 28 Jul 2008 08:31:41 -0500
>>> Von: Craig Walls <[EMAIL PROTECTED]>
>>> An: General OPS4J <[email protected]>
>>> Betreff: Re: Pax Drone
>>>
>>> Okay...here's what I did:
>>>
>>> 1. Used pax-create-project to create a project
>>> 2. Used pax-create-bundle to create the bundle subproject
>>> 3. Manually added Pax Drone dependencies to the top-level project's
>>> pom.xml
>>> 4. Added a Drone test case for the ExampleService
>>>
>>> When I run "mvn test", the test fails for the same reason it fails in my
>>> much more interesting project...that is, because it can't seem to find
>>> the service. The good news (sorta) is that the test runs in Eclipse...it
>>> still fails for the same reason that it fails in Maven, but it runs fine
>>> otherwise.
>>>
>>> The two places where I may've screwed up (and I am looking for feedback)
>>> are:
>>>
>>> * Did I correctly add Pax Drone to the project? I did it manually
>>> (instead of using something like pax-import-bundle) because I
>>> didn't want Pax Drone to be provisioned at runtime. Is there a
>>> better way than to add it manually in the POM?
>>> * Is my test case written correctly? Am I trying to get the service
>>> correctly? (I looked for examples in SVN, but all of the Drone
>>> examples that I found in SVN stopped short of retrieving a service
>>> and testing it. If I'm missing something, please point me in the
>>> right direction.)
>>>
>>> I checked all of what I did into SVN at
>>>
>>>
>> https://scm.ops4j.org/repos/ops4j/laboratory/users/habuma/pax-construct-drone.
>>
>>> BTW, side question: How does Pax Drone know to create a bundle for my
>>> project that publishes the service? Does it find a MANIFEST.MF somewhere
>>> and use that? Does it find an activator class and assume that it should
>>> be the activator? How does that magic work?
>>>
>>>
>>>
>>>
>>> Craig Walls wrote:
>>>
>>>> Absolutely. I'll try to cook one up.
>>>>
>>>> As I mentioned, I'm not 100% convinced that it's a Pax Drone/Pax
>>>> Construct mismatch--that was just the pattern that I had observed.
>>>>
>>>> I'll need to cook up an example where it fails. I am not prepared to
>>>> share the code that I discovered this in, but I'll try to come up with
>>>> something similar.
>>>>
>>>>
>>>> Stuart McCulloch wrote:
>>>>
>>>>
>>>>> 2008/7/28 Toni Menzel <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
>>>>>
>>>>> Will definitely have a look at that asap. @craig: can you provide
>>>>> a ready to go Sample of the Problem in your laboratory?
>>>>> Toni
>>>>>
>>>>>
>>>>> yep, I think we'll need an example - I tried to create one using
>>>>> pax-construct 1.3 and pax-drone 1.3-SNAPSHOT, but wasn't
>>>>> able to recreate the error
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 28.07.2008, at 10:38, "Stuart McCulloch"
>>>>> <[EMAIL PROTECTED]
>>>>>
>> <mailto:[EMAIL PROTECTED]>>
>>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 2008/7/28 Toni Menzel <[EMAIL PROTECTED]
>>>>>>
>>> <mailto:[EMAIL PROTECTED]>>
>>>
>>>>>> hex craig,
>>>>>> thanks for digging into the problems yourself and sorry
>>>>>>
>> about
>>
>>>>>> me not
>>>>>> jumping in this weekend.
>>>>>> first about the Manifest itself: (though it doesn't look to
>>>>>> be our
>>>>>> Problem today) its by design to ensure conistency within the
>>>>>> dronebundle as well as (More important) to really force the
>>>>>> testcode
>>>>>> not containing real code. Its different from unittesting.
>>>>>>
>> The
>>
>>>>>> drone is
>>>>>> just an extra module (bundle) solely to orchestrate the
>>>>>>
>> other
>>
>>>>>> bundles.
>>>>>> The wiki contains a faq entry about this.
>>>>>> About paxconstruct: will try to catch up with stuart whats
>>>>>> wrong here.
>>>>>>
>>>>>>
>>>>>> interesting... pax-construct generated projects are still normal
>>>>>> Maven projects that someone could create by hand, given time
>>>>>> - so it's odd they cause problems in pax-drone
>>>>>>
>>>>>> initial thought is possibly a dependency/plugin conflict... but
>>>>>>
>>> how?
>>>
>>>>>> Stay there! ;-)
>>>>>> Cheers,
>>>>>> Toni
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 28.07.2008, at 06:13, Craig Walls <[EMAIL PROTECTED]
>>>>>> <mailto:[EMAIL PROTECTED]>> wrote:
>>>>>>
>>>>>> >
>>>>>> > Following up to my earlier e-mail...
>>>>>> >
>>>>>> > I now believe that my previous supposition was false. At
>>>>>> that point I
>>>>>> > was thinking that my service wasn't being published
>>>>>>
>> because
>>
>>>>>> Pax Drone
>>>>>> > didn't know about my activator. But now I have a much
>>>>>> simpler bundle
>>>>>> > project and have no trouble writing Pax Drone tests in it
>>>>>> and against
>>>>>> > the service that its activator publishes. So that blows my
>>>>>> original
>>>>>> > theory.
>>>>>> >
>>>>>> > So, I've tried Pax Drone in a few more bundle projects and
>>>>>> have had a
>>>>>> > mixed bag of results. So far, the pattern seems to be that
>>>>>> it works
>>>>>> > fine
>>>>>> > in projects that I create by hand, but doesn't work well
>>>>>>
>> in
>>
>>>>>> projects
>>>>>> > that I created with Pax Construct. I suspect that I'll
>>>>>> prove that
>>>>>> > wrong,
>>>>>> > but that's the current pattern.
>>>>>> >
>>>>>> > For what it's worth, in Pax Construct projects, I am
>>>>>>
>> seeing
>>
>>> two
>>>
>>>>>> > problems
>>>>>> > (but they might be related). First, when I try to run the
>>>>>> test from
>>>>>> > Eclipse, I get the following exception/stack-trace:
>>>>>> >
>>>>>> > java.lang.SecurityException: class
>>>>>> > "org.apache.commons.logging.LogLevel"'s signer information
>>>>>> does not
>>>>>> > match signer information of other classes in the same
>>>>>>
>>> package
>>>
>>>>>> > at
>>>>>>
>> java.lang.ClassLoader.checkCerts(ClassLoader.java:775)
>>
>>>>>> > at
>>>>>> java.lang.ClassLoader.preDefineClass(ClassLoader.java:487)
>>>>>> > at
>>>>>>
>>> java.lang.ClassLoader.defineClass(ClassLoader.java:614)
>>>
>>>>>> > at
>>>>>> >
>>>>>>
>>>>>>
>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:
>>>
>>>>>> > 124)
>>>>>> > at
>>>>>> java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
>>>>>> > at
>>>>>> java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>>>>>> > at
>>>>>>
>> java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>>
>>>>>> > at java.security.AccessController.doPrivileged(Native
>>>>>> Method)
>>>>>> > at
>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>>>>>> > at
>>>>>>
>> java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>>
>>>>>> > at
>>>>>>
>>>>>>
>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
>>
>>>>>> > at
>>>>>>
>> java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>>
>>>>>> > at
>>>>>>
>>>>>>
>> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>>
>>>>>> > at org.ops4j.pax.runner.Run.<init>(Run.java:86)
>>>>>> > at
>>>>>> > org.
>>>>>> > ops4j.
>>>>>> > pax.
>>>>>> > drone.
>>>>>> > connector.
>>>>>> > paxrunner.
>>>>>> >
>>>>>>
>>>>>>
>>> intern.PaxRunnerInstanceImpl.startup(PaxRunnerInstanceImpl.java:75)
>>>
>>>>>> > at
>>>>>> > org.
>>>>>> > ops4j.
>>>>>> > pax.
>>>>>> > drone.
>>>>>> > connector.
>>>>>> >
>>>>>>
>>>>>>
>>> paxrunner.intern.PaxRunnerConnector.execute(PaxRunnerConnector.java:
>>>
>>>>>> > 63)
>>>>>> > at
>>>>>> org.ops4j.pax.drone.spi.DroneRunner.run(DroneRunner.java:76)
>>>>>> > at
>>>>>> > org.
>>>>>> >
>>>>>>
>>>>>>
>>> ops4j.pax.drone.spi.junit.DroneTestCase.runBare(DroneTestCase.java:60)
>>>
>>>>>> > at
>>>>>>
>>> junit.framework.TestResult$1.protect(TestResult.java:110)
>>>
>>>>>> > at
>>>>>> junit.framework.TestResult.runProtected(TestResult.java:128)
>>>>>> > at junit.framework.TestResult.run(TestResult.java:113)
>>>>>> > at junit.framework.TestCase.run(TestCase.java:124)
>>>>>> > at
>>>>>>
>> junit.framework.TestSuite.runTest(TestSuite.java:232)
>>
>>>>>> > at junit.framework.TestSuite.run(TestSuite.java:227)
>>>>>> > at
>>>>>> > org.
>>>>>> > junit.
>>>>>> >
>>>>>>
>>>>>>
>>> internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
>>>
>>>>>> > at
>>>>>> > org.
>>>>>> > eclipse.
>>>>>> > jdt.
>>>>>> > internal.
>>>>>> >
>>>>>>
>>>>>>
>>> junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
>>>
>>>>>> > at
>>>>>> > org.
>>>>>> > eclipse.
>>>>>> >
>>>>>>
>>>>>>
>>> jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>>
>>>>>> > at
>>>>>> > org.
>>>>>> > eclipse.
>>>>>> > jdt.
>>>>>> > internal.
>>>>>> >
>>>>>>
>>>>>>
>>> junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>>>
>>>>>> > at
>>>>>> > org.
>>>>>> > eclipse.
>>>>>> > jdt.
>>>>>> > internal.
>>>>>> >
>>>>>>
>>>>>>
>>> junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>>>
>>>>>> > at
>>>>>> > org.
>>>>>> > eclipse.
>>>>>> >
>>>>>>
>>>>>>
>>> jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:
>>>
>>>>>> > 386)
>>>>>> > at
>>>>>> > org.
>>>>>> > eclipse.
>>>>>> > jdt.
>>>>>> >
>>>>>>
>>>>>>
>>> internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
>>>
>>>>>> >
>>>>>> > When I run the tests at build time using Maven, the test
>>>>>> fails with a
>>>>>> > NPE when it tries to use the null ServiceReference
>>>>>>
>> received
>>
>>>>>> from the
>>>>>> > BundleContext.
>>>>>> >
>>>>>> > For non-Pax Construct projects, it works fine in both
>>>>>> Eclipse and
>>>>>> > Maven.
>>>>>> >
>>>>>> > Again, any clues would be greatly appreciated. In the
>>>>>> meantime, I'll
>>>>>> > be
>>>>>> > digging around in the Pax Drone source code.
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > Craig Walls wrote:
>>>>>> >> Imagine that I have created a bundle that publishes a
>>>>>> HelloService to
>>>>>> >> the OSGi service registry. Now I want to test that
>>>>>>
>> service,
>>
>>>>>> >> integrated
>>>>>> >> with all of the stuff (in other bundles) that it works
>>>>>> with. So I
>>>>>> >> write
>>>>>> >> a Pax Drone test, adding all of the required bundles.
>>>>>> >>
>>>>>> >> I run the test...it looks a little something like this:
>>>>>> >>
>>>>>> >> public class HelloServiceBundleTest extends DroneTestCase
>>>>>>
>> {
>>
>>>>>> >>
>>>>>> >> @Override
>>>>>> >> protected ConnectorConfiguration configure() {
>>>>>> >> return
>>>>>> ConnectorConfigurationFactory.create(this).setPlatform(
>>>>>> >> Platforms.EQUINOX).addBundle("...")
>>>>>> >> .addBundle("..."); // bundle names left
>>>>>> out for
>>>>>> >> brevity's sake
>>>>>> >> }
>>>>>> >>
>>>>>> >> public void testBundleContextExists() {
>>>>>> >> assertNotNull(droneContext.getBundleContext());
>>>>>> >> }
>>>>>> >>
>>>>>> >> public void testHelloServiceShouldExist() {
>>>>>> >> BundleContext bundleContext =
>>>>>> droneContext.getBundleContext();
>>>>>> >> ServiceReference serviceRef = bundleContext
>>>>>> >>
>>>>>> >>
>>>>>> .getServiceReference("com.habuma.hello.HelloService");
>>>>>> >> HelloService helloService = (HelloService)
>>>>>>
>>> bundleContext
>>>
>>>>>> >> .getService(serviceRef);
>>>>>> >> assertNotNull(helloService);
>>>>>> >> }
>>>>>> >> }
>>>>>> >>
>>>>>> >> But it doesn't work. The testBundleContextExists() test
>>>>>> works. But
>>>>>> >> testHelloServiceShouldExist() fails. It tries to find the
>>>>>> >> HelloService,
>>>>>> >> but it can't be found. I'm pretty sure that it's
>>>>>>
>> because...
>>
>>>>>> >>
>>>>>> >> * I'm not adding the hello service bundle to the
>>>>>> >> ConnectorConfiguration...and...
>>>>>> >> * I'm letting the test case automatically generate the
>>>>>> bundle for
>>>>>> >> the hello service...and...
>>>>>> >> * The generated bundle doesn't know about the
>>>>>> >> activator...therefore...
>>>>>> >> * The service isn't be published.
>>>>>> >>
>>>>>> >> My question: How can I test the index service (in an
>>>>>> integration test
>>>>>> >> along with all of the stuff that it depends on) using Pax
>>>>>> Drone?
>>>>>> >> Like I
>>>>>> >> said, it seems that the crux of the problem is that the
>>>>>> service is
>>>>>> >> never
>>>>>> >> published because the activator is never executed because
>>>>>> I don't
>>>>>> >> know
>>>>>> >> how to tell Pax Drone about the activator.
>>>>>> >>
>>>>>> >> Any clues? The only thing that I can think of is to test
>>>>>> the hello
>>>>>> >> service in a separate project, including the hello
>>>>>>
>> service
>>
>>>>>> bundle
>>>>>> >> in the
>>>>>> >> set of bundles added to the ConnectorConfiguration and
>>>>>> ensure that
>>>>>> >> the
>>>>>> >> hello service bundle has been created before I run the
>>>>>> integration
>>>>>> >> test.
>>>>>> >> But I'd really prefer to test the hello service bundle
>>>>>> within the
>>>>>> >> hello
>>>>>> >> service bundle project.
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> _______________________________________________
>>>>>> >> general mailing list
>>>>>> >> [email protected] <mailto:[email protected]>
>>>>>> >> http://lists.ops4j.org/mailman/listinfo/general
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > general mailing list
>>>>>> > [email protected] <mailto:[email protected]>
>>>>>> > http://lists.ops4j.org/mailman/listinfo/general
>>>>>>
>>>>>> _______________________________________________
>>>>>> general mailing list
>>>>>> [email protected] <mailto:[email protected]>
>>>>>> http://lists.ops4j.org/mailman/listinfo/general
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers, Stuart
>>>>>> _______________________________________________
>>>>>> general mailing list
>>>>>> [email protected] <mailto:[email protected]>
>>>>>> http://lists.ops4j.org/mailman/listinfo/general
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> general mailing list
>>>>> [email protected] <mailto:[email protected]>
>>>>> http://lists.ops4j.org/mailman/listinfo/general
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers, Stuart
>>>>>
>>>>>
>>> ------------------------------------------------------------------------
>>>
>>>>> _______________________________________________
>>>>> general mailing list
>>>>> [email protected]
>>>>> http://lists.ops4j.org/mailman/listinfo/general
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> general mailing list
>>>> [email protected]
>>>> http://lists.ops4j.org/mailman/listinfo/general
>>>>
>>>>
>>> _______________________________________________
>>> general mailing list
>>> [email protected]
>>> http://lists.ops4j.org/mailman/listinfo/general
>>>
>> _______________________________________________
>> general mailing list
>> [email protected]
>> http://lists.ops4j.org/mailman/listinfo/general
>>
>
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/general
>
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
