There is a tag <repository></repository> that you can use to point another location of features xml file in the features file.
Never used Charles Moulliard Senior Enterprise Architect Apache Camel Committer ***************************** blog : http://cmoulliard.blogspot.com twitter : http://twitter.com/cmoulliard On Tue, Oct 6, 2009 at 3:17 PM, Jean-Baptiste Onofré <[email protected]> wrote: > Hi, > > My problem is due to the fact that spring-dm feature (referenced in the NMR > document feature) is not found. > > spring and spring-dm features are provided by karaf. > > So, first, I tried to use karaf and nmr feature in the exec unit test: > > return options( > profile("log").version("1.4"), > org.ops4j.pax.exam.CoreOptions.systemProperty("org.ops4j.pax.logging.DefaultServiceLog.level").value("DEBUG"), > scanFeatures("mvn:org.apache.felix.karaf/apache-felix-karaf/1.1.0-SNAPSHOT/xml/features","spring-dm/1.2.0"), > scanFeatures("mvn:org.apache.servicemix.nmr/apache-servicemix-nmr/1.1.0-SNAPSHOT/xml/features","jbi/1.1.0-SNAPSHOT"), > felix()); > > Unfortunately, it doesn't work (pax-runner is already looking for spring-dm > version 0.0.0). > > The only way that I found for now is to merge karaf and nmr features into a > single file: > return options( > profile("log").version("1.4"), > org.ops4j.pax.exam.CoreOptions.systemProperty("org.ops4j.pax.logging.DefaultServiceLog.level").value("DEBUG"), > scanFeatures("file:apache-karaf-nmr-1.1.0-SNAPSHOT-features.xml","jbi/1.1.0-SNAPSHOT"), > felix()); > > Now spring-dm feature is found and pax-runner start felix correctly. > > Any idea about this issue ? > > Regards > JB > > Jean-Baptiste Onofré wrote: >> >> Hi all, >> >> based on this thread discuss, I have: >> - add required dependencies in the dependencyManagement of the >> components-pom: >> >> http://svn.apache.org/repos/asf/servicemix/components/components-pom/trunk/pom.xml >> - begin to use pax-exam in the exec component: >> >> http://svn.apache.org/repos/asf/servicemix/components/engines/servicemix-exec/trunk/src/test/java/org/apache/servicemix/exec/itest/smx4/ >> >> Unfortunately, I have an issue with the scanFeatures() method of pax-exam. >> >> I would like to deploy JBI feature into a felix instance using pax-exam. >> As mentioned by Guillaume, I do: >> >> Option[] options = options( >> profile("log").version("1.4"), >> org.ops4j.pax.exam.CoreOptions.systemProperty("org.ops4j.pax.logging.DefaultServiceLog.level").value("DEBUG"), >> >> scanFeatures(mavenBundle().groupId("org.apache.servicemix.nmr").artifactId("apache-servicemix-nmr").version("1.1.0-SNAPSHOT").type("xml/features"), >> "jbi"), felix()); >> >> As jbi feature is versionned, I get this exception in the unit test: >> java.lang.RuntimeException: >> >> org.ops4j.pax.runner.provision.ScannerException: Cannot find a feature >> named 'jbi' with version '0.0.0' >> >> I'm going to check in the pax-exam source code to see how I can manage the >> feature versionning. >> >> I will keep you posted. >> >> Regards >> JB >> >> Chris Custine wrote: >>> >>> Jean-Baptiste suggested in another thread that we consider moving to SMX4 >>> for component testing, and this has also crossed my mind recently so we >>> thought it bet to start a specific thread to discuss this. >>> >>> I think it will certainly be a requirement to automate testing of >>> components >>> inside SMX4, but there are also some more immediate motivations for doing >>> this in order to test components with updated dependencies used in SMX4. >>> After using Pax Exam a bit lately with the SMX4 itests, I am wondering if >>> that would be a suitable mechanism to test components with SMX4? I think >>> this would certainly be a more accurate test of integration with the >>> runtime >>> than the current tests, although there will possibly be a performance >>> penalty when running tests due to the more heavyweight nature. >>> Alternatively, we could bootstrap some smaller chunk of SMX4 in order to >>> perform more isolated tests without starting a full container. >>> >>> I am currently leaning towards using Pax Exam because it would provide a >>> very accurate representation of the component running inside the >>> container. >>> This would include deployment and startup lifecycle, interaction with >>> runtime dependencies, etc. which is slightly more accurate than the >>> current >>> tests. >>> >>> One final question is whether SMX4 provides an adequate test environment >>> that is reciprocal with SMX3. We have been relying on SMX3 for testing >>> components that are also deployed in SMX4, so is this also good enough >>> the >>> other way around or do we need to keep both? One of the downsides of the >>> current tests is that many of the components have their own base tests >>> that >>> create the appropriate environment in which to test, and I think this has >>> made the tests harder to maintain. I think one of the goals for this >>> would >>> be to make test authoring much easier. >>> >>> So what are everyone's thoughts on this? >>> >>> Thanks, >>> Chris >>> -- >>> Chris Custine >>> FUSESource :: http://fusesource.com >>> My Blog :: http://blog.organicelement.com >>> Apache ServiceMix :: http://servicemix.apache.org >>> Apache Directory Server :: http://directory.apache.org >>> >
