[swordfish-dev] Chat transcript 28/10/2008

[Oliver Wolf <oliver.wolf@xxxxxxxxx>]

Title: Chat transcript 28/10/2008

[START Transcript 28/10/2008]

Dietmar Wolz
Vololymyr - changed the master pom and the api pom (there should be no dep to camel anymore)
removed some stuff from the planner - there should be no dependency to servicemix nmr
refactored the planner and added planner.test

Volodymyr Zhabiuk
But now the planner functionality is also inside the swordfish.core
How can we merge that?

Dietmar Wolz
now the planner is clean of camel and smx core, so we could take this as a basis and adapt the other projects

Volodymyr Zhabiuk
In the swordfish.core the planner is also not coupled with NMR and Camel

Dietmar Wolz
we have also to check if the new master pom works for everyone - ans use the properties defined there

Volodymyr Zhabiuk
agree

Dietmar Wolz
why not remove all planner stuff from swordfish core and add a dependency to the planner project?
for the intergration tests to run some stuff needs to be in the local maven rep which cannot be downloaded from outside via maven, so there is a repository.zip containing all the stuff in exchange/dwolz

Volodymyr Zhabiuk
of course we may remove the planner functionality from the swordfish.core. But the thing is I have made some modifications and now we need to merge. This might be avoided if we put more emphasis on effort coordination
BTW why do we need to put the planner functionality into the separate project? Will it be used in several places?

Dietmar Wolz
lets discuss tomorrow if we want to have a separate planner service / bundle of if we integrate the planner into the core. I am in favour of a separate bundle because  then we can express the fact that it is independent from smx and camel via its dependencies. Oliver thinks that the planner eventually is too small for a separate bundle, so we need at least Andreas, Andreys and your opinion.
In this case unfortunately it was unavoidable that we both needed access to the planner, I thought the interface to the other parts is only one method, so I am suprized that major changes were necessary. I can do the merging, is your actual code in the core project?

Volodymyr Zhabiuk
Yes it is
sorry for that
But anyway, should the planner be the separate project?

Dietmar Wolz
Still not decided, if not it will be renamed to org.eclipse.swordfish.core.planner to indicate that it is part of the core. My argument in favour of a separate planner is that it is possible to build useful integration tests only using the planner and its plug-ins (strategies). Its definitely not necessary to have a separate bundle for every core package, but in this case it feels natural. It also reduces the chance of simultaneous modifications by team members.
Andreas, if you are online, perhaps you can post your opinion - and your opinion regarding whether SwordfishException should better be a RuntimeException. Since eclipse automatically generates try/catch blocks I changed my opinion regarding exceptions, now I tend to use more checked Exceptions than before.

Andrey Kopachevsky
BTW I've commited exception listener implementation this moning

Volodymyr Zhabiuk
The code becomes less readable if you use checked exceptions extensively
For example one of the most recognizable falacies of the java core is that the SQLException is checked
And it can not be solved by the IDE autogenerating facilities

Dietmar Wolz
For me its ok that SwordfishException becomes a RuntimeException, but we should wait for Andreas opinion.

Volodymyr Zhabiuk
But maybe we should allow to throw any kind of Exception from the Interceptor.process method?

Dietmar Wolz
I checked in the refactored new planner projects. To emphesize the fact that the planner is part of the core the bundle / Project / package names are renamed to org.eclipse.swordfish.core.planner. This doesn't mean that the decision to separate the planner is now done, we should rename the packages also in case we decide the planner should be part of the core bundle. Could someone try to checkout both new planner projects and try to run PlannerITest.java as unit test? you have to mvn install the planner first - and complete your local maven repo (there is a repository.zip in my share). After you can successfully reproduce the test I can answers questions about the spring osgi integration test framework used if necessary

Volodymyr Zhabiuk
Ok Thanks
Will try

Dietmar Wolz
ok
I will now start to write some real planner tests + test strategies. So I would prefer we leave the planner as separate bundle for now and reintegrate it later into the core if we decide to do so. This would mean that for the moment we delete the planner classes from the core project and introduce a dependency to the planner (can be taken from the planner test pom.xml)

Volodymyr Zhabiuk
Can not build the org.eclipse.swordfish.core.planner project. Some dependencies are missing
----------
1) org.eclipse:org.eclipse.osgi.services:jar:3.1.2

2) org.eclipse:org.eclipse.osgi.util:jar:3.1.3

3) org.eclipse:org.eclipse.osgi:jar:3.4.2

4) org.eclipse.equinox:org.eclipse.equinox.cm:jar:1.0.0

5) javax.xml.bind:com.springsource.javax.xml.bind:jar:2.1.7

6) javax.xml.stream:com.springsource.javax.xml.stream:jar:1.0.1

Dietmar Wolz
As I said, you need to deploy these by hand locally. You may use repository.zip in my exchange

Volodymyr Zhabiuk
As an ordinary developer that wants to try out the new open source project, I would be completely screwed up if somebody proposed me to install some maven artifacts manually in order to build that project
Some of the dependencies listed above can be downloaded from public repositories

