On 13/12/06, Steve Vinoski <[EMAIL PROTECTED]> wrote:
> The examples depend on the client (since the examples exercise the > client API - we should perhaps create another clientAPI module that is > separate from client but that is a separate discussion). I think that > the examples should therefore depend on client, and we should build > them when the client code changes. But that's not what happens right now. The way they're currently arranged, they're not part of any build. (There are also bugs in the pom, but that's a different matter.)
Yes, that was what was causing us problems. We were trying to get to a position where they were distributable easily (not saying we're there yet of course).
The problem with this is that you're trying to use the examples as tests,
No, I'm really not wanting to do that.
and only compile-time tests at that. If the APIs were properly covered by unit tests, none of the above would be an issue. I'd rather see us developing proper unit tests rather than trying to make user examples serve double duty as tests.
The examples are really designed to illustrate common usage patterns - e.g. spring integration is not used as a test. I think testing the examples is useful and important however, although I think that testing the examples will inevitably be something of a manual process depending on the example. I don't think the examples in any way replace tests.
I don't think providing such a jar yields much of a value, given that presumably the people using Qpid are developers who intend to build Qpid applications and thus will have their own build environments anyway, but it's doable either way.
We have found that it is very useful as a sanity check for people that problems they are having are not related to their build environment etc. We have several times resorted to supplying some of our users with a jar telling them to "run this". I think providing at least some examples that can be run with java -jar <example jar> helps. RG
