Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[swordfish-dev] Chat transcript 01/12/2008

Title: Chat transcript 01/12/2008
[START Transcript 01/12/2008]

Andrey Kopachevsky
I'm currently optimizing smx3 compatibility bundle, it is possible to get rid of losts needles jars, hope finish today
I've reduced org.eclipse.swordfish.compatibility.smx3  jars  number from 57 to ... 6. Probably it cutted some functionality that we are сuttently not using...
So integration tests passed, Volodimyr's http round trip also works. Check out exchange/dwolz/
Yes, this 6 jars now downloading downloading from maven repository, so all  smx3 project's jars should be moved from svn
I've reviewed refactored projects, don't have objections against core project divided on several bundles, but I steel don't see much sense in dividing core.test project on several bundles because following reasons:

1. after refactoring we have only org.eclipse.swordfish.core.test that has sever source files, all other project have only 1 testcase class per project, does it make sense to create separate project to host one or too files?

2. every test project should have dependency on org.eclipse.swordfish.core.test because it includes some utils classes and BaseOsgiTestCase - base class for every swordfish integration testcase

3. pom.xml in every integration test project almost the same, so to reduce repeated code we at least should create parent project and move there all similar stuff.

Dietmar Wolz
had to adapt some stuff to maintain compatibility with the new api from Andreas. Everything compiles, but no test run so far.
Regarding the splitting of the tests - we will provide some arguments soon

Andrey Kopachevsky

Oliver Wolf
@andrey, some reasons for splitting the integration tests are:
1. since the functionality is spread across multiple bundles, it is more natural to split the integrations tests related to this functionality as well
2. keeping them separate makes it easier to work on functionality and the related integration tests without affecting something else
3. if functionaliy is not working properly for some time, we can easily exclude the related integretion tests from running automatically during the build

Andrey Kopachevsky
well, I see your point


Want to join the chat?


Oliver Wolf

Back to the top