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 >
