[swordfish-dev] Chat transcript 5/11/2008

[Oliver Wolf <oliver.wolf@xxxxxxxxx>]

Title: Chat transcript 5/11/2008

[START Transcript 5/11/2008]

Volodymyr Zhabiuk
Good morning Gentlemen
There is a problem with the configuration
Equinox allows to store only simple types or collections of simple types within the configuration dictionary
private static void validateValue(Object value) {
 Class clazz = value.getClass();

 // Is it in the set of simple types 
 if (simples.contains(clazz))
  return;

 // Is it an array of primitives or simples
 if (simpleArrays.contains(clazz) || primitiveArrays.contains(clazz))
  return;

 // Is it a vector of simples
 if (clazz == Vector.class) {
  Vector valueVector = (Vector) value;
  for (Iterator it = valueVector.iterator(); it.hasNext();) {
   Class containedClazz = it.next().getClass();
   if (!simples.contains(containedClazz)) {
    throw new IllegalArgumentException(containedClazz.getName() + " in " + Vector.class.getName()); //$NON-NLS-1$
   }
  }
  return;
 }
 throw new IllegalArgumentException(clazz.getName());
}
I've noticed this problem when trying to switch the EndpointResolverInterceptor to the new configuration api
The EndpointResolverInterceptor now uses the new configuration api

Dietmar Wolz
Hallo; perhaps one of you can answer my questions: 
a) Which of the remaining refactorings proposed on monday are done and checked in
b) Are there build problems with the actual version?
c) Does the planner integration test still work and are there new integration tests?
d) Are we using the same versions of imported projects (e.g. 2.5.5 for spring), can we agree on the versions in the master pom and are we referring to them in the project poms?

Volodymyr Zhabiuk
None of them
1), 2),3) will do today
5) we need to discuss
6) We will start implementing tomorrow

Dietmar Wolz
I would like to run at least the planner integration test successfully today including all proposed refactorings

Andrey Kopachevsky
I'll make working dietmar refactoring with our osig test lunck, the least thins to do is to move core.api package in core project, and remove getType method from interceptor
Volodimir took this task because he finded better solution for getType technique
I'm now trying to make integration test after refactoring

Dietmar Wolz
Please tell me when I can checkout the new version including the remaining refactorings. The reason for the integration test is to see whether a refactoring did break anything which then has to be fixed. I think it is importent, that a) the integration tests run on all our machines and b) we all use the integration test to verify our refactorings, agreed?

Andrey Kopachevsky
ok, we'll finish with this today

Volodymyr Zhabiuk
agreed

Oliver Wolf
ok, than we'll talk again tomorrow 15:00. It would be great if all the refatorings were done by then and you get the integration test running again. If you run into any problem with the testing stuff, don't hesitate to raise it on the chat.... we'll try to help

Volodymyr Zhabiuk
@Dietmar: regarding package exports, Why do you export <Export-Package>org.eclipse.swordfish.core.api,org.eclipse.swordfish.api,org.eclipse.swordfish.core.planner</Export-Package>       from the core.planner project?

Dietmar Wolz
Feel free to restrict the export as long as the test works. I would prefer explicit exports, but they should be minimal. imports can be handled by the maven plugin. It would be nice to drop org.eclipse.swordfish.core.planner from the export, I tried but didn't get the integration test running without.

Volodymyr Zhabiuk
org.eclipse.swordfish.core.api,org.eclipse.swordfish.api packages belong to other bundles hence  should not be included in the export statement
@Dietmar: There is a problem with planner.test the class org.springframework.osgi.test.LocalMavenRepositoryLocator can not be found in the spring-osgi-test 1.1.2 jar
I can not build this project after refactorings
1), 2) are done
3) is not needed
We have a cyclic dependency problem: the swordfish.core depends on the core.planner and vica versa

Dietmar Wolz
as stated before, I added this class to spring to fix the problem that it used local bundles and not only the ones in the local maven repo. you find the fix in my exchange, repository.zip contains the fixed spring test framework. Will check in the fix into our local svn soon

