[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [equinox-dev] PDE build with a framework adapter
|
Thanks for the suggestions Andrew and Thomas. I tried this, but nothing works (ie- same compile errors):
1. add require bundle for org.eclipse.osgi to the downstream plugins
2. add -DflattenDependencies=true to the ant call to start the pde build. (I didn't think this would work since the plugin and fragment are in the same feature already)
3. Added
Eclipse-ExtensibleAPI: true to my fragment (even though I know it's not supposed to go there)
4. I even re-ordered the included plugins specified in the feature.xml.
Any more ideas?
On Tue, Jul 17, 2012 at 8:07 AM, Andrew Niefer
<aniefer@xxxxxxxxxx> wrote:
For PDE/Build, there should be no difference
between Import-Package and Require-Bundle. The bundles that bundles
that PDE/Build will consider as required are from BundleDescription#getResolvedImports
and BundleDescription#getResolvedRequires.
Fragments should always show up on the
classpath when a host bundle is required, the ExtensibleAPI header affects
whether the fragments show up before or after the host.
Here, the problem doesn't seem to be
with the order of the classpath, but rather the order of compilation.
One thing to check is the property "flattenDependencies",
I believe the default is false if not set. Without this set to true,
then bundles compilation is only ordered by dependencies within a feature.
Features are processed in inclusion order. If you set this
to true, then all bundles across all features are sorted according to dependencies
and compiled in that order.
(As an aside, this ordering feature
was added in 3.5, perhaps it is time to change the default to true :) ).
-Andrew
From:
Thomas Watson <tjwatson@xxxxxxxxxx>
To:
Equinox development
mailing list <equinox-dev@xxxxxxxxxxx>
Date:
07/17/2012 08:41 AM
Subject:
Re: [equinox-dev]
PDE build with a framework adapter
Sent by:
equinox-dev-bounces@xxxxxxxxxxx
Fragments to the system bundle (org.eclipse.osgi)
should be added to the class path for any bundles that import packages
exported by the fragment bundle. This is similar to SWT where all
the java classes are provided by the SWT fragments. There is a header
in org.eclipse.osgi (Eclipse-ExtensibleAPI: true) that simply a marker
to indicate to PDE that it should place any fragments (that export packages)
on the class path of consumers that either require-bundle the host (org.eclipse.osgi)
or import a package provided by the host or one of its attached fragments.
The only thing I can think of is that this is not working seamlessly
for Import-Package. As an experiment could you try building a bundle
that uses Require-Bundle: org.eclipse.osgi as well as Import-Package?
If that works then I would open a bug against PDE-Build for the issue since
it should handle Import-Package similarly to how PDE-UI does.
Tom
Andrew
Eisenberg ---07/16/2012 11:05:30 PM---Hi all,
Hi all,
I have a framework adapter that I am creating. Other bundles in the
eclipse feature need to reference classes from the framework adapter.
In a runtime workbench, this is working fine. Similarly, I don't
have
any problems at runtime. The bundles that require classes from the
framework adapter just use import-package and everything seems to
work.
However, the problem is during a pde build. The compile of the
non-fragment bundles happens first and so they fail to compile since
the fragment is not yet compiled (note that there is no explicit
dependency on the fragment, there is only an import-package). I've
gotten around this through a horrendous hack where I compile the
source folder of the framework adapter into a jar that gets stuck on
the compile-time classpath of the bundles that need it. And it is
removed before creating the update site.
Does anyone know a way around this? Should I be asking this on the
PDE mailing list?
thanks,
Andrew
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev