You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2009/11/24 12:49:55 UTC
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
I chatted with Luciano about this the other day and we debugged
through it and it turns out the problem was caused by some module test
classes being added to the samples classpath. It looked like that
could have been caused by a bug in the mvn -Peclipse .classpath
generation though i've not been able to recreate it. Does anyone else
see any of the module test classes in the samples referenced libraries
in Eclipse?
...ant
On Sat, Nov 22, 2008 at 5:11 AM, <lr...@apache.org> wrote:
> Author: lresende
> Date: Fri Nov 21 21:11:38 2008
> New Revision: 719807
>
> URL: http://svn.apache.org/viewvc?rev=719807&view=rev
> Log:
> Using contribution helper to properly discover the contribution location
>
> Modified:
> tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>
> Modified: tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
> URL: http://svn.apache.org/viewvc/tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java?rev=719807&r1=719806&r2=719807&view=diff
> ==============================================================================
> --- tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java (original)
> +++ tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java Fri Nov 21 21:11:38 2008
> @@ -18,9 +18,11 @@
> */
> package calculator;
>
> -import static org.junit.Assert.*;
> +import static org.junit.Assert.assertEquals;
>
> import org.apache.tuscany.sca.node.Client;
> +import org.apache.tuscany.sca.node.Contribution;
> +import org.apache.tuscany.sca.node.ContributionLocationHelper;
> import org.apache.tuscany.sca.node.Node;
> import org.apache.tuscany.sca.node.NodeFactory;
> import org.junit.AfterClass;
> @@ -40,7 +42,9 @@
>
> @BeforeClass
> public static void setUpBeforeClass() throws Exception {
> - node = NodeFactory.newInstance().createNode();
> + NodeFactory factory = NodeFactory.newInstance();
> + String contribution = ContributionLocationHelper.getContributionLocation(CalculatorClient.class);
> + node = factory.createNode("Calculator.composite", new Contribution("calculator", contribution));
> node.start();
>
> calculatorService = ((Client)node).getService(CalculatorService.class, "CalculatorServiceComponent");
>
>
>
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by Simon Laws <si...@googlemail.com>.
I looked at the "Referenced Libraries" folder of the
samples/calculator project that I have loaded in eclipse currently.
Looks OK to me with no extra test files. I create the eclipse project
using mvn -Peclipse
Simon
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by Raymond Feng <en...@gmail.com>.
When a dependent module is part of the reactor build, maven eclipse plugin
will add the module as a "src" dependency. That's what happens when you run
mvn -Peclipse from trunk folder.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Tuesday, November 24, 2009 11:27 AM
To: <de...@tuscany.apache.org>
Subject: Re: svn commit: r719807 -
/tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
> Thats intersting, no i have:
>
> <classpathentry kind="var"
> path="M2_REPO/org/apache/tuscany/sca/tuscany-deployment/2.0-SNAPSHOT/tuscany-deployment-2.0-SNAPSHOT.jar"/>
>
> which i guess explains why i don't see them.
>
> ...ant
>
> On Tue, Nov 24, 2009 at 7:21 PM, Raymond Feng <en...@gmail.com> wrote:
>> Do you have tuscany-deployment shown as a project or jar in the
>> .classpath
>> of sample-calculator? The test resources/classes are only visible when
>> tuscany-deployment is a src entry in the .classpath, such as:
>>
>> <classpathentry kind="src" path="/tuscany-deployment"/>
>>
>> I confirm that the sample-calculator can see hello.deployer.HelloWorld by
>> adding the following code to the test case.
>>
>> Class cls = Class.forName("hello.deployer.HelloWorld");
>>
>> Thanks,
>> Raymond
>>
>> --------------------------------------------------
>> From: "ant elder" <an...@apache.org>
>> Sent: Tuesday, November 24, 2009 11:09 AM
>> To: <de...@tuscany.apache.org>
>> Subject: Re: svn commit: r719807 -
>> /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>>
>>> On Tue, Nov 24, 2009 at 6:28 PM, Raymond Feng <en...@gmail.com>
>>> 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
>>
>>
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by ant elder <an...@apache.org>.
Thats intersting, no i have:
<classpathentry kind="var"
path="M2_REPO/org/apache/tuscany/sca/tuscany-deployment/2.0-SNAPSHOT/tuscany-deployment-2.0-SNAPSHOT.jar"/>
which i guess explains why i don't see them.
...ant
On Tue, Nov 24, 2009 at 7:21 PM, Raymond Feng <en...@gmail.com> wrote:
> Do you have tuscany-deployment shown as a project or jar in the .classpath
> of sample-calculator? The test resources/classes are only visible when
> tuscany-deployment is a src entry in the .classpath, such as:
>
> <classpathentry kind="src" path="/tuscany-deployment"/>
>
> I confirm that the sample-calculator can see hello.deployer.HelloWorld by
> adding the following code to the test case.
>
> Class cls = Class.forName("hello.deployer.HelloWorld");
>
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "ant elder" <an...@apache.org>
> Sent: Tuesday, November 24, 2009 11:09 AM
> To: <de...@tuscany.apache.org>
> Subject: Re: svn commit: r719807 -
> /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>
>> On Tue, Nov 24, 2009 at 6:28 PM, Raymond Feng <en...@gmail.com> 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
>
>
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by Raymond Feng <en...@gmail.com>.
Do you have tuscany-deployment shown as a project or jar in the .classpath
of sample-calculator? The test resources/classes are only visible when
tuscany-deployment is a src entry in the .classpath, such as:
<classpathentry kind="src" path="/tuscany-deployment"/>
I confirm that the sample-calculator can see hello.deployer.HelloWorld by
adding the following code to the test case.
Class cls = Class.forName("hello.deployer.HelloWorld");
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Tuesday, November 24, 2009 11:09 AM
To: <de...@tuscany.apache.org>
Subject: Re: svn commit: r719807 -
/tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
> On Tue, Nov 24, 2009 at 6:28 PM, Raymond Feng <en...@gmail.com> 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
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by Simon Laws <si...@googlemail.com>.
>
> Interestingly according to the STP project planning page they're about
> to start trying to use our 2.x runtime -
> http://wiki.eclipse.org/STP/SCA_Project#Planning
>
> ...ant
>
Good spot!
Simon
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by ant elder <an...@apache.org>.
On Wed, Nov 25, 2009 at 3:52 PM, Simon Laws <si...@googlemail.com> wrote:
> On Wed, Nov 25, 2009 at 3:43 PM, ant elder <an...@apache.org> wrote:
>> On Wed, Nov 25, 2009 at 3:16 PM, Simon Laws <si...@googlemail.com> wrote:
>>>> The issue with doing that is that the contribution then gets included
>>>> in the Tuscany runtime classpath and the Tuscany runtime gets included
>>>> in the contribution classpath - so its not really properly testing how
>>>> it would be used which leads to bugs. This is a real issue as while
>>>> i'm working on all this domain and client stuff I keep coming across
>>>> issues where things dont work properly as its only ever been tested
>>>> with the contribution part of the system classpath.
>>>>
>>>> ...ant
>>>>
>>>
>>> OK, fair point. We just then need a sample launcher project that
>>> allows us and our users to easily run the samples from Eclipse in lieu
>>> of us bringing up the Eclipse plugin. Even when we do I would argue
>>> that it's useful for a user to be able to easily fire up a
>>> contribution from the binary distribution without needing to further
>>> configure their Eclipse environment. I guess we can debate that. In
>>> the mean time though we do need an easy way to run sample
>>> contributions during development.
>>>
>>> Simon
>>>
>>
>> In r884146 I've added the maven tuscany plugin to the helloworld
>> sample pom.xml so you can now run it with "mvn tuscany:run"
>>
>> You could also run it with the the launcher from the trunk
>> distribution build by doing:
>>
>> ..\..\distribution\all\target\apache-tuscany-sca-all-2.0-SNAPSHOT.dir\tuscany-sca-2.0-SNAPSHOT\bin\tuscany.bat
>> target\sample-helloworld.jar
>>
>> or more simply by first adding that to your environment path eg:
>>
>> set PATH=\Tuscany\trunk\distribution\all\target\apache-tuscany-sca-all-2.0-SNAPSHOT.dir\tuscany-sca-2.0-SNAPSHOT\bin;%PATH%
>>
>> and then you can run any sample with:
>>
>> tuscany target\sample-helloworld.jar
>
> nice
>
>>
>> I'm not sure about Eclipse, ideally you would have some Eclipse plugin
>> like the old Tuscany one or the STP one wouldnt you? (eg you can't run
>> an webapp or ejb in eclipse without first installing some container
>> plugin).
>
> +1 but we don't have it today
>
> If there's an itest for the sample like the
>> itest-sample-helloworld one you can run that in eclipse, doesn't that
>> do what you want or am i misunderstanding what you're suggesting?
>
> We can but a user of the distribution can't. I guess this comes down
> to what we want to put on the TODO list for eclipse for 2.0. If we
> agree to put the eclipse plugin on the list (or help the STP project
> to get some support for 2.0 in the right kind of timeframe) then I
> agree that's the right long term approach. If we can't do that then I
> think we need to help the user out.
>
> I'd be happy to include either of those tasks. Ease of use should be
> one of our objectives. As an aside, if we decide to go down the plugin
> route in the first instance I think we can make it slicker now that we
> have the registry in the runtime.
>
> Simon
>
Interestingly according to the STP project planning page they're about
to start trying to use our 2.x runtime -
http://wiki.eclipse.org/STP/SCA_Project#Planning
...ant
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Nov 25, 2009 at 3:43 PM, ant elder <an...@apache.org> wrote:
> On Wed, Nov 25, 2009 at 3:16 PM, Simon Laws <si...@googlemail.com> wrote:
>>> The issue with doing that is that the contribution then gets included
>>> in the Tuscany runtime classpath and the Tuscany runtime gets included
>>> in the contribution classpath - so its not really properly testing how
>>> it would be used which leads to bugs. This is a real issue as while
>>> i'm working on all this domain and client stuff I keep coming across
>>> issues where things dont work properly as its only ever been tested
>>> with the contribution part of the system classpath.
>>>
>>> ...ant
>>>
>>
>> OK, fair point. We just then need a sample launcher project that
>> allows us and our users to easily run the samples from Eclipse in lieu
>> of us bringing up the Eclipse plugin. Even when we do I would argue
>> that it's useful for a user to be able to easily fire up a
>> contribution from the binary distribution without needing to further
>> configure their Eclipse environment. I guess we can debate that. In
>> the mean time though we do need an easy way to run sample
>> contributions during development.
>>
>> Simon
>>
>
> In r884146 I've added the maven tuscany plugin to the helloworld
> sample pom.xml so you can now run it with "mvn tuscany:run"
>
> You could also run it with the the launcher from the trunk
> distribution build by doing:
>
> ..\..\distribution\all\target\apache-tuscany-sca-all-2.0-SNAPSHOT.dir\tuscany-sca-2.0-SNAPSHOT\bin\tuscany.bat
> target\sample-helloworld.jar
>
> or more simply by first adding that to your environment path eg:
>
> set PATH=\Tuscany\trunk\distribution\all\target\apache-tuscany-sca-all-2.0-SNAPSHOT.dir\tuscany-sca-2.0-SNAPSHOT\bin;%PATH%
>
> and then you can run any sample with:
>
> tuscany target\sample-helloworld.jar
nice
>
> I'm not sure about Eclipse, ideally you would have some Eclipse plugin
> like the old Tuscany one or the STP one wouldnt you? (eg you can't run
> an webapp or ejb in eclipse without first installing some container
> plugin).
+1 but we don't have it today
If there's an itest for the sample like the
> itest-sample-helloworld one you can run that in eclipse, doesn't that
> do what you want or am i misunderstanding what you're suggesting?
We can but a user of the distribution can't. I guess this comes down
to what we want to put on the TODO list for eclipse for 2.0. If we
agree to put the eclipse plugin on the list (or help the STP project
to get some support for 2.0 in the right kind of timeframe) then I
agree that's the right long term approach. If we can't do that then I
think we need to help the user out.
I'd be happy to include either of those tasks. Ease of use should be
one of our objectives. As an aside, if we decide to go down the plugin
route in the first instance I think we can make it slicker now that we
have the registry in the runtime.
Simon
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by Simon Laws <si...@googlemail.com>.
>
> As the specs only really define zip contributions I've changed the
> helloworld sample to be a zip instead of a jar. Looking at that I'm
> wondering if it wouldnt be better to have the zip contribution plugin
> that we almost released once, its simpler to use and the maven project
> classifier and artifact ends up as a single zip without the jar one as
> happens now. Any have opinions either way?
>
> ...ant
>
Anything that removes the need to use the assembly plugin is fine by
me. Asking our users to understand it just to zip up a contribution is
asking too much.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by ant elder <an...@apache.org>.
On Wed, Nov 25, 2009 at 3:16 PM, Simon Laws <si...@googlemail.com> wrote:
>> The issue with doing that is that the contribution then gets included
>> in the Tuscany runtime classpath and the Tuscany runtime gets included
>> in the contribution classpath - so its not really properly testing how
>> it would be used which leads to bugs. This is a real issue as while
>> i'm working on all this domain and client stuff I keep coming across
>> issues where things dont work properly as its only ever been tested
>> with the contribution part of the system classpath.
>>
>> ...ant
>>
>
> OK, fair point. We just then need a sample launcher project that
> allows us and our users to easily run the samples from Eclipse in lieu
> of us bringing up the Eclipse plugin. Even when we do I would argue
> that it's useful for a user to be able to easily fire up a
> contribution from the binary distribution without needing to further
> configure their Eclipse environment. I guess we can debate that. In
> the mean time though we do need an easy way to run sample
> contributions during development.
>
> Simon
>
In r884146 I've added the maven tuscany plugin to the helloworld
sample pom.xml so you can now run it with "mvn tuscany:run"
You could also run it with the the launcher from the trunk
distribution build by doing:
..\..\distribution\all\target\apache-tuscany-sca-all-2.0-SNAPSHOT.dir\tuscany-sca-2.0-SNAPSHOT\bin\tuscany.bat
target\sample-helloworld.jar
or more simply by first adding that to your environment path eg:
set PATH=\Tuscany\trunk\distribution\all\target\apache-tuscany-sca-all-2.0-SNAPSHOT.dir\tuscany-sca-2.0-SNAPSHOT\bin;%PATH%
and then you can run any sample with:
tuscany target\sample-helloworld.jar
I'm not sure about Eclipse, ideally you would have some Eclipse plugin
like the old Tuscany one or the STP one wouldnt you? (eg you can't run
an webapp or ejb in eclipse without first installing some container
plugin). If there's an itest for the sample like the
itest-sample-helloworld one you can run that in eclipse, doesn't that
do what you want or am i misunderstanding what you're suggesting?
...ant
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by Simon Laws <si...@googlemail.com>.
> The issue with doing that is that the contribution then gets included
> in the Tuscany runtime classpath and the Tuscany runtime gets included
> in the contribution classpath - so its not really properly testing how
> it would be used which leads to bugs. This is a real issue as while
> i'm working on all this domain and client stuff I keep coming across
> issues where things dont work properly as its only ever been tested
> with the contribution part of the system classpath.
>
> ...ant
>
OK, fair point. We just then need a sample launcher project that
allows us and our users to easily run the samples from Eclipse in lieu
of us bringing up the Eclipse plugin. Even when we do I would argue
that it's useful for a user to be able to easily fire up a
contribution from the binary distribution without needing to further
configure their Eclipse environment. I guess we can debate that. In
the mean time though we do need an easy way to run sample
contributions during development.
Simon
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by ant elder <an...@apache.org>.
On Wed, Nov 25, 2009 at 2:55 PM, Simon Laws <si...@googlemail.com> wrote:
>
> Should the sample be a jar instead of a
>> zip?
>
> Zip is the default SCA support contribution format but Jar is valid
> also so a mixture of both is ok.
>
As the specs only really define zip contributions I've changed the
helloworld sample to be a zip instead of a jar. Looking at that I'm
wondering if it wouldnt be better to have the zip contribution plugin
that we almost released once, its simpler to use and the maven project
classifier and artifact ends up as a single zip without the jar one as
happens now. Any have opinions either way?
...ant
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by ant elder <an...@apache.org>.
On Wed, Nov 25, 2009 at 2:55 PM, Simon Laws <si...@googlemail.com> wrote:
> Just finishing off a policy test before I update with your change. In
> the mean time
>
> ...snip
> samples/helloworld which is a plain SCA contribution
>> with a unit test that doesn't use any Tuscany, and an
>> itest/samples/helloworld which is an integration test for the
>> helloworld sample that runs it in Tuscany. Is that the type of thing
>> most of the samples should be?
>
> Sounds like the right sort of thing. I don't actually mind having a
> Tuscany specific unit test in the contribution if this helps
> development, for example, in Eclipse.
The issue with doing that is that the contribution then gets included
in the Tuscany runtime classpath and the Tuscany runtime gets included
in the contribution classpath - so its not really properly testing how
it would be used which leads to bugs. This is a real issue as while
i'm working on all this domain and client stuff I keep coming across
issues where things dont work properly as its only ever been tested
with the contribution part of the system classpath.
...ant
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by ant elder <an...@apache.org>.
On Wed, Nov 25, 2009 at 11:40 AM, Simon Laws <si...@googlemail.com> wrote:
> +1 to being explicit about contribution location. I would favour an
> approach where sample projects simply produce contributions. They can
> then we used by launchers of various flavours.
>
> command line
> embedded
> domain
>
> We would though still need to include tests for the samples. We could
> either stick with unit tests or use the itests. We should use a
> mixture of a limited number of approaches to show best practice for
> each situation.
>
> Simon
>
Ok that all sounds fine to me. Shall we explore what that would look
like - I've added samples/helloworld which is a plain SCA contribution
with a unit test that doesn't use any Tuscany, and an
itest/samples/helloworld which is an integration test for the
helloworld sample that runs it in Tuscany. Is that the type of thing
most of the samples should be? Should the sample be a jar instead of a
zip? Should we have a plugin for running the itest instead of manually
createing a runtime along the lines of how things like webapps are
usually tested?
...ant
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by Simon Laws <si...@googlemail.com>.
+1 to being explicit about contribution location. I would favour an
approach where sample projects simply produce contributions. They can
then we used by launchers of various flavours.
command line
embedded
domain
We would though still need to include tests for the samples. We could
either stick with unit tests or use the itests. We should use a
mixture of a limited number of approaches to show best practice for
each situation.
Simon
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by ant elder <an...@apache.org>.
On Tue, Nov 24, 2009 at 8:17 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Tue, Nov 24, 2009 at 11:09 AM, ant elder <an...@apache.org> wrote:
>> On Tue, Nov 24, 2009 at 6:28 PM, Raymond Feng <en...@gmail.com> 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
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Nov 24, 2009 at 11:09 AM, ant elder <an...@apache.org> wrote:
> On Tue, Nov 24, 2009 at 6:28 PM, Raymond Feng <en...@gmail.com> 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/
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by ant elder <an...@apache.org>.
On Tue, Nov 24, 2009 at 6:28 PM, Raymond Feng <en...@gmail.com> 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
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by Raymond Feng <en...@gmail.com>.
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.
The root cause of this behavior is that Eclipse doesn't distinguish between
scopes of maven dependencies. In maven, test dependencies are not
transitive. When we run a test case from A, B's test resources or classes
are not visible to A.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Tuesday, November 24, 2009 9:45 AM
To: <de...@tuscany.apache.org>
Subject: Re: svn commit: r719807 -
/tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
> Ok if its not the .classpath what else could be causing it? The
> problem was when running in Eclipse the test classes from the
> deployment and node-impl modules were being included in the classpath
> for the calculator sample.
>
> ...ant
>
> On Tue, Nov 24, 2009 at 5:24 PM, Raymond Feng <en...@gmail.com> wrote:
>> I don't think it is a .classpath issue. When you launch a test case or
>> main
>> class within Eclipse, it aggregates all the class path entries from the
>> depending projects. Eclipse doesn't have the concept of "test" dependency
>> but maven does.
>>
>> Thanks,
>> Raymond
>> --------------------------------------------------
>> From: "ant elder" <an...@gmail.com>
>> Sent: Tuesday, November 24, 2009 3:49 AM
>> To: <de...@tuscany.apache.org>
>> Subject: Re: svn commit: r719807 -
>> /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>>
>>> I chatted with Luciano about this the other day and we debugged
>>> through it and it turns out the problem was caused by some module test
>>> classes being added to the samples classpath. It looked like that
>>> could have been caused by a bug in the mvn -Peclipse .classpath
>>> generation though i've not been able to recreate it. Does anyone else
>>> see any of the module test classes in the samples referenced libraries
>>> in Eclipse?
>>>
>>> ...ant
>>>
>>> On Sat, Nov 22, 2008 at 5:11 AM, <lr...@apache.org> wrote:
>>>>
>>>> Author: lresende
>>>> Date: Fri Nov 21 21:11:38 2008
>>>> New Revision: 719807
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=719807&view=rev
>>>> Log:
>>>> Using contribution helper to properly discover the contribution
>>>> location
>>>>
>>>> Modified:
>>>>
>>>>
>>>> tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>>>>
>>>> Modified:
>>>> tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>>>> URL:
>>>> http://svn.apache.org/viewvc/tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java?rev=719807&r1=719806&r2=719807&view=diff
>>>>
>>>> ==============================================================================
>>>> ---
>>>>
>>>> tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>>>> (original)
>>>> +++
>>>> tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>>>> Fri Nov 21 21:11:38 2008
>>>> @@ -18,9 +18,11 @@
>>>> */
>>>> package calculator;
>>>>
>>>> -import static org.junit.Assert.*;
>>>> +import static org.junit.Assert.assertEquals;
>>>>
>>>> import org.apache.tuscany.sca.node.Client;
>>>> +import org.apache.tuscany.sca.node.Contribution;
>>>> +import org.apache.tuscany.sca.node.ContributionLocationHelper;
>>>> import org.apache.tuscany.sca.node.Node;
>>>> import org.apache.tuscany.sca.node.NodeFactory;
>>>> import org.junit.AfterClass;
>>>> @@ -40,7 +42,9 @@
>>>>
>>>> @BeforeClass
>>>> public static void setUpBeforeClass() throws Exception {
>>>> - node = NodeFactory.newInstance().createNode();
>>>> + NodeFactory factory = NodeFactory.newInstance();
>>>> + String contribution =
>>>> ContributionLocationHelper.getContributionLocation(CalculatorClient.class);
>>>> + node = factory.createNode("Calculator.composite", new
>>>> Contribution("calculator", contribution));
>>>> node.start();
>>>>
>>>> calculatorService =
>>>> ((Client)node).getService(CalculatorService.class,
>>>> "CalculatorServiceComponent");
>>>>
>>>>
>>>>
>>
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by ant elder <an...@apache.org>.
Ok if its not the .classpath what else could be causing it? The
problem was when running in Eclipse the test classes from the
deployment and node-impl modules were being included in the classpath
for the calculator sample.
...ant
On Tue, Nov 24, 2009 at 5:24 PM, Raymond Feng <en...@gmail.com> wrote:
> I don't think it is a .classpath issue. When you launch a test case or main
> class within Eclipse, it aggregates all the class path entries from the
> depending projects. Eclipse doesn't have the concept of "test" dependency
> but maven does.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "ant elder" <an...@gmail.com>
> Sent: Tuesday, November 24, 2009 3:49 AM
> To: <de...@tuscany.apache.org>
> Subject: Re: svn commit: r719807 -
> /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>
>> I chatted with Luciano about this the other day and we debugged
>> through it and it turns out the problem was caused by some module test
>> classes being added to the samples classpath. It looked like that
>> could have been caused by a bug in the mvn -Peclipse .classpath
>> generation though i've not been able to recreate it. Does anyone else
>> see any of the module test classes in the samples referenced libraries
>> in Eclipse?
>>
>> ...ant
>>
>> On Sat, Nov 22, 2008 at 5:11 AM, <lr...@apache.org> wrote:
>>>
>>> Author: lresende
>>> Date: Fri Nov 21 21:11:38 2008
>>> New Revision: 719807
>>>
>>> URL: http://svn.apache.org/viewvc?rev=719807&view=rev
>>> Log:
>>> Using contribution helper to properly discover the contribution location
>>>
>>> Modified:
>>>
>>>
>>> tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>>>
>>> Modified:
>>> tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>>> URL:
>>> http://svn.apache.org/viewvc/tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java?rev=719807&r1=719806&r2=719807&view=diff
>>>
>>> ==============================================================================
>>> ---
>>> tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>>> (original)
>>> +++
>>> tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>>> Fri Nov 21 21:11:38 2008
>>> @@ -18,9 +18,11 @@
>>> */
>>> package calculator;
>>>
>>> -import static org.junit.Assert.*;
>>> +import static org.junit.Assert.assertEquals;
>>>
>>> import org.apache.tuscany.sca.node.Client;
>>> +import org.apache.tuscany.sca.node.Contribution;
>>> +import org.apache.tuscany.sca.node.ContributionLocationHelper;
>>> import org.apache.tuscany.sca.node.Node;
>>> import org.apache.tuscany.sca.node.NodeFactory;
>>> import org.junit.AfterClass;
>>> @@ -40,7 +42,9 @@
>>>
>>> @BeforeClass
>>> public static void setUpBeforeClass() throws Exception {
>>> - node = NodeFactory.newInstance().createNode();
>>> + NodeFactory factory = NodeFactory.newInstance();
>>> + String contribution =
>>> ContributionLocationHelper.getContributionLocation(CalculatorClient.class);
>>> + node = factory.createNode("Calculator.composite", new
>>> Contribution("calculator", contribution));
>>> node.start();
>>>
>>> calculatorService =
>>> ((Client)node).getService(CalculatorService.class,
>>> "CalculatorServiceComponent");
>>>
>>>
>>>
>
Re: svn commit: r719807 - /tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
Posted by Raymond Feng <en...@gmail.com>.
I don't think it is a .classpath issue. When you launch a test case or main
class within Eclipse, it aggregates all the class path entries from the
depending projects. Eclipse doesn't have the concept of "test" dependency
but maven does.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@gmail.com>
Sent: Tuesday, November 24, 2009 3:49 AM
To: <de...@tuscany.apache.org>
Subject: Re: svn commit: r719807 -
/tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
> I chatted with Luciano about this the other day and we debugged
> through it and it turns out the problem was caused by some module test
> classes being added to the samples classpath. It looked like that
> could have been caused by a bug in the mvn -Peclipse .classpath
> generation though i've not been able to recreate it. Does anyone else
> see any of the module test classes in the samples referenced libraries
> in Eclipse?
>
> ...ant
>
> On Sat, Nov 22, 2008 at 5:11 AM, <lr...@apache.org> wrote:
>> Author: lresende
>> Date: Fri Nov 21 21:11:38 2008
>> New Revision: 719807
>>
>> URL: http://svn.apache.org/viewvc?rev=719807&view=rev
>> Log:
>> Using contribution helper to properly discover the contribution location
>>
>> Modified:
>>
>> tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>>
>> Modified:
>> tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>> URL:
>> http://svn.apache.org/viewvc/tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java?rev=719807&r1=719806&r2=719807&view=diff
>> ==============================================================================
>> ---
>> tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>> (original)
>> +++
>> tuscany/java/sca/samples/calculator/src/test/java/calculator/CalculatorTestCase.java
>> Fri Nov 21 21:11:38 2008
>> @@ -18,9 +18,11 @@
>> */
>> package calculator;
>>
>> -import static org.junit.Assert.*;
>> +import static org.junit.Assert.assertEquals;
>>
>> import org.apache.tuscany.sca.node.Client;
>> +import org.apache.tuscany.sca.node.Contribution;
>> +import org.apache.tuscany.sca.node.ContributionLocationHelper;
>> import org.apache.tuscany.sca.node.Node;
>> import org.apache.tuscany.sca.node.NodeFactory;
>> import org.junit.AfterClass;
>> @@ -40,7 +42,9 @@
>>
>> @BeforeClass
>> public static void setUpBeforeClass() throws Exception {
>> - node = NodeFactory.newInstance().createNode();
>> + NodeFactory factory = NodeFactory.newInstance();
>> + String contribution =
>> ContributionLocationHelper.getContributionLocation(CalculatorClient.class);
>> + node = factory.createNode("Calculator.composite", new
>> Contribution("calculator", contribution));
>> node.start();
>>
>> calculatorService =
>> ((Client)node).getService(CalculatorService.class,
>> "CalculatorServiceComponent");
>>
>>
>>