[swordfish-dev] Chat transcript 09/02/2009

[Oliver Wolf <oliver.wolf@xxxxxxxxx>]

Title: Chat transcript 09/02/2009

[START Transcript 09/02/2009]

Jürgen Kindler
Hi, I'm currently trying to dig into the Swordfish. Could anybody explain what the *.compatibility.* and the *.endpoints.* are about?
I would also like to understand how the packages are in general structured - esp.  concerning QA.  I see there is one *.test.util here and also a couple of tests. How many of the tests are real unit tests and which are rather integration tests?

Andrey Kopachevsky
*.compatibility - are extension bundles to solve different class loading issues, for example to help particular bundle to find jaxp factory implementation class path

Jürgen Kindler
So this is OSGi specific to some extend?

Andrey Kopachevsky
yes, we can say that

Jürgen Kindler
I see that for those packages the src/main/java only contains dummy classes ... so the relevant info must be in the resources or jar files in the projects, right?

Andrey Kopachevsky
yes, this is extension bundle it purpose is to extend master bundle classpath, so all bundle configuration is placed in MANIFEST.mf file, with generating using felix plugin, see project pom.xml

Jürgen Kindler
So these are special sets of configurations? As I remember ServiceMix has CXF inside already ...

Andrey Kopachevsky
yes but it was issue with osgi support

Jürgen Kindler
Not sure if I understand that... Was the issue that you wanted to connect to Swordfish via CXF directly and that did not work easily because of OSGi classloading?

Andrey Kopachevsky
one min I try to find this discussion in archive, Guillaume Noded was also partisipate in it

Jürgen Kindler
Would I be able to look for it on the Sworfish website instead of bothering you?#

Andrey Kopachevsky
it quite hard to find on site, here is our archives http://dev.eclipse.org/mhonarc/lists/swordfish-dev/maillist.html
but I coudn't find chat transcript for this stuff

Jürgen Kindler
OK, thanks - I'll have a look ...

Andrey Kopachevsky
we are using cxf-bundle-minimal, instead cfx-bundle that uses in SMX4, I can't tell you strictly why we choose it, Volodimir could explain better but I suspect minial bundle required less dependencies
but I also requred additional fixing as you see

Jürgen Kindler
Hm, I see... so what I see there is something from ServiceMix that has been modified / tailroed to the needs of Swordfish, right?
As you are talking about SMX 4 and I see smx3  - does this mean, both versions of SMX will be supported? Or is SMX3 just for backwards compatibility?

Andrey Kopachevsky
SMX3 not supoorted by swordfish, where did you see SMX3 mentions?

Jürgen Kindler
So why do we need *.compatibility.smx3 then?

Andrey Kopachevsky
I fogot about this bundle, this is not extension bundle, this is lib boundle, this is SMX4 dependency for jbi
see this article
http://gnodet.blogspot.com/2008/05/servicemix-4-nmr-on-equinox.html
oh, this better
http://cwiki.apache.org/SMX4NMR/4-installing-the-nmr-in-equinox.html
this is example how to run SMX4 on equinox and execute simple jbi http call
to support jbi in this example you need to install servicemix-shared-compat-3.2.1-installer.zip

Jürgen Kindler
Hm, thanks - so the naming of the package made me draw a false conclusion... ? OOPS!? servicemix-shared-compat-3.2.1-installer.zip belongs to SMX4?

Guillaume Nodet
actually, it kinda belongs to both
the latest version is named 2008.01 to avoid this confusion as it is now shared between smx3 and smx4

Jürgen Kindler
Phew... that 2008.01 is also very meaningful 
OK, so from your perspective - what would be the best starting point to dig into Swordfish?
OOps... forgot one question...

Andrey Kopachevsky
you've asked about integration tests, I think this is a good start point

Jürgen Kindler
So you mean the existing tests?

Andrey Kopachevsky
yeap
start point for get deep into code?
or for start develompent?

Jürgen Kindler
From QA perspective towards understanding how to improve testing. So you pulled me right into my question...
The project uses Spring OSGi, but also JUnit 4.4
Which is kind of a contradiction, because with Spring OSGi it is not possible to use OSGi Mocks and JUnit 4.

Andrey Kopachevsky
so, at the moment *.test project are mostly integration tests, they all have dependency on core.test.util wich is mostly lib project with spring osgi helpers
but as I know we don't have cleare strategy to split unit and integration tests for now

Jürgen Kindler
Hm... personally I would move integration tests to a separate project - at least if they are time consuming and only retain unit tests in the production projects...
Just to have a fast build with basic QA and have the integration test suite in one (or more pieces) separately.
Which means that I soppose that even test code is product / production code 

