You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2008/11/21 17:59:51 UTC
What's on the PDE project classpath? was: Re: 2.0 trunk modules status update
Hi,
It seems that they are a lot of confusions about the class path entries for
the tuscany modules as PDE projects. Let me try to claify:
1) We generate the .classpath from maven dependencies.
2) For maven compile/provided dependencies, the modules explicit references
these dependencies via packages. We define corresponding Import-Package
header in the MANIFEST.MF for OSGi, and these get resolved to other bundles
that export the matching packages. This magic comes from the
"org.eclipse.pde.core.requiredPlugins" classpath container which is
contributed by the Eclipse PDE. The classpath container resolves the OSGi
dependencies such as Import-Package or Required-Bundle and automatically add
the required bundles to the classpath as we see in Eclipse project under the
"Plugin Dependencies".
3) The exported packages come from three types of sources:
* System packages (exported by the System Bundle, i.e., org.eclipse.osgi).
Different JDK levels have different list of system packages, for example,
javax.xml.stream is not in J2SE-1.5 but in JSEJava-1.6. You can find the
complete list by looking the .profile files within osgi-<version>.jar.
* Tuscany modules in the Eclipse workspace. The classpath entry will be
listed as a project under "Plugin Dependencies"
* 3rd-party jars (already as OSGi bundles contributed by the target
platform). The classpath entry will be listed as a jar under "Plugin
Dependencies"
4) For maven runtime dependencies, there is no corresponding Import-Package
and the dependencies are used in runtime. Ideally in OSGi, they could be a
Required-Bundle or a bundle available at runtime. To run the project in JSE
inside Eclipse, we generate an explicit classpath entry.
5) For maven test dependencies, there are two types: one is for test
compilation and the other for test runtime. For the first type, we use
optional Import-Package to pull in the dependencies if the same project has
the compile dependency for the same artifact. Otherwise, we generate an
explicit classpath entry for JSE testing.
6) For test cases which require extra dependencies in addition to the
compile/provided/runtime dependencies for the main code, they probably
should not be unit tests. We need to consider how to move them into the
itest bucket.
Thanks,
Raymond
From: Simon Laws
Sent: Friday, November 21, 2008 6:08 AM
To: dev@tuscany.apache.org
Subject: Re: 2.0 trunk modules status update
On Fri, Nov 21, 2008 at 1:42 PM, Simon Laws <si...@googlemail.com>
wrote:
On Fri, Nov 21, 2008 at 1:08 PM, Simon Laws <si...@googlemail.com>
wrote:
On Fri, Nov 21, 2008 at 10:29 AM, Luciano Resende <lu...@gmail.com>
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 <si...@googlemail.com>
wrote:
>
>
> On Fri, Nov 21, 2008 at 9:42 AM, Luciano Resende <lu...@gmail.com>
> 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 <si...@googlemail.com>
>> wrote:
>> >
>> >
>> > On Fri, Nov 21, 2008 at 9:22 AM, Luciano Resende <lu...@gmail.com>
>> > wrote:
>> >>
>> >> On Thu, Nov 20, 2008 at 10:23 PM, Raymond Feng <en...@gmail.com>
>> >> 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: dev@tuscany.apache.org ; antelder@apache.org
>> >> > Subject: Re: 2.0 trunk modules status update
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Nov 20, 2008 at 3:30 PM, ant elder <an...@gmail.com>
>> >> > wrote:
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Nov 20, 2008 at 2:30 PM, Simon Laws
>> >> > <si...@googlemail.com>
>> >> > wrote:
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Nov 20, 2008 at 7:22 AM, Raymond Feng <en...@gmail.com>
>> >> > 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" <lu...@gmail.com>
>> >> > Sent: Wednesday, November 19, 2008 11:19 AM
>> >> > To: <de...@tuscany.apache.org>
>> >> > 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
>> >> > <si...@googlemail.com>
>> >> > wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Nov 19, 2008 at 5:15 PM, Simon Laws
>> >> > <si...@googlemail.com>
>> >> > wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Nov 19, 2008 at 4:37 PM, ant elder <an...@gmail.com>
>> >> > 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
Re: What's on the PDE project classpath? was: Re: 2.0 trunk modules status update
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Nov 21, 2008 at 4:59 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> It seems that they are a lot of confusions about the class path entries for
> the tuscany modules as PDE projects. Let me try to claify:
>
> 1) We generate the .classpath from maven dependencies.
>
> 2) For maven compile/provided dependencies, the modules explicit references
> these dependencies via packages. We define corresponding Import-Package
> header in the MANIFEST.MF for OSGi, and these get resolved to other bundles
> that export the matching packages. This magic comes from the
> "org.eclipse.pde.core.requiredPlugins" classpath container which is
> contributed by the Eclipse PDE. The classpath container resolves the OSGi
> dependencies such as Import-Package or Required-Bundle and automatically add
> the required bundles to the classpath as we see in Eclipse project under the
> "Plugin Dependencies".
>
> 3) The exported packages come from three types of sources:
> * System packages (exported by the System Bundle, i.e., org.eclipse.osgi).
> Different JDK levels have different list of system packages, for example,
> javax.xml.stream is not in J2SE-1.5 but in JSEJava-1.6. You can find the
> complete list by looking the .profile files within osgi-<version>.jar.
> * Tuscany modules in the Eclipse workspace. The classpath entry will be
> listed as a project under "Plugin Dependencies"
> * 3rd-party jars (already as OSGi bundles contributed by the target
> platform). The classpath entry will be listed as a jar under "Plugin
> Dependencies"
>
> 4) For maven runtime dependencies, there is no corresponding Import-Package
> and the dependencies are used in runtime. Ideally in OSGi, they could be a
> Required-Bundle or a bundle available at runtime. To run the project in JSE
> inside Eclipse, we generate an explicit classpath entry.
>
> 5) For maven test dependencies, there are two types: one is for test
> compilation and the other for test runtime. For the first type, we use
> optional Import-Package to pull in the dependencies if the same project has
> the compile dependency for the same artifact. Otherwise, we generate an
> explicit classpath entry for JSE testing.
>
> 6) For test cases which require extra dependencies in addition to the
> compile/provided/runtime dependencies for the main code, they probably
> should not be unit tests. We need to consider how to move them into the
> itest bucket.
>
> Thanks,
> Raymond
>
>
See, it's obvious really;-) Thanks for the summary Raymond. 6) is an
interesting point that we need to start looking out for. We should add it to
the list (themes?) of things we need to address.
Simon