Volodymyr Zhabiuk
So you patched the spring jar file?

Dietmar Wolz
referring to cyclic dep: perhaps we move the core.api files to the planner?
I called a mvn install on the sources, no file was changed, but one class was added
I couldn't add the class in our package because it needed to be located in the spring test package

Volodymyr Zhabiuk
Ok will move core.api files to the planner

Dietmar Wolz
spring-osgi-1.1.2 patched.zip contains the additional class
u could unpack it and call mvn install

Volodymyr Zhabiuk
Honestly, I don't like such approach

Oliver Wolf
what's the alternative when you find an issue in open source software and need it to be fixed?

Volodymyr Zhabiuk
We should use only  frameworks that are mature enough. Obviously spring-osgi-test does not belong to that kind
I had concerns that bundles are taken from the maven repo but not from the target platform
Anyway tomorrow I will write one more osgi integration test for the configuration implementation, and maybe I will explore some other alternatives
Addressed the cyclic dependency problem
In general 
1), 2) are done. 
3) is not needed. 
Andrey works on 4). 
5) is not needed. 
6) Will do tomorrow

Andrey Kopachevsky
@dietmar I need your exmplanation about this patched spring-osgi
so it basically patched maven project that we need to build spring-osgi-core.jar yes?

Dietmar Wolz
@Volodymyr: feel free to propose an alternative osgi integration test technique which works both from the IDE (debugging) and maven (nightly test). These are our requirements and we need a solution now - and not when everyone agrees about the "maturity" of the used framework - whatever this means exactly. A Tycho / PDE-build based solution could be an alternative but I didn't see much enthusiasm about its "maturity" either.
@Andrei: exactly

Volodymyr Zhabiuk
Ok. Thanks

Oliver Wolf
hm.... i see a conflict here. on one hand you guys preferred a fully maven-based approach but on the other hand you have reservation against taking bundles from a maven repo for integration tests. how does that go together?

Volodymyr Zhabiuk
taking bundles from a maven repo is ok as long as they can be downloaded from the public maven repos
As for now this is impossible

Oliver Wolf
but we can easily substitute the public repos with our own one hosted on the eclipse download site that contains the things that are not available from the public repos. then anyone can download the source and build it, taking the some of the dependencies from public maven repos and some from ours

Dietmar Wolz
@Andrei: the patched jar is spring-osgi-test-1.1.2.jar

Oliver Wolf
i agree that this is not the perfect solution, but as long as most of the eclipse artifacts are not available in public repos, it's probably the way to go

Andrey Kopachevsky
@dietma yes I understup I've executed mvn install

Oliver Wolf
hopefully, at some point eclipse will have their own maven repo... p2 will be able to pick up bundles from there

Andrey Kopachevsky
I think more important point not in IDE or maven build, more important that we execute integration test not against targetPlaftrom bunles and it basically completelly different environment
For example in the planner.test we have com.springsource.javax.xml.stream-1xx.jar bundle in dependency, ant don't have such in target platrom yet.

Volodymyr Zhabiuk
@Oliver. This would be great and it will definitely solve the problem. We would be able to compose the whole target platform by one maven command
But as far as I understand It will take a lot of time to settle licensing issues.

Oliver Wolf
ok, so for the time being we'll use our own maven repo and build the target platform from there and switch to eclipse when an official eclipse repo becomes available

Volodymyr Zhabiuk
And all this time to conduct integration testing we would need to copy files to maven repo manually

Oliver Wolf
yes, licenses are an issue, but we're under parallel ip, so we can proceed and check in or upload 3rd party stuff in parallel to the ip compliance process being worked on

Volodymyr Zhabiuk
Could you clarify the last statement? what is the parallel ip?
BTW I've just looked at the spring-osgi-test implementation and it seems to be rather easy to load bundles from the target platform the following method is needed to be overriden
protected Resource[] getTestBundles()
This method may return the fileSystemResources
in this case we don't have any problems with the artifactLocator

Oliver Wolf
@volodymyr: re: parallel ip: parallel ip is a streamlined version of the eclipse ip compliance process. all projects under incubation are eligible for parallel ip, whioch basically means, that you can start using 3rd party libs after you get a preliminary clearance and don't have to wait for the full ip compliance process to be completed
regarding your alternative solution to loading bundles: yes, i think that would work and it's a good idea, actually. the inly issue i see here is that ideally the target platform is a result of the build, not a prerequisite. if you consider someone who just checks out the source and wants to build the bundles, this someone probably doesn't have a target platform, but mave ncan easily retrieve the bundles from maven repos, both public and swordfish-specific. and for headless maven-based builds you typically also don't have a target platform

Andrey Kopachevsky
@dietmar: I'm trying to run PlannerITest, it not fails but not executed, have you seen such exception befure?
java.lang.IllegalStateException: Unable to load dependencies informations
at org.eclipse.swordfish.core.planner.test.PlannerITest.getBundleVersion(PlannerITest.java:120)
at org.eclipse.swordfish.core.planner.test.PlannerITest.getBundle(PlannerITest.java:107)
at org.eclipse.swordfish.core.planner.test.PlannerITest.getTestBundlesNames(PlannerITest.java:161)
at org.springframework.osgi.test.AbstractDependencyManagerTests.getTestBundles(AbstractDependencyManagerTests.java:224)
at org.springframework.osgi.test.AbstractOsgiTests.locateBundles(AbstractOsgiTests.java:271)
at org.springframework.osgi.test.AbstractOsgiTests.startup(AbstractOsgiTests.java:249)
at org.springframework.osgi.test.AbstractOsgiTests.prepareTestExecution(AbstractOsgiTests.java:374)
at org.springframework.osgi.test.AbstractOsgiTests.runBare(AbstractOsgiTests.java:203)
at org.springframework.osgi.test.AbstractOsgiTests$1.protect(AbstractOsgiTests.java:184)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at org.springframework.osgi.test.AbstractOsgiTests.run(AbstractOsgiTests.java:181)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: java.io.FileNotFoundException: target\classes\META-INF\maven\dependencies.properties (Could not finde path specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at org.eclipse.swordfish.core.planner.test.PlannerITest.getBundleVersion(PlannerITest.java:117)
... 19 more

Volodymyr Zhabiuk
Fully agree
Even now we may use the Archiva tool to setup the maven repository for the Swordfish specific libraries
And to build the target platform by downloading bundles from this repository

Oliver Wolf
exactly
so it makes sense to pull the bundles from the maven repo for integration testing

Volodymyr Zhabiuk
Ok. Agree
We need to set up the swordfish maven repo as soon as possible
Besides it seems com.springsource dependencies can be downloaded from the public maven repo(Investigated by Andrey)
The only problem is the eclipse jars

Dietmar Wolz
Sorry Andrey, forgot to warn you. Guiliome build a maven plugin generating dependency information used by the test to derive the versions of the derived bundle
just run maven install a second time

Andrey Kopachevsky
ok, one sec
you mean maven install on planner.test? hasn't helped so far
one more point, are you running tests using maven or eclipse ide?

Dietmar Wolz
both, should both work. Caused by: java.io.FileNotFoundException: target\classes\META-INF\maven\dependencies.properties (Could not finde path specified)
check if the file is generated by maven

Andrey Kopachevsky
yes it starts works!
great
everything green?

Andrey Kopachevsky
no)
but I se reasonable error messages, about missing constraints
so it can be figured out

Dietmar Wolz
hope so, may be the poms need to be adapted to fulfill all imports

Andrey Kopachevsky
org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: Import-Package: org.apache.servicemix.nmr.api; version="0.0.0"
ok, check this tomorow
I'll check

Dietmar Wolz
the version from monday had no dependency to smx core, only to smx jbi. So its clear that the import is missing, but unclear why there is this dependency now

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