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

[Oliver Wolf <oliver.wolf@xxxxxxxxx>]

Title: Chat transcript 10/02/2009

[START Transcript 10/02/2009]

Jürgen Kindler
Hi Andrey... currently we have a root project that is depending on the sub projects that deliver Swordfish functionality only (and - a bit surprising to me - also on core.test.util).
I would suggest to have one maven container project that depends on the *.test projects, because
- we can do a mvn eclipse:eclipse for that project and easily import the test projects in Eclipse
- building this test wrapper project automatically builds the tests and can also execute them.
Ideallly we would have a project that then wraps our current root project and the test wrapper project so people who do want to build everything just build this new one and thus implicidly build the product and the tests. But it would still be possible to build product and tests separately ...
This structure will make it much easier for new comers to get an overview and do a first build without fully understanding the project.
I would also propose to separate the examples from the main product project. So in the end the structure would look like this:
AllProjects
- > Core
- > Examples -> Core
- > Tests - > Core

Andrey Kopachevsky
hi Jurgen, what does it mean "Core" 
- > Examples -> Core?

Jürgen Kindler
Hi Andrey. Oliver structured my project yesterday in Eclipse and cor contains api, core, configuration, event, planner, tracking and util

Andrey Kopachevsky
yes but what do you mean by Core in case of Test and Examples wrapper projects?

Jürgen Kindler
These maven projects simply contain a pom that describes their dependencies. So their are basically containers or wrappers...
And they also logically group (and thus document) the dependencies on higher level.

Andrey Kopachevsky
yes, it also calls master pom

Jürgen Kindler
You can find that idea in "Better builds with Maven" which should be available as pdf ...
Well, my understanding of the master pom is that this is the Maven internal POM that is the root of all POMs we would write. (Not sure if that is 100% right).

Andrey Kopachevsky
maybe you right, well I don't have objections about structure you proposed

Jürgen Kindler
Ok, thanks for testing & questioning my ideas 
I will talk to Oliver or Dietmar and check with them as well. I would not be able to check in myself.

Andrey Kopachevsky
so for org.eclipse.swordfish.samples you'll just move this project folder on one level up, yes?
I mean it is already wrapper-project

Jürgen Kindler
OK, I will have a closer look - but if it's already there I guess it can remain where it is ... When I did such stuff we always had directories for projects side by side and not nested, because we did not want to materialize dependencies in the directory structure.
OK, I see what your point is about the examples. From my perspective we could as well leave them as they are or move the ones inside to the top level directory.
In Eclipse they would be side by side on top level anyway ...
But this is not a decision we have to take now.

Andrey Kopachevsky
ok

Jürgen Kindler
I am simply to lazy to build each test project manually and create the Eclipse projects manually - that's what the new projects would do for me, because of the dependencies defined in there  
... and the "How to Build" documentation for Swordfish would also be much simpler 

Andrey Kopachevsky
yes, you absolutely right, we decided to make wrapper project for integration test projects when Dietmar and Oliver was here

Jürgen Kindler
So if it's OK from your side I will take care about this after checking with Oliver or Dietmar ...

Andrey Kopachevsky
yes, we with Volodimir love hierarchical structure))
Vova, I'm I right?

Jürgen Kindler
Is that for historical reasons or a cultural thingy ?  

Andrey Kopachevsky
this is  common maven-style project approach

Jürgen Kindler
I see ... 

Andrey Kopachevsky
and from my experiense, it just more easy to navigate throght this style structure and build separate parts of project

Jürgen Kindler
That's true... however I try to define hierachies on the pom level and keep the directories flat, because sometimes there are more hierachies. I've run into problems there already, because I had to decide which hierarchy was the most important one ... It's a similiar decision like with Inheritence vs. composition.

Andrey Kopachevsky
ok)

Jürgen Kindler
For now I will make small changes only - adding projects. Fortunately we use SVN so moving directories is something that can still be done later ...
Andrey? Can you give me a hint about execution of the integration tests? How do I have to start them?
Oops

Andrey Kopachevsky
noprob

Sergey Dneprovskiy
Zsolt, before starting with any tasks related Service Registry component it is necessary to have clear picture how it will look like.
As I understand you and Andreas have some vision regarding new SR, could you please share this information?
That would help also to proceed with tasks I think...

Zsolt Beothy-Elo
The vision is very simple: Build the simplest registry possible, where you can lookup for a given portType name the endpoints of all providers that implement the portType interface.
Ijust post the the feature descriptio here. I did have the time until now to put it to the wiki:
Feature
Make a remote lookup from the Swordfish Registry interceptor to a remote registry. The interceptor issues a HTTP request specifying the port type the provider must implement. The response of the registry is the list of all provider endpoints implementing the service. The concrete send in the resposne has still to be decided, e.g. WS-Adressing header, WSDL.
Limitations
- There is no authentication necessary to do the lookup nor is HTTPS supported.
- The registry backend might be in the simplest case the file system.
- The registry will only be able to handle SDX & SPDX, no general WSDL files 
Out of Scope
- It is not the scope of the feature how the artefacts are registered in the registry
Non functional aspects
For the current sprint it is assumed that a maximum of 20 - 25 services are registerd in the registry
This should make it clear what is meant by simplest.
For the first sprint we will base the registry on the file system, we will only accept SDX and SPDX as known from SOPERA ASF, we will just ignore policies,and we assume that we can hold the whole registry data in memory.

[END]

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


-- 

Oliver Wolf
SOPERA GmbH