Hi Lin, Thanks a lot for this pointer. I previously only took a look at Blueprint and the integration tests that are defined there. That is why I missed this nice fixture which is used in other itests projects. My fault :).
Best regards, Bartek 2010/5/21 Lin Sun <[email protected]>: > Hi Bartek, > > Thanks. I think we have something similar in our unittest already, it > is called ArchiveFixture which you can use to construct your archive > you want. > > For example, see the BasicAppManagerTest in > org.apache.aries.application.runtime.itests. > > Lin > > On Thu, May 20, 2010 at 8:00 PM, Bartosz Kowalewski > <[email protected]> wrote: >> Hi All, >> >> I'm rather new to Apache Aries (at least I haven't played with the >> source code a lot). However, today I had an opportunity to dig in, >> because I needed ARIES-9 to be fixed. As a part of the fix that I >> provided I also created a new Pax Exam test for blueprint-core. I >> learned that all tests that are available in blueprint-itests project >> use a shared test bundle (blueprint-sample) with a single file that >> contains Blueprint definitions. This means that with every test run >> all definitions from this sample Blueprint bundle are processed and we >> get lots of components. Each test case uses only a subset of these >> components. I'm wondering if you ever thought of refactoring these >> tests, so that each test class would use its own sample blueprint >> bundle? I know that using tens of test/sample Maven projects would not >> be acceptable :). I was rather thinking of using swissbox tinybundles >> and generating the sample bundles with Blueprint definitions at >> runtime. Here's an example of similar code that I created for Spring >> powered bundles some time ago: >> >> protected Option generateBundle(String symbolicName, >> Class<?>[] classesToAdd, String[] importedPackages, >> String[] exportedPackages, InputStream >> springContextContents) >> { >> // Note: we do not check if parameters are not null; NPEs >> will be thrown >> >> TinyBundle generatedBundle = newBundle(); >> if (classesToAdd != null) >> { >> for (Class<?> clazz : classesToAdd) >> { >> generatedBundle.add(clazz); >> } >> } >> >> generatedBundle.add("META-INF/spring/generated-" + >> symbolicName >> + ".xml", springContextContents); >> generatedBundle.set(Constants.BUNDLE_NAME, symbolicName); >> generatedBundle.set(Constants.BUNDLE_SYMBOLICNAME, >> symbolicName); >> >> //generatedBundle.set(Constants.DYNAMICIMPORT_PACKAGE, "*"); >> >> StringBuilder sb = new StringBuilder(); >> if (importedPackages.length > 0) >> { >> sb.append(importedPackages[0]); >> } >> for (int i = 1; i < importedPackages.length; i++) >> { >> sb.append("," + importedPackages[i]); >> } >> generatedBundle.set(Constants.IMPORT_PACKAGE, sb.toString()); >> >> sb.setLength(0); >> if (exportedPackages.length > 0) >> { >> sb.append(exportedPackages[0]); >> } >> for (int i = 1; i < exportedPackages.length; i++) >> { >> sb.append("," + exportedPackages[i]); >> } >> generatedBundle.set(Constants.EXPORT_PACKAGE, sb.toString()); >> >> // replace Spring specific names with constants? >> generatedBundle.set("Spring-Context", >> >> "*;publish-context:=true;create-asynchronously:=false"); >> >> return provision(generatedBundle.build(withBnd())); >> } >> >> A similar approach can be used to generate Blueprint bundles. Such a >> generated bundle can then be passed to Pax Exam. >> >> There's one significant drawback the approach taht I'm proposing. You >> also need to customize the Pax Exam test probe (again using Tiny >> Bundles :) ) and remove the resources and classes that you want only >> to be available in the generated sample Blueprint (or Spring powered) >> bundle. By default these resources would also be used by Pax Exam when >> creating the test probe. >> >> Thanks, >> Bartek >> >
