On Tue, Nov 24, 2009 at 8:17 PM, Luciano Resende <[email protected]> wrote: > 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. >
If you have multiple contributions on the classpath like is happening with this Eclipse example then having them all be found is the correct behaviour isn't it? It would be more odd if it ignored included contributions, if you don't want them found then don't include them. I do agree with that sentiment though. IMHO we should change the APIs to only use contributions not classloaders. In these samples and tests we know the location of the contribution so its simpler and clearer to just use that explicitly. I've updated the calculator sample (r884011) to show what i mean. Ideally we should also change all the samples and tests to not have the contribution be on the Tuscany runtime classpath. For that we need to rearrange things a bit so they're completely separate, it would be worth doing IMHO and then cleaning up all the APIs so thats the only way to do things. ...ant
