| More on best practice for using Buckminster for IDE Target Platform [message #660126] |
Wed, 16 March 2011 23:43  |
 Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
I wanted to ask a followup question WRT to our discussion regarding preferred way to set up our IDE so that it matches our headless Jenkins / Hudson instance. But I thought it would be useful for people if I summarized the approach. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=324444 and recent posts for context.
Thomas suggests the following way to set up your local IDE. The idea here is to avoid using a pre-defined target platform either on the IDE side or in Jenkins. This has all kinds of benefits, not least of which is not having to muck around with your local update sites, etc.. at all. Just grab your releng project(s), trigger Buckminster, and you're all set! Jenkins builds are similarly simplified / rationalized.
1. Create an empty, general project and call it TP.
2. Go to "Window" -> "Preferences" -> Plug-in Development" -> "Target Platform"
3. Create a new target platform and call it TP. It consists of one Directory.
The Directory is set to ${workspace_loc:TP}
4. Make sure that this target platform is the active one.
5. Add properties that are normally passed on the command line as "Run/Debug"
-> "String Substitution" preferences.
6. Open your CQUERY and click Resolve and Materialize.
7. Get some coffee...
8. Once the materialization completes, the workspace builds automatically.
9. Right click on the project containing the action that you want. Choose
"Buckminster" -> "Invoke Action". In the dialog that opens, choose a property
file and the action to perform.
If you're building for RCP, I noted that you can get around an issue with building RCPs by doing this:
1. Manually add to your applications feature:
<includes
id="org.eclipse.equinox.executable"
version="0.0.0"/>
You can't use the PDE UI because of course it doesn't exist yet.
2. You will see an error in the feature.
3. Open site cquery and select "Resolve and Materialize"
4. Feature should now build.
5. Invoke site.p2, create.product..
I then asked how to handle the issue that you might want the source in the IDE target, but not in the build target. Thomas says:
"Populate the TP using Buckminster with our without the property buckminster.download.source set to true."
|
|
|
|
|
|
| Re: More on best practice for using Buckminster for IDE Target Platform [message #660156 is a reply to message #660128] |
Thu, 17 March 2011 07:22  |
|
On 2011-03-17 01:01, Miles Parker wrote:
> Now for my question. What about the case where you need something as a design-time dependency but not at run-time? This
> is a somewhat unusual circumstance -- I am not talking about the situation where you just need a build time *tool* --
> that is of course handled by simply installing it into your IDE. An example is when generating XText projects. Here
> there are optional dependencies that Xtext built projects use to find things that they need for generating code but that
> aren't needed at runtime. Am I correct in thinking that you would want to set eclipse.p2.optional=false in order to get
> those dependencies?
>
That would probably work if your objective is to get that stuff into your TP. Question is, why would you? We use XText a
great deal but we've never had any use for that. If you have a need to generate, then install XText into your IDE.
Everyone else can do without it since the generated stuff is checked in.
One could of course argue that Bucky should be able to extend your IDE (the design time tool) too, but that's not
possible at present.
> Also, a dumb question for sure, but when I make these kinds of changes, or changes in dependencies for features, what's
> the best way to make the TP match? Especially when I've done version changes the only thing that seems to work is to
> manually delete the TP and start from scratch. Am I missing something easier?
For my day to day work, I usually keep the TP and just re-materialize so that the TP is complemented with the new stuff.
The only situation when that'll break is where you have things in the TP that shouldn't be there. For instance, you have
things that make the wrong bundle resolving package imports. Older versions will normally be discriminated by default
and things that aren't used, well, the seldom do any harm. They are not included in the build.
- thomas
|
|
|
| Re: More on best practice for using Buckminster for IDE Target Platform [message #660157 is a reply to message #660142] |
Thu, 17 March 2011 07:25 |
|
On 2011-03-17 03:43, Miles Parker wrote:
> And now for super-duper extra credit, how should one go about provisioning the target platform so that the IDE itself
> can use the toolsets/sdks needed?
Not possible at the moment I'm afraid. Extending the functionality of the IDE must be done as a separate thing. The IDE
doesn't have access to the TP. It can be scripted of course (using the director to install things), but it cannot be
part of the normal bucky resolution.
- thomas
|
|
|
|
Powered by
FUDForum. Page generated in 0.02196 seconds
] 
Search
Help
Register
Login
Home
