On Fri, Nov 21, 2008 at 9:35 AM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > I saw the same issue with org.w3c.dom.traversal package too. This package is > not exported by the system bundle (while org.w3c.dom is). > > I also looked into the code. It was introduced as part of the "Any Element" > processor to write the DOM into an XMLStreamWriter. Can we use a different > algorithm to avoid this dependency? >
This is probably the first version of the processor that was still using DOM. We can try to move to the new version and avoid this issue. > Thanks, > Raymond > > > From: Simon Laws > Sent: Friday, November 21, 2008 8:10 AM > To: [email protected] > Subject: Re: 2.0 trunk modules status update > > > > > > On Fri, Nov 21, 2008 at 2:47 PM, Simon Laws <[EMAIL PROTECTED]> > wrote: > > > > > On Fri, Nov 21, 2008 at 2:08 PM, Simon Laws <[EMAIL PROTECTED]> > wrote: > > > > > On Fri, Nov 21, 2008 at 1:42 PM, Simon Laws <[EMAIL PROTECTED]> > wrote: > > > > > On Fri, Nov 21, 2008 at 1:08 PM, Simon Laws <[EMAIL PROTECTED]> > wrote: > > > > > On Fri, Nov 21, 2008 at 10:29 AM, Luciano Resende <[EMAIL PROTECTED]> > wrote: > > Here is a patch that uses the geronimo stax dependency, and reduced > the number of errors related to the stax-api dependency. > I'm still trying to figure out why assembly-xml have no reference to > the stax dependency. > > > > On Fri, Nov 21, 2008 at 1:51 AM, Simon Laws <[EMAIL PROTECTED]> > wrote: >> >> >> On Fri, Nov 21, 2008 at 9:42 AM, Luciano Resende <[EMAIL PROTECTED]> >> wrote: >>> >>> Good point, the difference is that in the equinox branch, although we >>> are defining the stax-api:1.0-2 in the pom, the dependency being >>> picked up in plug-in dependencies is the >>> geronimo-stax-api_1.0_spec-1.0.1.jar. Maybe we could experiment with >>> these two different dependencies and see if they make any difference. >>> >>> On Fri, Nov 21, 2008 at 1:26 AM, Simon Laws <[EMAIL PROTECTED]> >>> wrote: >>> > >>> > >>> > On Fri, Nov 21, 2008 at 9:22 AM, Luciano Resende <[EMAIL PROTECTED]> >>> > wrote: >>> >> >>> >> On Thu, Nov 20, 2008 at 10:23 PM, Raymond Feng <[EMAIL PROTECTED]> >>> >> wrote: >>> >> > Hi, >>> >> > >>> >> > I can now get JDK 1.6 working with the PDE projects. I'm still >> > >>> >> > seeing >>> >> > the >>> >> > unresolved javax.xml.stream issues with JDK 5 even though the >> > >>> >> > equinox >>> >> > console shows all the bundles can be resolved. >>> >> > >>> >> >>> >> I'm seeing the issue in JDK 1.5, and was wondering if this could be >>> >> related to the stax-api-1.0-2 which version is 1.0-2, but is being >>> >> listed as 1.0.0 in the pdetarget. I tried to fix that in the manifest, >>> >> but eclipse was complaining that "dash" wasn't a valid character. >>> >> Well, this is just a guess, I'll try to look into this a little more >>> >> in the morning. >>> >> >>> >> > I also added the option to create a launchable equinox >> > >>> >> > configuration. >>> >> > You >>> >> > can now start the equinox console as follows: >>> >> > >>> >> > C:\Tuscany\java\sca\distribution\pdetarget\target\modules> >>> >> > "c:\Program >>> >> > Files\IBM\Java50\bin\java.exe" -jar >> > osgi-3.3.0-v20070530.jar >>> >> > -console >>> >> > -clean >>> >> > >>> >> > Thanks, >>> >> > Raymond >>> >> > >>> >> > >>> >> > From: Simon Laws >>> >> > Sent: Thursday, November 20, 2008 7:35 AM >>> >> > To: [email protected] ; [EMAIL PROTECTED] >>> >> > Subject: Re: 2.0 trunk modules status update >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > On Thu, Nov 20, 2008 at 3:30 PM, ant elder <[EMAIL PROTECTED]> >>> >> > wrote: >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > On Thu, Nov 20, 2008 at 2:30 PM, Simon Laws >>> >> > <[EMAIL PROTECTED]> >>> >> > wrote: >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > On Thu, Nov 20, 2008 at 7:22 AM, Raymond Feng <[EMAIL PROTECTED]> >>> >> > wrote: >>> >> > >>> >> > Hi, >>> >> > >>> >> > I spent a few hours trying to get the Eclipse PDE integration >>> >> > working. >>> >> > But I >>> >> > ran into a strange issue that doesn't exist in the sca-equinox >>> >> > branch: >>> >> > The >>> >> > org.eclipse.osgi plugin cannot be selected for the target platform, >>> >> > otherwise javax.xml.stream Import-Package cannot be resolved. I will >>> >> > have to >>> >> > continue tomorrow. >>> >> > >>> >> > I suggest that we try to get more modules built and loaded into >>> >> > Eclipse >>> >> > PDE >>> >> > following the steps below. >>> >> > >>> >> > 1) Build maven-eclipse-compiler first >>> >> > cd tools/maven/maven-eclipse-compiler >>> >> > mvn clean install >>> >> > >>> >> > 2) Build the modules >>> >> > cd modules >>> >> > mvn clean install -Dmaven.test.skip=true >>> >> > mvn -Peclipse >>> >> > >>> >> > 3) Build the PDE target >>> >> > cd distribution >>> >> > mvn clean install >>> >> > cd pdetarget >>> >> > mvn -Peclipse >>> >> > >>> >> > 4) Import distribution/pdetarget >>> >> > Launch your Eclipse IDE, select File->Import->Existing projects into >>> >> > Workplace, and then import the "PDE Target" project (from >>> >> > distribution/pdetarget) into your Eclipse Workspace. >>> >> > Inside eclipse, open tuscany-distribution-pdetarget project >>> >> > open target/tuscany-distribution-pdetarget.target >>> >> > click "Set as target platform" on the upper-right side of the >>> >> > overview >>> >> > window that opened >>> >> > You can then go to Windows --> Preferences --> Plugin Development >> >>> >> > > Env >>> >> > --> >>> >> > Target Platform to verify >>> >> > >>> >> > 5) Import modules >>> >> > Now, launch your Eclipse IDE, select File->Import->Existing projects >>> >> > into >>> >> > Workplace, and then import the project from SCA Modules into your >>> >> > Eclipse >>> >> > Workspace. >>> >> > >>> >> > >>> >> > Thanks, >>> >> > Raymond >>> >> > -------------------------------------------------- >>> >> > From: "Luciano Resende" <[EMAIL PROTECTED]> >>> >> > Sent: Wednesday, November 19, 2008 11:19 AM >>> >> > To: <[email protected]> >>> >> > Subject: Re: 2.0 trunk modules status update >>> >> > >>> >> > >>> >> > We have made good progress, this is all good news. As for what's >>> >> > next, >>> >> > I believe there are still lots of work to do to get a stable base >> >>> >> > > for >>> >> > our OASIS work, and this thread [1] give us some hints of what can >>> >> > >> > be >>> >> > our next steps. I think we still need to bring up most if not all >> >>> >> > > the >>> >> > modules as OSGi bundles, get some of the OSGi tools integrated, >> > >>> >> > start >>> >> > working on getting the tests passing, etc >>> >> > >>> >> > >>> >> > [1] http://markmail.org/message/otyegk65ebku642o >>> >> > >>> >> > On Wed, Nov 19, 2008 at 11:06 AM, Simon Laws >>> >> > <[EMAIL PROTECTED]> >>> >> > wrote: >>> >> > >>> >> > >>> >> > >>> >> > On Wed, Nov 19, 2008 at 5:15 PM, Simon Laws >>> >> > <[EMAIL PROTECTED]> >>> >> > wrote: >>> >> > >>> >> > >>> >> > >>> >> > On Wed, Nov 19, 2008 at 4:37 PM, ant elder <[EMAIL PROTECTED]> >>> >> > wrote: >>> >> > >>> >> > >>> >> > FYI, the 2.0 trunk modules build ok for me now, thats with the >>> >> > modules/pom.xml only including the reduced set for the calculator >>> >> > sample, >>> >> > and samples/calculator-equinox is workingish, gets a lot of warning >>> >> > messages >>> >> > but the calculator component does run, but only when the maven >>> >> > repository is >>> >> > not within a folder containg spaces in the name. >>> >> > >>> >> > ...ant >>> >> > >>> >> > >>> >> > Nice one ant. Let me do an update and get your changes. >>> >> > >>> >> > Simon >>> >> > >>> >> > >>> >> > Ok, so those changes work for me and I'm up and running with this >>> >> > basic >>> >> > set >>> >> > of modules. So what next? I guess it's back over to the themes >> > >>> >> > thread >>> >> > to >>> >> > hear what people want to work on, in what order, and look at how we >>> >> > get >>> >> > it >>> >> > done. >>> >> > >>> >> > Simon >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Luciano Resende >>> >> > Apache Tuscany, Apache PhotArk >>> >> > http://people.apache.org/~lresende >>> >> > http://lresende.blogspot.com/ >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > Hi >>> >> > >>> >> > So I upgraded to Ganymede, followed the steps in the previous post >>> >> > >> > to >>> >> > install the new PDE target (needed a bit of pom editing about to get >>> >> > it >>> >> > to >>> >> > work with our minimum set of modules). >>> >> > >>> >> > I installed the PDE eclipse projects (mvn -Peclipse) and got a lot >>> >> > >> > of >>> >> > errors. >>> >> > >>> >> > I reverted back to standard eclipse projects (mvn elipse:eclipse) >> >>> >> > > and >>> >> > of >>> >> > course I'm good again. >>> >> > >>> >> > I suggest we concentrate on getting the minimum set of modules just >>> >> > as >>> >> > we >>> >> > want them before pulling the kitchen sink back into the build. That >>> >> > doesn't >>> >> > mean of course that if you want to maintain other modules in you IDE >>> >> > if >>> >> > you >>> >> > feel the need >>> >> > >>> >> > On that note can we now move all of the modules that don't don't >>> >> > contribute >>> >> > to the minimum set out of the modules dir? >>> >> > >>> >> > Simon >>> >> > >>> >> > >>> >> > >>> >> > I'm doing the same, and it is working ok though i get the errors >>> >> > below >>> >> > on >>> >> > some of the manifests relating to a few dependencies. Whats the way >>> >> > to >>> >> > fix >>> >> > these? >>> >> > >>> >> > ...ant >>> >> > >>> >> > Description Resource Path Location Type >>> >> > No available bundle exports package 'commonj.work' MANIFEST.MF >>> >> > tuscany-core/META-INF line 50 Plug-in Problem >>> >> > No available bundle exports package 'net.sf.cglib.proxy' >>> >> > MANIFEST.MF >>> >> > tuscany-core/META-INF line 56 Plug-in Problem >>> >> > No available bundle exports package 'org.apache.ws.commons.schema' >>> >> > MANIFEST.MF tuscany-xsd/META-INF line 15 Plug-in Problem >>> >> > No available bundle exports package 'org.mortbay.component' >>> >> > MANIFEST.MF >>> >> > tuscany-host-jetty/META-INF line 19 Plug-in Problem >>> >> > No available bundle exports package 'org.mortbay.jetty.handler' >>> >> > MANIFEST.MF >>> >> > tuscany-host-jetty/META-INF line 21 Plug-in Problem >>> >> > No available bundle exports package 'org.mortbay.jetty.nio' >>> >> > MANIFEST.MF >>> >> > tuscany-host-jetty/META-INF line 22 Plug-in Problem >>> >> > No available bundle exports package 'org.mortbay.jetty.security' >>> >> > MANIFEST.MF >>> >> > tuscany-host-jetty/META-INF line 23 Plug-in Problem >>> >> > No available bundle exports package 'org.mortbay.resource' >>> >> > MANIFEST.MF >>> >> > tuscany-host-jetty/META-INF line 26 Plug-in Problem >>> >> > No available bundle exports package 'org.mortbay.thread' >>> >> > MANIFEST.MF >>> >> > tuscany-host-jetty/META-INF line 27 Plug-in Problem >>> >> > Unsatisfied constraint: 'Import-Package: org.mortbay.jetty; >>> >> > version="6.1.7"' >>> >> > MANIFEST.MF tuscany-host-jetty/META-INF line 20 Plug-in >>> >> > Problem >>> >> > Unsatisfied constraint: 'Import-Package: org.mortbay.jetty.servlet; >>> >> > version="6.1.7"' MANIFEST.MF tuscany-host-jetty/META-INF >>> >> > line >>> >> > 24 >>> >> > Plug-in Problem >>> >> > Unsatisfied constraint: 'Import-Package: org.mortbay.log; >>> >> > version="6.1.7"' >>> >> > MANIFEST.MF tuscany-host-jetty/META-INF line 25 Plug-in >>> >> > Problem >>> >> > >>> >> > >>> >> > >>> >> > I don't see those, I'm getting problems to do with packages that are >>> >> > in >>> >> > the >>> >> > JDK, e.g. the start of the databinding-jaxb manifest is >>> >> > >>> >> > Import-Package: javax.activation, >>> >> > javax.imageio, >>> >> > javax.xml.bind, >>> >> > >>> >> > An eclipse complains that no available bundle export javax.imageio. >>> >> > Which is >>> >> > a little odd. >>> >> > >>> >> > I wonder if it's something to do with the JDK that was used to >> > >>> >> > create >>> >> > these >>> >> > manifests. They were generated using "Created-By: 1.6.0_07 (Sun >>> >> > Microsystems >>> >> > Inc.)" I'm on IBM 1.5. Just a stab in the dark at the moment. >>> >> > >>> >> > Simon >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> Luciano Resende >>> >> Apache Tuscany, Apache PhotArk >>> >> http://people.apache.org/~lresende >>> >> http://lresende.blogspot.com/ >>> > >>> > Hi >>> > >>> > Could well be that dash. Strange that this wasn't an issue on the >>> > branch. >>> > Were you using JDK6 there? I'll prod it a little to day to see if I can >>> > get >>> > anywhere. >>> > >>> > Simon >>> > >>> >>> >>> >>> -- >>> Luciano Resende >>> Apache Tuscany, Apache PhotArk >>> http://people.apache.org/~lresende >>> http://lresende.blogspot.com/ >> >> Ok, that's useful. I can certainly give that a spin. >> >> Simon >> > > > > > -- > > Luciano Resende > Apache Tuscany, Apache PhotArk > http://people.apache.org/~lresende > http://lresende.blogspot.com/ > > > > I went with the change to geronimo-stax-api_1.0_spec-1.0.1.jar. but I get a > different set of problems now. In making this change I did a number of > cleans (starting eclipse and mvn eclipse:clean). The PDE target now does't > reference the osgi jar directly interestingly so I get a load of errors of > the form > > > Description Resource Path Location Type > > Bundle cannot be resolved EquinoxHostTestCase.java > tuscany-extensibility-equinox/src/test/java/org/apache/tuscany/sca/extensibility/equinox > line 66 Java Problem > Bundle cannot be resolved EquinoxHostTestCase.java > tuscany-extensibility-equinox/src/test/java/org/apache/tuscany/sca/extensibility/equinox > line 69 Java Problem > Bundle cannot be resolved EquinoxHostTestCase.java > tuscany-extensibility-equinox/src/test/java/org/apache/tuscany/sca/extensibility/equinox > line 72 Java Problem > Bundle cannot be resolved EquinoxHostTestCase.java > tuscany-extensibility-equinox/src/test/java/org/apache/tuscany/sca/extensibility/equinox > line 75 Java Problem > Bundle cannot be resolved EquinoxHostTestCase.java > tuscany-extensibility-equinox/src/test/java/org/apache/tuscany/sca/extensibility/equinox > line 78 Java Problem > > Looking at the generated .classpath for extensibility-exquinox you see the > following dependency > > <classpath> > <classpathentry kind="src" path="src/main/java"/> > <classpathentry kind="src" path="src/test/java" > output="target/test-classes"/> > <classpathentry kind="src" path="src/test/resources" > output="target/test-classes" excluding="**/*.java"/> > <classpathentry kind="output" path="target/classes"/> > <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> > <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/> > <classpathentry kind="var" > path="M2_REPO/org/eclipse/equinox/app/1.0.0-v20070606/app-1.0.0-v20070606.jar"/> > <classpathentry kind="var" > path="M2_REPO/org/eclipse/equinox/common/3.3.0-v20070426/common-3.3.0-v20070426.jar"/> > <classpathentry kind="var" > path="M2_REPO/org/eclipse/core/contenttype/3.2.100-v20070319/contenttype-3.2.100-v20070319.jar"/> > <classpathentry kind="var" > path="M2_REPO/org/eclipse/core/jobs/3.3.0-v20070423/jobs-3.3.0-v20070423.jar"/> > <classpathentry kind="var" path="M2_REPO/junit/junit/4.5/junit-4.5.jar"/> > <classpathentry kind="var" > path="M2_REPO/org/eclipse/equinox/preferences/3.2.100-v20070522/preferences-3.2.100-v20070522.jar"/> > <classpathentry kind="var" > path="M2_REPO/org/eclipse/equinox/registry/3.3.0-v20070522/registry-3.3.0-v20070522.jar"/> > <classpathentry kind="var" > path="M2_REPO/org/eclipse/core/runtime/3.3.100-v20070530/runtime-3.3.100-v20070530.jar"/> > </classpath> > > So it has the notion of a container dependency on > org.eclipse.pde.core.requiredPlugins which sounds like the sort of thin that > should contain the OSGi jar. But where is > org.eclipse.pde.core.requiredPlugins defined? > > Simon > > > > Another runt of the mvn -Peclipse and the OSGi dependency is back again (?) > and so are my stax problem. > > Looking at assembly-xml generated classpath is interesting. > > > <classpath> > <classpathentry kind="src" path="src/main/java"/> > > <classpathentry kind="src" path="src/main/resources" > excluding="**/*.java"/> > > <classpathentry kind="src" path="src/test/java" > output="target/test-classes"/> > <classpathentry kind="src" path="src/test/resources" > output="target/test-classes" excluding="**/*.java"/> > <classpathentry kind="output" path="target/classes"/> > <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> > <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/> > > <classpathentry kind="var" path="M2_REPO/junit/junit/4.5/junit-4.5.jar"/> > > <classpathentry kind="var" > path="M2_REPO/org/apache/tuscany/sca/tuscany-assembly-xsd/2.0-SNAPSHOT/tuscany-assembly-xsd-2.0-SNAPSHOT.jar"/> > <classpathentry kind="var" > path="M2_REPO/org/apache/tuscany/sca/tuscany-definitions-xml/2.0-SNAPSHOT/tuscany-definitions-xml-2.0-SNAPSHOT.jar"/> > <classpathentry kind="var" > path="M2_REPO/org/apache/tuscany/sca/tuscany-policy-xml/2.0-SNAPSHOT/tuscany-policy-xml-2.0-SNAPSHOT.jar"/> > <classpathentry kind="var" > path="M2_REPO/org/codehaus/woodstox/wstx-asl/3.2.4/wstx-asl-3.2.4.jar"/> > </classpath> > > A direct reference to wstx jar has been included. This is a pretend bundle > but is included in the pde target. However the geronimo-stax-api_1.0_spec-1. > 0.1.jar dependency is missing. This is apparently a real bundle, and it also > appears as enabled in the pde target. > > The assembly-xml project itself has a set of pluging dependencies listed. No > idea how it determins what these are (I'd guess based on imports/exports) > but it obvioudly doesn't include the geronimo dependency. Also interesting > that it includes tuscany-assembly-xsd on the classpath but assembly as a > plugin dependency. Strange! > > Simon > > > > So the only pattern I can see here is that the items on the classpath seem > to be test or runtime scope. > > I've found a panel in Eclipse (after some searching!) that says that the > java.xml.stream dependency is satisfied by the JRE so I imagine it is just > ignoring the fact that we are including the geronimo stax library. > > I'm on the IBM JDK5 JDK at the moment which doesn't provide this package so > I wonder why it thinks it does? > > Simon > > > > The only way I can make progress is by manually switching over to the 3.4 > version of the OSGi dependency. There is something going wrong in the PDE > as, from the PDE status panel, if you select the missing stax dependency it > takes you to the OSGi 3.4 manifest. Even though that manifest doesn't export > that package and I have the 3.3.0 version selected for the target > environment. Anyhow selecting that gets me down to 47 errors of the > following form > > > Description Resource Path Location Type > > No available bundle exports package 'javax.imageio' MANIFEST.MF > tuscany-databinding-jaxb/META-INF line 23 Plug-in Problem > No available bundle exports package 'javax.naming' MANIFEST.MF > tuscany-core/META-INF line 51 Plug-in Problem > No available bundle exports package 'javax.security.auth.callback' > MANIFEST.MF tuscany-policy-security/META-INF line 38 Plug-in > Problem > No available bundle exports package 'javax.security.auth.login' MANIFEST.MF > tuscany-policy-security/META-INF line 39 Plug-in Problem > No available bundle exports package 'javax.security.auth' MANIFEST.MF > tuscany-core/META-INF line 52 Plug-in Problem > No available bundle exports package 'javax.security.auth' MANIFEST.MF > tuscany-sca-api/META-INF line 13 Plug-in Problem > No available bundle exports package 'javax.xml.datatype' MANIFEST.MF > tuscany-databinding-jaxb/META-INF line 28 Plug-in Problem > No available bundle exports package 'javax.xml.datatype' MANIFEST.MF > tuscany-databinding/META-INF line 39 Plug-in Problem > No available bundle exports package 'javax.xml.datatype' MANIFEST.MF > tuscany-interface/META-INF line 19 Plug-in Problem > No available bundle exports package 'javax.xml.namespace' MANIFEST.MF > tuscany-assembly-xml/META-INF line 21 Plug-in Problem > No available bundle exports package 'javax.xml.namespace' MANIFEST.MF > tuscany-assembly/META-INF line 23 Plug-in Problem > No available bundle exports package 'javax.xml.namespace' MANIFEST.MF > tuscany-binding-sca-xml/META-INF line 12 Plug-in Problem > No available bundle exports package 'javax.xml.namespace' MANIFEST.MF > tuscany-contribution-java/META-INF line 16 Plug-in Problem > > All references into the JDK so the PDE doesn't seem to understand that the > JDK satisfies some of the import reqiurements. > > So I'm stuck again with this. I'm going to stop trying to do this for a > while and use the normal build process. > > Simon > > > I switched over to a sun version of JDK6 and I can get it down to 1 problem. > Again it's something that appears to be in the JDK. The module > contribution-xml has an import of org.w3c.dom.traversal which the PDE can't > resolve?. If I remove this import the workspace compiles. If I run mvn on > this module to regen the jar in my local repo I can also get a clean run of > the calculator-equinox sample. Yippee! Not sure what this dependency is > required for but obviously the calculator-equinox samples doesn't touch that > code path. > > So I guess my conclusion is that something is definitely broken when trying > to get IBM JDK5 to work. Also, it can be very confusing trying to sort out > dependency problems in this tuscany/mvn/Eclipse/PDE/OSGi environment. I > could try a few other things to get this going on JDK 5 but I'm going to > take a rest and try and get a bit more familiar with the merged code before > embarking on any more Eclipse/OSGi shenanigans. > > Simon > -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/
