Simon Laws wrote:
On Wed, May 20, 2009 at 1:20 PM, Simon Nash <[email protected]> wrote:
I don't agree with the change to introducing-launcher in this commit
that puts the client code inline and eliminates the use of the
introducing-client-contribution.
Having the client code as part of the launcher is acceptable for
jumpstart-launcher to keep this sample very simple, but for the other
samples I think the pattern of having a separate contribution for
test client code is a good pattern that we should use.
Simon
[email protected] wrote:
Author: slaws
Date: Sun May 17 15:23:10 2009
New Revision: 775672
>>> (cut)
I'm trying to reduce the number of moving parts. As it stood to test
the combination of
introducing-goodvaluetrips-contribution
introducing-tuscanyscatours-contribution
required
LaunchNode
introducing-launcher as a contribution
introducing-client-contribution
I agree that we should not need to have separate moving parts for
LaunchNode and introducing-launcher as a contribution.
I thought the Node APIs required this separation, but from looking
at the changes in r775672 I see that it is possible to pass null as
the first argument to createSCANode() rather than a composite URI.
This means we can eliminate scatours.composite and we can also
eliminate having introducing-launcher as a separate contribution.
These are both useful simplifications.
which to me says Tuscany is hard to use and requires many artifacts to
get it up and running.
If we have a generic launcher then I could see the benefit of a client
contribution. But in this case we don't as the launcher is specific to
this sample so it might as well contain the test code directly.
I don't agree with this. The launcher should do what it says, i.e.,
launch the sample using the necessary contributions. It should not
do any more than this. If client test code is needed, this should
be provided separately from the launcher because it is not logically
part of the launcher. The travel sample should be illustrating best
practice, and putting client code into the launcher class itself is
very definitely not best practice. IMO the client code should be a
contribution and not loaded from the classpath, so that imports from
the provider contributions can work correctly.
If we keep client code and launcher code separate, it may be possible
to come up with a generic launcher approach. I think this would be a
very useful simplification. This could be part of the travel sample,
or perhaps we could come up with something that could be added to
the Tuscany codebase.
Now if your argument is that we want to test remote bindings on the
tuscanyscatours service the that is a good justification. We don't in
this case but I could buy it from the "consistency with other samples"
point of view. I would however suggest that, if a client contribution
is required, we add it to the launcher module by extending the
launcher contribution to remove the requirement to have as many test
contributions are there are contributions to test.
In the r775672 version of this code there is no launcher contribution
passed to createSCANode(), so I'm not sure what you mean by "extending
the launcher contribution". For the reasons I gave above, I think
client test code needs to be in its own contribution. I can think of
a few options for where these test contributions would be located:
1. Leave test contributions in the main contributions module, with a
naming convention to distinguish them from provider contributions.
2. Create a new module for test contributions. This doesn't feel right
from a modularity perspective.
3. Put test contributions into launcher modules. If we do this, I think
we should rename the current "xxx-launcher" modules to something else
like "xxx-test" to reflect their extended role.
I would be OK with 1 or 3.
Simon
Simon