Andrey Kopachevsky
yes agree

Jürgen Kindler
I peeked a bit into Riena where some former colleagues are working and found something I also thought about aleady: The use annotations to tag tests with categories so they can collect them in a generic way without using naming conventions.

Andrey Kopachevsky
cool)
also we with Oliver and Ditmar came to conclusion to group integration test project and move it to separate maven project
also problem that we have now with integration test is slightly different behavior with test running as maven test run and eclipse ide based, this is because Spring OSGI low maturity age
I hope my message clear)

Jürgen Kindler
You mean thet tests executed by Maven react differently when executed in an OSGi console in Eclipse?

Andrey Kopachevsky
not osgi console
you can run spring integration test as common junit test
so we had situation when you run it from eclipse and it passed, but when we run with "mvn test" command it failed

Jürgen Kindler
Could you point me to one of the tests that showed that behaviour?
Or should I just try by myself... OK, I guess that's best!

Andrey Kopachevsky
Volodimir fixed this issue, but we didin't understand it's root clear, so It can come up again in future, as starting poring you can build project and try to run any of integration tests from eclipse and from maven
just download trunk project, and execute mvn install eclipse:eclipse 

Jürgen Kindler
OK, so it looks like the Spring OSGi Mock Objects has not been used yet ...

Andrey Kopachevsky
yes

Jürgen Kindler
I would tend to go back to JUnit 3.* - at least for integration tests - otherwise Spring Mocks are not available ...
we use junit 3 at the moment for plain unit tests

Jürgen Kindler
Ok, looks I am blind  
It means you use JUnit 4 without annotations or you really use the junit3.* jar?

Andrey Kopachevsky
don't sure)

Jürgen Kindler
I#ll check - after the sprint meeting ...
Hi folks, Dietmar told me that the integration tests I am looking for may be in a place different from the trunk of Swordfish!?? If so, where wouldI find them?

Andrey Kopachevsky
I don't know about those test)

Jürgen Kindler
Hm, so the tests you know are simply those I can find within the normal projects under src/test/java ? (As I thought before Dietmar told me otherwise)
OK ... now I understand how it works... I just manage to squeeze out the info from Dietmar ...:)
I just could not see the test projects in my Eclipse because they are not referenced in the main project.
I would propose that there should be two additional container projects. One that contains the tests and one that wraps the current main project plus the test container. That would simplify the setup and make tests visible immediately ...
I have a bit of experience with Maven so I could take care of that 
Any objections?  
Ok, then  
CU

Andrey Kopachevsky
I don't understud about and one that wraps the current main project plus the test container
ok)
bye

[END]

Want to join the chat? 
http://www.skype.com/go/joinpublicchat?skypename=ranyart99&topic=Swordfish%20Developers&blob=Gu7tZh64gTuo551Icz6_iwhXVeXxQ0K4yEzI5XFwGdWIQ_-miteLtgSBILodJ8koN6Uwy9PiotEU5ewRYFqEJeUtl1Yhfc1ipuVwOFz0SWN9HwMZAeikprh0R_8

-- 
Wir bieten Trainings zu SOA:
Jetzt online auf unserer Homepage informieren und schnell buchen!
 
 
Oliver Wolf
Tel.:    +49 228-182 19059
Fax:    +49 228-182 19093
Mobil:  +49 160 98931313
oliver.wolf@xxxxxxxxxx
 
 
SOPERA GmbH - Open Source SOA
Subscription Services, Support & Maintenance, Training,
Technical SOA Consulting & Customized Development
www.sopera.com
 
SOPERA GmbH · Geschäftsführer: Dr. Ricco Deutscher, Harald Weimer, Peter Spiegel
Standort Bonn: Sträßchensweg 10 · 53113 Bonn · Handelsregister: Bonn HRB 15336
Standort München: Hohenlindnerstraße 11b · 85622 München
 
 
Vertraulichkeitshinweis: Diese Nachricht und jeder übermittelte Anhang beinhaltet vertrauliche Informationen und ist nur für die Personen oder das Unternehmen bestimmt, an welche sie tatsächlich gerichtet ist. Sollten Sie nicht der Bestimmungsempfänger sein, weisen wir Sie darauf hin, dass die Verbreitung, das (auch teilweise) Kopieren sowie der Gebrauch der empfangenen E-Mail und der darin enthaltenen Informationen gesetzlich verboten ist und gegebenenfalls Schadensersatzpflichten auslösen kann. Sollten Sie diese Nachricht aufgrund eines Übermittlungsfehlers erhalten haben, bitten wir Sie, den Sender unverzüglich hiervon in Kenntnis zu setzen.