Simon Nash wrote:
Simon Laws wrote:
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.
Ok, if we reduce this to the one contribution that holds the test code
I'm +1 for that. Of the options here then, 1 seems most
straighforward.
Simon
Thanks, I'll make these changes to introducing-launcher so we can see
how it looks.
Simon
I have made these updates. The introducing-launcher module is no
longer a contribution, and now only contains two files:
src/main/java/scatours/IntroducingLauncher.java
src/test/java/scatours/IntroducingTestCase.java
I also updated build.xml so that it does not create a jar file
containing IntroducingLauncher.class (not very useful with only one
class). I don't know how to tweak the pom.xml to do this, so the
mvn build is still creating an scatours-introducing-launcher.jar file.
Simon