Dietmar Wolz
Volodymyr, you are right, at least we should host the needed libraries ourselve if there is no other public maven repo. But for now we have to install it locally, next we will have our shared swordfish repo, finally everything should be publicly avaliable.

Andrey Kopachevsky
so we'll host 3rd party jars in our repository?

Volodymyr Zhabiuk
Should I try to find that jars or at least alternatives from the public repositories not listed in the  maven settings.xml file?

Oliver Wolf
@andrey: we'll have to, because we need to get approval for any 3rd partie libs from eclipse legal
@volodymyr: we're going to set up our own maven repo on the eclipse download site and have our poms point to that. it's a pain, i know

[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.
 

------ Weitergeleitete Nachricht
Von: Oliver Wolf <oliver.wolf@xxxxxxxxx>
Antworten an: Swordfish Developer Discussions <swordfish-dev@xxxxxxxxxxx>
Datum: Mon, 27 Oct 2008 18:07:12 +0100
An: Swordfish Developer Discussions <swordfish-dev@xxxxxxxxxxx>
Betreff: [swordfish-dev] Chat transcript 27/10/2008

[START Transcript 23/10/2008]

Volodymyr Zhabiuk
Good afternoon
I have integrated the planner routing functionality with the nmr
Endpoints are sorted according to the "priority" property
<osgi:service ref="endpointResolverInterceptor">
 <osgi:interfaces><value>org.eclipse.swordfish.api.Interceptor</value></osgi:interfaces>
 <osgi:service-properties>  
     <entry key="priority" value="2"/>  
   </osgi:service-properties>
 </osgi:service>
This property can also be supplied by implementing  method Interceptor.getProperties()
The basic scenarion with the cxfEndpoint invocation have passed

Dietmar Wolz
Hi Volodymyr, did you check in the sources? I am currently adapting the planner code to the new structure. This weekend I succeeded in getting first integration tests running, and hope to be able to reproduce this result using the refactored planner soon

Volodymyr Zhabiuk
yes
All changes have been commited

Dietmar Wolz
in order to factor  out the API from the planner I need to install the api project. I tried to run maven and got 
[INFO] ------------------------------------------------------------------------
[INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.eclipse.swordfish:parent for project: org.eclipse.swordfish:org.eclipse.swordfish.api:bundle:${swordfishVersion} for project org.eclipse.swordfish:org.eclipse.swordfish.api:bundle:${swordfishVersion}
what can I do?

Volodymyr Zhabiuk
you should have the  org.eclipse.swordfish:parent pom.xml in your local maven repository

Dietmar Wolz
thanks, is the parent pom checked in somewhere?

Volodymyr Zhabiuk
the best solution is to checkout the whole trunk directory, and maintain the hierarchical project structure
it's in the trunk dir

Dietmar Wolz
ok, will try
Andreas, are you here? Oliver wants to publish our API classes and there are javadocs missing. Perhaps you can do that? I need some more time for the testing stuff

Andreas Mattes
I think I'll be able to do that.

Dietmar Wolz
I hope I can finish a first version of the integration test sample for the planner and will check it in later today. We should add something similar for the interceptor executor stuff

Volodymyr Zhabiuk
Could you clarify your last statement?

Dietmar Wolz
I adapted some stuff from the spring-osgi-intergration test framework similar as done by guillome in smx4 kernel (not core)

Andrey Kopachevsky
I'm currently integrating error listener

Dietmar Wolz
I will provide a sample for an osgi integration test which builds an osgi bundle set on the fly and performs some test on the deployed services. Its meant as a blueprint for other integration tests

Volodymyr Zhabiuk
Sounds great

Dietmar Wolz
Unfortunately it wasn't easy to remove all obstacles and it is highly dependent on maven
but it enables integration tests both from maven and from the IDE which peform identically
will tell more details after the integrated version is checked in

Volodymyr Zhabiuk
ok

Dietmar Wolz
Andreas, Oliver is not here but I expect he would be happy if you could provide an estimation when the javadocs could be ready

Volodymyr Zhabiuk
I have a question about the Exception handling
Why does the method " public void process(MessageExchange exchange)" throw SwordfishException?
In the Interceptor interface
I guess it wouldl be more natural, if the interceptor threw Exception
Or the swordfishException itself may be derived from the RuntimeException
In the present situation, each time you implement the interceptor, you need to take care of converting some specific exceptions, that might be thrown, to the SwordfishException

Dietmar Wolz
For me the discussion related to SwordfishException is still open. In smx4 we have public class ServiceMixException extends RuntimeException. We probably have to wait for Andreas and Oliver to post their opinion
some issues related to the top level pom: 
a) I would prefer the use of properties similar to the current (unfinished) planner pom.xml. Of course the properties there should move to the master pom.
b) I have concerns about the spring version - it should be 2.5.5 instead of 2.5. Please check if anyone has objections related to the versions in the planner pom, 
because these versions have proven to work with the osgi integration tests

[END]
-- 
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.
 


------ Ende der weitergeleiteten Nachricht

Attachment: ATT00001.c
Description: ATT00001.c