Responses inline.
Jean-Sebastien Delfino wrote:
Comments inline.
Simon Nash wrote:
There were problems with the previous structure that led to the
splitting of these samples. With all the files together in a
single module, the only way to allow the samples to run "out of
the box" in the binary distro was to place the client/application
code that used the extension in the same jar as the extension
itself, which does not show how people should actually build a
new extension. There were various emails to the list last week
about this and the separation into two samples seemed like the
best solution.
I apologize if I missed something obvious in the previous discussions,
but Is that a problem with the Ant build? Can't we run out of classes
outside of the Jar?
Actually it's an issue with the maven build. By default, the jar
step will put all .class files under target/classes into the jar. These
classes are the result of compiling all the java code that's under
src/main. The code under src/test is compiled into target/test-classes,
and maven does not include this code in the jar.
So the options were: 1) put the client/application code into src/test,
which is misleading as it is sample client code and not test code,
or 2) find a way to stop maven from putting all the target/classes code
into the jar. The latter might have been possible, but neither SimonL
or I knew how to do it, and it seemed cleaner to go with a separate
module (and jar) for the sample application code.
I would like to keep the "split" structure as it currently is
rather than make a last minute change just before the 0.90 RC
without opportunity for discussion. (I'm on a plane tomorrow so
I won't have any email access all day.) I am fine with the
proposed renaming of the samples as suggested:
- echo-binding to echo-binding-extension
- echo-binding-appl to echo-binding
- implementation-crud to implementation-crud-extension
- implementation-crud-client to implementation-crud
Adding the "extension" suffix to the extension samples makes the
purpose of these samples clearer and solves the awkwardness over
how to describe the non-extension code.
Now that the release work is done, I'd like to see if we could simplify
this in the trunk and reduce the number of modules, then we won't have
to find good names for them :)
Quite a few of the samples come in pairs, with client code and server code
or (now) extension code and application code. I think the most important
thing is for the samples to follow a simple, clear and readily understandable
pattern, and to observe good practice that people will use to develop real
applications and extensions. If we can reduce the number of modules
without breaking these principles, that's great :-) In this case, I think
combining the extension and application modules would lead to some loss of
clarity and good structure.
The purpose of the junit test code in the "client/appl" samples is to
ensure that the client code runs successfully. The only way to test
this is by actually invoking the client code. At present the sample
client code is very similar to the junit test client code, but over
time I would expect more divergence. If it is considered undesirable
to ship a junit test for the client code as part of the samples, then
we could put it under sca/itest/samples as I originally suggested.
It was moved to its current location after discussion on the list
last week. Note that the extension sample modules contain "normal"
junit test code to ensure the extension is loaded and functional.
I think we can use the unit tests to show people:
- how to test their extension, in implementation-crud
- how to test the invocation of SCA service components, in
implementation-crud-client
- how to test the client side of an SCA application, by mocking an SCA
component, we could do this in implementation-crud-client too, but it'll
require some thinking to keep it simple.
There is a very fine line between testing the first of these and testing
the second. Implementation extensions like implementation-crud are
activated by invocations of SCA service components of that implementation
type. Can you suggest some other way to test extension code? Would this
be done with mocking code that drives the extension code using the SPIs?
Testing that our sample client doesn't fail with an exception is useful
to us and may deserve a test in our integration test suite (if we think
that having a proper unit test case testing the bits and pieces in that
module is not good enough), but I don't thing that it's interesting to
keep it in the sample itself, as it's not going to teach anything to an
application developer looking at the sample, and doesn't look like a
"normal" unit test case.
Yes, agreed that this does not really belong in the samples. I would be
inclined to put this test code in itest/samples, just to have the build
confirm automatically that all the sample clients actually do run. It's
good to have equivalent unit tests as well, but the samples are so visible
that I think it's worth testing them explicitly.
I agree with making the client/application packages different from
the extension packages. This had been discussed and agreed on the
list and it should have already been that way.
I'd like to better understand the comment about putting test resources
into src/test/resources. In both implementation-crud-client and
binding-echo-appl, the only resources are the composites, and these
are used by the client/application code in src/main. The junit tests
invoke the client code, and the client code uses these resources.
The client code also uses these resources even when it is invoked
directly from the command line and not from the junit tests. So I
don't think it would be correct to move these composites from
src/main to src/test.
I was talking about
incubator/tuscany/java/sca/samples/implementation-crud/src/main/resources/crud.composite
It was only used by the test case in this module, and I moved it to
src/test/resources in revision r539773.
Sorry for misunderstanding. I thought that you were talking about
resource files in the client/application samples. This file in
implementation-crud was misplaced, and moving it was a good catch.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
