Home » Eclipse Projects » Rich Client Platform (RCP) » Headless PDE Build: Building each plugin separately and then bundling into RCP application?
| | |
| Re: Headless PDE Build: Building each plugin separately and then [message #461666 is a reply to message #461655] |
Tue, 16 January 2007 04:55   |
 Alex Blewitt
Messages: 946
Registered: July 2009 |
Senior Member |
|
|
So, getting onto the features is a first start :-)
When you build/compile your plugins, you are (implicitly) depending on the plugins in the target platform (i.e. your installed version of Eclipse). So, whilst you need to compile org.example.foo, you don't need to compile org.eclipse.core.runtime, because it's already there for you.
If you look in your eclipse/features/ directory, you'll find (at least) org.eclipse.platform and org.eclipse.sdk. If you look into the SDK feature, you'll find it will say something like:
<includes
id="org.eclipse.platform"
version="3.2.1.r321_v20060921-b_XVA-INSQSyMtx"/>
[/xml]
So, instead of the SDK having to list everything that it directly depends on, it can just require the org.eclipse.platform feature, and if the org.eclipse.platform feature changes in the future, the SDK doesn't care -- it just takes whatever the feature gives it.
So, I was suggesting that you have two features:
org.example.data.feature (containing org.example.data)
org.example.app.feature (containing org.example.app, depending on org.example.data)
The automated build, on a feature basis, will compile features separately. So you can have one build that compiles the org.example.data.feature (and dependent plugins) separately from the org.example.app.feature (and dependent plugins). Plus, you can then ship them separately, so that the data plugin changes less frequently than the app plugin, in much the same way that (e.g.) the org.eclipse.platform might change more slowly than org.eclipse.sdk.
Of course, in order for this to work, you'll need to move towards a feature-based plugin :-)
The other hack that you could do is to compile the data plugin and copy it into your plugins/ of your target platform. That way, you could still set up and compile your build without having to recompile the data each time. Of course, you'd still need to have a way of updating the data plugin, possibly manually.
Alex.
|
|
|
| Re: Headless PDE Build: Building each plugin separately and then [message #462024 is a reply to message #461666] |
Sun, 21 January 2007 22:57 |
Barrie Treloar
Messages: 11
Registered: July 2009 |
Junior Member |
|
|
Alex Blewitt wrote:
> So, I was suggesting that you have two features:
>
> org.example.data.feature (containing org.example.data)
> org.example.app.feature (containing org.example.app, depending on
> org.example.data)
>
> The automated build, on a feature basis, will compile features
> separately. So you can have one build that compiles the
> org.example.data.feature (and dependent plugins) separately from the
> org.example.app.feature (and dependent plugins). Plus, you can then
> ship them separately, so that the data plugin changes less frequently
> than the app plugin, in much the same way that (e.g.) the
> org.eclipse.platform might change more slowly than org.eclipse.sdk.
>
> Of course, in order for this to work, you'll need to move towards a
> feature-based plugin :-)
>
> The other hack that you could do is to compile the data plugin and
> copy it into your plugins/ of your target platform. That way, you
> could still set up and compile your build without having to recompile
> the data each time. Of course, you'd still need to have a way of
> updating the data plugin, possibly manually.
Thank Alex.
I'm still having trouble seeing the difference between the automated
build and the hack.
For the org.example.app.feature build to work I still need the build of
the feature org.example.data.feature to have completed. And then I need
to have the org.example.data.feature plugins available somehow so that
the org.example.app.feature can find them.
How does the PDE build automate retrieval of dependent plugins from a
feature build? From my understanding it doesn't retrieve the plugins as
it expects them to be in your target platform.
It is feeling like I will have a maven project for each of the features
and each project will have its own target platform and I can automate
the population of the target platform via maven prior to invoking the
ant pde build.
Cheers
Barrie
|
|
|
| Re: Headless PDE Build: Building each plugin separately and then [message #462025 is a reply to message #462024] |
Mon, 22 January 2007 03:54 |
Alex Blewitt
Messages: 946
Registered: July 2009 |
Senior Member |
|
|
> For the org.example.app.feature build to work I still need the build of
> the feature org.example.data.feature to have completed.
Yes, but -- and this is the important point -- they don't have to be done at the same time. You don't recompile org.eclipse.equinox.common each time you do your build, nor (in a Maven project) do you re-build the Log4J libraries if you happen to use them. In fact, Maven pretty much is predicated on building each pom at its own time, and resolving whatever non-source poms are left by reference to the maven repository. It's pretty much the same thing with the headless PDE build, except that the 'repository' is called the 'target platform'.
> How does the PDE build automate retrieval of dependent plugins from a
> feature build? From my understanding it doesn't retrieve the plugins as
> it expects them to be in your target platform.
You can think of the target platform as being the maven repo; that's the set of things you depend on, but don't build. So you'd have two builds; one for your 'data' feature, and the other for the 'code' feature. In the 'data' feature, your plugin is just the standard Eclipse RCP; in the 'code' feature your target platform becomes the RCP+data feature.
So yes, consider this as two separate builds, each with their own feature as output. It's really no different from a system where you have two developer teams producing a core library and a project that uses that library (and don't share maven repositories). You build the core library separately from the users of that library, then at strategic points, bump the version number of the core library up and make it available to the other team; except in your case, the 'core library' just contains data, not code.
Alex.
|
|
|
Goto Forum:
Current Time: Fri Apr 26 06:37:26 GMT 2024
Powered by FUDForum. Page generated in 0.03029 seconds |
] 
Search
Help
Register
Login
Home
