Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster » More on best practice for using Buckminster for IDE Target Platform
More on best practice for using Buckminster for IDE Target Platform [message #660126] Wed, 16 March 2011 23:43 Go to next message
Miles Parker is currently offline Miles Parker
Messages: 1340
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 #660128 is a reply to message #660126] Thu, 17 March 2011 00:01 Go to previous messageGo to next message
Miles Parker is currently offline Miles Parker
Messages: 1340
Registered: July 2009
Senior Member
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?

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?
Re: More on best practice for using Buckminster for IDE Target Platform [message #660136 is a reply to message #660128] Thu, 17 March 2011 01:41 Go to previous messageGo to next message
Miles Parker is currently offline Miles Parker
Messages: 1340
Registered: July 2009
Senior Member
Miles Parker wrote on Wed, 16 March 2011 20:01
Am I correct in thinking that you would want to set eclipse.p2.optional=false in order to get those dependencies?



Was basing this on someone else's guess in the forums. Turns out what you want is "eclipse.p2.optional=true", which does make more sense. (A better name would have been "eclipse.p2.include.optional" ala buckminster source property.)
Re: More on best practice for using Buckminster for IDE Target Platform [message #660142 is a reply to message #660136] Thu, 17 March 2011 02:43 Go to previous messageGo to next message
Miles Parker is currently offline Miles Parker
Messages: 1340
Registered: July 2009
Senior Member
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?
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 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
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
Re: More on best practice for using Buckminster for IDE Target Platform [message #660293 is a reply to message #660156] Thu, 17 March 2011 17:13 Go to previous message
Miles Parker is currently offline Miles Parker
Messages: 1340
Registered: July 2009
Senior Member
Thomas Hallgren wrote on Thu, 17 March 2011 03:22

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.


In my experience, the XText generators want certain stuff -- such as the de.antlr packages -- to appear in the classpath and get grouchy if they don't. But forcing the optional resolution takes care of that.
Previous Topic:build.xml:86 {fs:action.requirements} not found
Next Topic:Plain "build" command fails on Hudson/Jenkins with buckminster-headless 3.6.2 release
Goto Forum:
  


Current Time: Thu Oct 02 06:41:32 GMT 2014

Powered by FUDForum. Page generated in 0.01938 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software