On Tue, Nov 24, 2009 at 11:09 AM, ant elder <[email protected]> wrote: > On Tue, Nov 24, 2009 at 6:28 PM, Raymond Feng <[email protected]> wrote: >> I have explained how Eclipse builds up the classpath to run a test case. Let >> me try again. >> >> 1) The generated .classpath for each project contains entries for all maven >> dependencies with different scopes (compile/runtime/test/provide/system). >> The .classpath cannot tell the maven scope of an dependency. >> >> 2) Taking an example: there are two projects A and B. A depends on B. A has >> a test resource META-INF/sca-contribution.xml (say R1) and B also has a test >> resource META-INF/sca-contribution.xml (R2). R1 is visible on A's .classpath >> while R2 is visible on B's .classpath. >> >> 3) When we run a test case from A inside Eclipse, Eclipse creates a JUnit >> Run Profile with a classpath that combines entries from both A and B's >> .classpath. As a result, the test case will see both R1 and R2. >> > > Really? Its easy to try - the deployment module has a test class > hello.deployer.HelloWorld, thats not visible to the calculator sample > in my environment, is it in yours? It could inadvertently get used if > it was which would be a be a bit confusing wouldn't it? > > ...ant >
Independent of the investigation going on around this sample, I believe that relying solely on classpath getResource in a production environment can cause issues in a customer application environment where it could start finding multiple contributions (performance issues and other issues as well). IMO, we should encourage the usage of the NodeApi passing the contribution location, instead of using the default way without passing any contribution information... this represents a one line code change for the user/developer and can avoid multiple issues in a production environment that would not be so easy to find/investigate. -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.com/
