Hi Bartek, No prob, thanks a bunch in thinking of how to improve the Aries project.
Lin On Fri, May 21, 2010 at 6:21 PM, Bartosz Kowalewski <[email protected]> wrote: > 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 >>> >> >
