Home » Eclipse Projects » Plugin Development Environment (PDE) » headless PDE build: how can I force resolution of a modified plugin?
| headless PDE build: how can I force resolution of a modified plugin? [message #63620] |
Thu, 28 May 2009 20:09  |
 William R. Swanson
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
I'm using Eclipse 3.4.2 to do a headless PDE build
for a product where I'm importing a standard plugin
(org.eclipse.cdt.make.ui) as a source project and making
some minor changes to the plugin code.
What I'm seeing is that when I export the product from
within Eclipse (File->Export, Eclipse Product), it builds
as expected and the standard CDT plugin is replaced
with my modified version.
When running a headless build, however, the behavior isn't
determinstic: on some runs it's replaced and on other runs
the original version of the plugin is picked up.
Is there a way to force the headless build to resolve
the plugin correctly, or equivalently is there something
else I need to do (like specify a dependency or a
different version number on the modified plugin)?
Currently, my modified CDT plugin has the same version
number as the original; I've tried changing the version number
(e.g. incrementing it to 5.0.2, etc.) but this does not work
because something (maybe the CDT feature) is still looking
for the original version:
Problems during export
Unable to find plug-in: org.eclipse.cdt.make.ui_5.0.1.200902130801. Please
check the error log for more details.
Unable to find plug-in: org.eclipse.cdt.make.ui_5.0.1.200902130801. Please
check the error log for more details.
The product is defined as one feature, which includes the
modified plugin together with some other custom plugins.
The feature also includes the two "platform" features
(org.eclipse.cdt, org.eclipse.platform), and the product
invokes the org.eclipse.ui.ide.workbench application.
When I compare the output of a successful headless run with
a failed headless run, it appears that the eclipse.generateFeature
task is attempting to resolve the modified plugin, since I always
see the following in the build log output:
generateFeature:
[eclipse.generateFeature] Some inter-plug-in dependencies have not been
satisfied.
[eclipse.generateFeature] Bundle org.eclipse.cdt.make.ui:
[eclipse.generateFeature] Another singleton version selected:
org.eclipse.cdt.make.ui_5.0.1.200902130801
In the generated "build.xml" file for the feature, I see that
the "all.plugins" target either does or does not include
an entry for the modified CDT plugin, based on how the
plugin gets resolved.
<target name="all.plugins" depends="init">
<ant antfile="build.xml" dir="../../plugins/org.eclipse.cdt.make.ui"
target="${target}">
<property name="arch" value="x86"/>
<property name="ws" value="gtk"/>
<property name="os" value="linux"/>
</ant>
... other custom plugins ...
</target>
Any suggestions on what I should change to get the
modified plugin to be resolved consistently?
It's almost there, it's like I only need to specify
one more constraint to make it happen. :-)
--- WRS
|
|
|
| Re: headless PDE build: how can I force resolution of a modified plugin? [message #63643 is a reply to message #63620] |
Fri, 29 May 2009 07:30  |
Eclipse User |
|
|
|
Originally posted by: mickael.istria.openwide.fr
Hello William.
William R. Swanson a écrit :
> Is there a way to force the headless build to resolve
> the plugin correctly, or equivalently is there something
> else I need to do (like specify a dependency or a
> different version number on the modified plugin)?
Have you tried to set a specific version for your plugin (for example
3.0.2.patched or 3.0.3) and to specify in your .product or feature.xml
that you wish to use this version ?
HTH
Mickael
|
|
| |
| Re: headless PDE build: how can I force resolution of a modified plugin? [message #64119 is a reply to message #63620] |
Thu, 04 June 2009 20:48 |
William R. Swanson
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
For the record, after working with this for a bit, I came up with
the following method which seems to do what I want:
- determine the "feature" hierarchy that contains the
plugin you want to modify; in my case it was
org.eclipse.cdt (feature) contains
org.eclipse.cdt.platform (feature) contains
org.eclipse.cdt.make.ui (plugin)
- import each parent feature as a binary feature project
- import the plugin to be modified as a plugin project with source
- increment the version number on the plugin project
- in the parent feature's "Plug-ins" page,
specify that incremented version for the edited plugin
instead of the wildcard "0.0.0"
- do the same thing for each containing feature project
(increment the feature's version number, and specify
that number explicitly in the parent feature's
"Included Features" page)
- I'm using a topmost containing feature project to define my product;
in that feature project I just needed to add a reference to the topmost
feature project (org.eclipse.cdt), specifying the new version number.
This appears to cause the headless PDE build process to correctly
pick up the modified features/plugins for my build, but still pick up
the original features/plugins for the rest of CDT. I'm assuming the
same trick would work if I needed to modify a plugin from
the Eclipse platform as well.
This feels somewhat reasonable, and produces the right result,
though I'd be concerned if the feature hierarchy was much deeper
and I had to import a lot more feature projects.
If this method is obviously broken somehow, or if someone knows
a more efficient way to do this, please let me know!
--- WRS
"William R. Swanson" <traveler@tilera.com> wrote in message
news:gvmr19$t2l$1@build.eclipse.org...
> I'm using Eclipse 3.4.2 to do a headless PDE build
> for a product where I'm importing a standard plugin
> (org.eclipse.cdt.make.ui) as a source project and making
> some minor changes to the plugin code.
>
> What I'm seeing is that when I export the product from
> within Eclipse (File->Export, Eclipse Product), it builds
> as expected and the standard CDT plugin is replaced
> with my modified version.
>
> When running a headless build, however, the behavior isn't
> determinstic: on some runs it's replaced and on other runs
> the original version of the plugin is picked up.
>
> Is there a way to force the headless build to resolve
> the plugin correctly, or equivalently is there something
> else I need to do (like specify a dependency or a
> different version number on the modified plugin)?
> ...
|
|
| |
| Re: headless PDE build: how can I force resolution of a modified plugin? [message #597966 is a reply to message #63620] |
Fri, 29 May 2009 07:30 |
|
Hello William.
William R. Swanson a écrit :
> Is there a way to force the headless build to resolve
> the plugin correctly, or equivalently is there something
> else I need to do (like specify a dependency or a
> different version number on the modified plugin)?
Have you tried to set a specific version for your plugin (for example
3.0.2.patched or 3.0.3) and to specify in your .product or feature.xml
that you wish to use this version ?
HTH
Mickael
|
|
| |
| Re: headless PDE build: how can I force resolution of a modified plugin? [message #598107 is a reply to message #63620] |
Thu, 04 June 2009 20:48 |
William R. Swanson
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
For the record, after working with this for a bit, I came up with
the following method which seems to do what I want:
- determine the "feature" hierarchy that contains the
plugin you want to modify; in my case it was
org.eclipse.cdt (feature) contains
org.eclipse.cdt.platform (feature) contains
org.eclipse.cdt.make.ui (plugin)
- import each parent feature as a binary feature project
- import the plugin to be modified as a plugin project with source
- increment the version number on the plugin project
- in the parent feature's "Plug-ins" page,
specify that incremented version for the edited plugin
instead of the wildcard "0.0.0"
- do the same thing for each containing feature project
(increment the feature's version number, and specify
that number explicitly in the parent feature's
"Included Features" page)
- I'm using a topmost containing feature project to define my product;
in that feature project I just needed to add a reference to the topmost
feature project (org.eclipse.cdt), specifying the new version number.
This appears to cause the headless PDE build process to correctly
pick up the modified features/plugins for my build, but still pick up
the original features/plugins for the rest of CDT. I'm assuming the
same trick would work if I needed to modify a plugin from
the Eclipse platform as well.
This feels somewhat reasonable, and produces the right result,
though I'd be concerned if the feature hierarchy was much deeper
and I had to import a lot more feature projects.
If this method is obviously broken somehow, or if someone knows
a more efficient way to do this, please let me know!
--- WRS
"William R. Swanson" <traveler@tilera.com> wrote in message
news:gvmr19$t2l$1@build.eclipse.org...
> I'm using Eclipse 3.4.2 to do a headless PDE build
> for a product where I'm importing a standard plugin
> (org.eclipse.cdt.make.ui) as a source project and making
> some minor changes to the plugin code.
>
> What I'm seeing is that when I export the product from
> within Eclipse (File->Export, Eclipse Product), it builds
> as expected and the standard CDT plugin is replaced
> with my modified version.
>
> When running a headless build, however, the behavior isn't
> determinstic: on some runs it's replaced and on other runs
> the original version of the plugin is picked up.
>
> Is there a way to force the headless build to resolve
> the plugin correctly, or equivalently is there something
> else I need to do (like specify a dependency or a
> different version number on the modified plugin)?
> ...
|
|
| |
Goto Forum:
Current Time: Sat Apr 27 04:17:18 GMT 2024
Powered by FUDForum. Page generated in 0.03504 seconds |
] 
Search
Help
Register
Login
Home
