On Mon, Oct 6, 2008 at 9:02 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED] > wrote:
> ant elder wrote: > >> >> >> On Wed, Oct 1, 2008 at 6:21 AM, Jean-Sebastien Delfino < >> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: >> >> ant elder wrote: >> >> >> >> On Mon, Sep 29, 2008 at 5:01 PM, Jean-Sebastien Delfino >> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> >> wrote: >> >> ant elder wrote: >> >> >> >> On Thu, Sep 11, 2008 at 5:37 PM, Jean-Sebastien Delfino >> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> >> <mailto:[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>>>> wrote: >> >> <snip> >> >> >> I'll create a branch to make progress on this Equinox >> porting >> effort >> without breaking everybody else. As I said before >> it'll probably >> take a few weeks to get most Tuscany samples and >> itests up and >> running, but I'd like to try to have a few core itests >> and >> maybe a >> Web Service or two working in the next few days. >> >> >> >> Its been a few weeks now, what are the plans and time >> frames for >> merging this branch back into the mainstream trunk? >> >> ...ant >> >> >> Still making progress on the Equinox bringup, going slowly as >> I'm >> busy at work. Getting the whole runtime really working end to >> end in >> Equinox is going to require changes in many different places >> in the >> code, so don't expect miracles it's going to take time. Some >> of the >> changes may be possible to merge to trunk already if people >> want to >> help with that. >> >> -- Jean-Sebastien >> >> >> The problem with helping is that its difficult to work out what >> are the changes. I've done a diff of the sca-equinox branch to >> the trunk which is at: >> >> http://people.apache.org/~antelder/temp/sca-equinox.diff<http://people.apache.org/%7Eantelder/temp/sca-equinox.diff> >> <http://people.apache.org/%7Eantelder/temp/sca-equinox.diff>. >> >> Its huge, and lots of the changes seem quite unrelated to OSGi >> class loading. Some changes from trunk get merged to the branch, >> some don't, others get modified and then merged, there's also >> what looks like new development not directly related to >> OSGi/Equinox that goes into the branch but not trunk. If this >> branch is to show what changes are needed for Equinox then >> wouldn't it be clearer if the only changes in the branch were >> directly related to Equinox? With the diff so huge now how can >> this ever get merged to trunk? >> >> ...ant >> >> >> I've always had trouble too working off flat diffs like that. >> Merging / porting individual commits from the history should be >> easier. That's what I've been doing to pull some changes from trunk, >> and it's really easy once you've done it a few times and have >> defined your merge processes with the Svn, diff, patch tools etc. If >> you're interested in trying it, for more complicated cases (like >> when I started to create the android branch) I've also found Git >> very powerful at handling merges. Working off the history should >> also help you pick only the changes that are not going to break the >> trunk at this point, or pick them in a more convenient sequence for >> example. >> >> If that helps I could try to document the steps that I've been >> following for various merge cases but I'm busy these days so it'll >> probably take some time before I get to it. >> >> If people want to help, at the moment I'm seeing issues with many >> 'dirty' cross module dependencies (tapping directly into impl >> classes instead of going through the SPI. >> >> An example is dependencies on o.a.t.sca.contribution.impl, causing >> this: >> >> warning: Unresolved resource >> META-INF/services/org.apache.tuscany.sca.node.SCANodeFactory found >> in 15 org.apache.tuscany.sca.node.impl INSTALLED >> severe: SCA Node could not be created >> java.lang.reflect.InvocationTargetException >> at >> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> at >> >> >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >> at >> >> >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >> at >> java.lang.reflect.Constructor.newInstance(Constructor.java:513) >> at >> >> >> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:155) >> at >> >> >> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.createNode(NodeLauncher.java:83) >> at >> calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:44) >> at junit.framework.TestCase.runBare(TestCase.java:132) >> at junit.framework.TestResult$1.protect(TestResult.java:110) >> at junit.framework.TestResult.runProtected(TestResult.java:128) >> at junit.framework.TestResult.run(TestResult.java:113) >> at junit.framework.TestCase.run(TestCase.java:124) >> at junit.framework.TestSuite.runTest(TestSuite.java:232) >> at junit.framework.TestSuite.run(TestSuite.java:227) >> at >> >> >> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) >> at >> >> >> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) >> at >> >> >> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) >> at >> >> >> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) >> at org.apache.maven.surefire.Surefire.run(Surefire.java:132) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> >> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> at >> >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at >> >> >> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) >> at >> >> >> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) >> Caused by: org.osoa.sca.ServiceRuntimeException: >> java.lang.reflect.InvocationTargetException >> at >> >> >> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:146) >> at >> >> >> org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:116) >> ... 25 more >> Caused by: java.lang.reflect.InvocationTargetException >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> >> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> at >> >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at >> >> >> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:128) >> ... 26 more >> Caused by: java.lang.IllegalStateException: >> org.osgi.framework.BundleException: The bundle could not be >> resolved. Reason: Missing Constraint: Import-Package: >> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0" >> at >> >> >> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:227) >> at >> >> >> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getFirstServiceDeclaration(EquinoxServiceDiscoverer.java:191) >> at >> >> >> org.apache.tuscany.sca.extensibility.ServiceDiscovery.getFirstServiceDeclaration(ServiceDiscovery.java:83) >> ... 31 more >> Caused by: org.osgi.framework.BundleException: The bundle could not >> be resolved. Reason: Missing Constraint: Import-Package: >> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0" >> at >> >> >> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) >> at >> >> >> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) >> at >> >> >> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252) >> at >> >> >> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:225) >> ... 33 more >> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: >> 4.213 sec <<< FAILURE! >> testDummy(calculator.CalculatorTestCase) Time elapsed: 4.153 sec >> <<< ERROR! >> org.apache.tuscany.sca.node.equinox.launcher.LauncherException: >> java.lang.reflect.InvocationTargetException >> at >> >> >> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:174) >> at >> >> >> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.createNode(NodeLauncher.java:83) >> at >> calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:44) >> at junit.framework.TestCase.runBare(TestCase.java:132) >> at junit.framework.TestResult$1.protect(TestResult.java:110) >> at junit.framework.TestResult.runProtected(TestResult.java:128) >> at junit.framework.TestResult.run(TestResult.java:113) >> at junit.framework.TestCase.run(TestCase.java:124) >> at junit.framework.TestSuite.runTest(TestSuite.java:232) >> at junit.framework.TestSuite.run(TestSuite.java:227) >> at >> >> >> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) >> at >> >> >> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) >> at >> >> >> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) >> at >> >> >> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) >> at org.apache.maven.surefire.Surefire.run(Surefire.java:132) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> >> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> at >> >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at >> >> >> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) >> at >> >> >> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) >> Caused by: java.lang.reflect.InvocationTargetException >> at >> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> at >> >> >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >> at >> >> >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >> at >> java.lang.reflect.Constructor.newInstance(Constructor.java:513) >> at >> >> >> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:155) >> ... 20 more >> Caused by: org.osoa.sca.ServiceRuntimeException: >> java.lang.reflect.InvocationTargetException >> at >> >> >> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:146) >> at >> >> >> org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:116) >> ... 25 more >> Caused by: java.lang.reflect.InvocationTargetException >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> >> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> at >> >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at >> >> >> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:128) >> ... 26 more >> Caused by: java.lang.IllegalStateException: >> org.osgi.framework.BundleException: The bundle could not be >> resolved. Reason: Missing Constraint: Import-Package: >> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0" >> at >> >> >> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:227) >> at >> >> >> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getFirstServiceDeclaration(EquinoxServiceDiscoverer.java:191) >> at >> >> >> org.apache.tuscany.sca.extensibility.ServiceDiscovery.getFirstServiceDeclaration(ServiceDiscovery.java:83) >> ... 31 more >> Caused by: org.osgi.framework.BundleException: The bundle could not >> be resolved. Reason: Missing Constraint: Import-Package: >> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0" >> at >> >> >> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) >> at >> >> >> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) >> at >> >> >> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252) >> at >> >> >> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:225) >> ... 33 more >> >> >> I'm starting to fix node-impl to only reference SPIs but I've not >> been able to find what's causing the above exception, given that the >> unresolved contribution.impl package is exported+imported right now >> (as a workaround, but the workaround doesn't seem to work). >> >> So if anybody has ideas about that exception, please let me know... >> >> Thanks >> -- Jean-Sebastien >> >> >> >> So this branch is really a fork isn't it? >> >> ...ant >> >> > Is that a question or a statement? I don't really understand how you come > up to that conclusion. > > It's not a fork, it's a branch to work through breaking changes (and pretty > complex changes I must say) which should allow our runtime to correctly work > as a set of modular bundles in an Equinox/OSGi environment. > > I'm hoping that this work can somehow benefit Tuscany, by providing code, > patterns or maybe just a set of techniques that the project can implement to > work in Equinox/OSGi. It'll be up to the Tuscany community to take a look > and decide what can be reused or if it's just something to study and learn > from. > > At the moment that Equinox port is still pretty broken, I've made changes > to start to clean up the dependencies on assembly.builder.impl and > contribution.service.impl for example, but there are many other similar > cross-bundle dependencies on implementation packages which will take time to > clean up. > > -- > Jean-Sebastien > I guess what i'm still not understanding is why can't the most of this happen in trunk? For example - "clean up the dependencies on assembly.builder.impl and contribution.service.impl for example, but there are many other similar cross-bundle dependencies on implementation packages" - all of that is applicable to the trunk code and has no dependencies on the OSGi changes so why not just do it from the start in trunk? ...ant
