Thanks, Thomas, this is just what I needed to get going!
Regarding Mark's question, is this something that we would resolve by
pointing the p2 providers in the RMAP to the appropriate Eclipse download
On 5/28/10 5:04 AM, "Mark Phippard" <markphip_at_gmail.com> wrote:
> A quick question I have ...
> When I build Subclipse for release, I do it using a copy of Eclipse
> 3.2 that I leave lying around. Is this still possible using
> Buckminster? Obviously the build process could run with something
> newer, but the classes it is resolving against when it compiles need
> to be Eclipse 3.2 for proper backwards compat. at least that is what
> I always thought.
> On Fri, May 28, 2010 at 2:33 AM, Thomas Hallgren <thomas_at_tada.se> wrote:
>> Hi Stephen,
>> Looks like you've done a real deep dive in Buckminster land.
>> I would recommend a simpler approach where you let Buckminster resolve and
>> populate both your target platform and your workspace. Keeping them apart
>> physically is a good thing of course, but you can do that and still have the
>> benefits of one single resolution.
>> The approach outlined here assumes that you are using Buckminster 3.6 and a
>> 3.6 RC2 IDE. The IDE is of course optional but it's great for the initial
>> steps and to get things up and running smoothly.
>> 1. Create feature that describes your intended update site. It's just a
>> normal Eclipse feature. Normally, this feature is not included in the
>> resulting site. It just acts as a description.
>> 2. Create a CQUERY/RMAP combination that works. In the RMAP, try using "svn"
>> providers for the source (with source="true") and p2 providers for all
>> bundles that you wish to get as binaries. The CQUERY must point to the
>> feature created in #1.
>> Do not use our dogfood RMAP. It's not maintained.
>> 3. Use your IDE at first. Create a target platform with one single
>> "directory" container and set that target platform as the active one.
>> 4. Run the CQUERY "Resolve and Materialize". The first time you do this, you
>> are likely to run into problems with components that cannot be resolved (like
>> the one you describe). Once it resolves correctly, you will see that
>> Buckminster populates both your target platform and your workspace.
>> 5. Verify that everything builds in your IDE. Rigth click on the feature
>> created in #1 and select "Buckminster" -> "Perform" -> "site.p2". This should
>> build the update site for you.
>> Once the above works, the Buckminster part of your build is complete. You
>> should now be able to repeat the same thing headlessly.
>> 1. Import the CQUERY using buckminster import <url>
>> 2. Issue a buckminster build
>> 3. Issue a buckminster perform <feature name>#site.p2
>> The rest is all about Hudson.
>> Please note that if Hudson is used when populating your workspace, you will
>> miss two things:
>> 1. The target platform is not resolved and materialized by Buckminster.
>> 2. SVN meta-data is not available since the workspace projects are not
>> "shared" using the team provider. This means that qualifier replacement using
>> revision number or timestamp doesn't work.
>> If you want a simple example of a complete build of a site, you can take a
>> look at the last one that I did for xtext. It's in the form of two projects.
>> One 'releng' that is a pure release engineering project. It contains the
>> cspec, the rmap, and needed properties:
>> and then there's an example of a feature that describes a site.
>> Don't hesitate to ask if you have more questions. I'm more then happy to help
>> with this. You can also try our mailing lists and newsgroups. You'll get
>> quick answers there, both regarding Buckminster itself and the Buckminster
>> Hudson plugin.
>> Kind Regards,
>> Thomas Hallgren
>> To unsubscribe from this discussion, e-mail:
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_subclipse.tigris.org].
Received on 2010-05-28 15:54:29 CEST