Eclipse Community Forums: Buckminster

Help

Home

Home » Archived » Buckminster » Workspace Resolver

Show: Today's Messages :: Show Polls :: Message Navigator

Workspace Resolver [message #550544]

Fri, 30 July 2010 18:37

Terran Gilman

Messages: 67
Registered: July 2009

Member

When materializing a cquery, what are the valid location paths for the workspace resolver? The reason I ask is that i currently have the VTP build working with buckminster, however i'd like to make some improvements.

Right now we check out our releng project from SVN using the Hudson. We then initiate the buckminster build with a cquery that pulls all our components from source and their dependencies from various other repository locations and types. We generate the p2 update site and publish the results. All this is working great.

I would like to use Hudson to perform the checkout of all our source components to simplify the update process and Hudson uses this information for various other things like a change log. We have to blank the workspace before each build to ensure the most recent code has been checked out. This would be easy if it weren't for our non-standard SVN repository structure. We arrange things by component. Here is a rough layout for our repo:

{svnroot}
     Desktop
          trunk
               features
               plugins
          branches
               branch1
                    features
                    plugins
     Framework
          trunk
               features
               plugins
          branches
     Releng
          project1
          project2

Is there a way to tell the workspace resolver that there may be additional structure to navigate to locate the projects? It appears that projects in the root of the workspace and projects divided into plugins and features directories works as well.

Report message to a moderator

Re: Workspace Resolver [message #550612 is a reply to message #550544]

Sat, 31 July 2010 09:46

Thomas Hallgren

Messages: 3240
Registered: July 2009

Senior Member

Hi Trip,

The integration with Hudson and other CI's would benefit quite a bit if
the repositories were separated from the repository root relative
locations. Right now, this is not really possible. We can let Hudson
check out everything and then have 'local' resolvers appointing things
in the checked out material but when we do that, the SCM information
about the projects are lost (essential for version qualifier
generation). This means that at present, the only viable option is to
use a complex RMAP setup to check things out to the workspace.

You can direct where things will end up in your workspace by using mspec
directives but I don't think that's really helpful to you.

We have work in progress in this area [1], so the situation will improve
in 3.7.

Regards,
Thomas Hallgren

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=309147

On 07/30/2010 08:37 PM, Trip Gilman wrote:
> When materializing a cquery, what are the valid location paths for the
> workspace resolver? The reason I ask is that i currently have the VTP
> build working with buckminster, however i'd like to make some improvements.
>
> Right now we check out our releng project from SVN using the Hudson. We
> then initiate the buckminster build with a cquery that pulls all our
> components from source and their dependencies from various other
> repository locations and types. We generate the p2 update site and
> publish the results. All this is working great.
>
> I would like to use Hudson to perform the checkout of all our source
> components to simplify the update process and Hudson uses this
> information for various other things like a change log. We have to blank
> the workspace before each build to ensure the most recent code has been
> checked out. This would be easy if it weren't for our non-standard SVN
> repository structure. We arrange things by component. Here is a rough
> layout for our repo:
>
>
> {svnroot}
> Desktop
> trunk
> features
> plugins
> branches
> branch1
> features
> plugins
> Framework
> trunk
> features
> plugins
> branches
> Releng
> project1
> project2
>
>
> Is there a way to tell the workspace resolver that there may be
> additional structure to navigate to locate the projects? It appears that
> projects in the root of the workspace and projects divided into plugins
> and features directories works as well.

Report message to a moderator

Re: Workspace Resolver [message #550622 is a reply to message #550544]

Tue, 03 August 2010 22:26

Terran Gilman

Messages: 67
Registered: July 2009

Member

OK. Given the limitation with the current resolvers, is there a way to get the secondary effect I'm looking for, namely the use of SVN update. We are currently clearing the plugins/features folders that get created in the workspace at each build so the most current source is always pulled from SVN when the cquery is imported.

As far as I can tell, if there is already a workspace project and workspace resolution is enabled, the project is taken "as is" for the purpose of the build. Really what we need is a way to force some sort of "up to date" behavior that will check SVN version number from the trunk or which ever branch a project is resolved to and ensure they match. If the workspace is old, the project is grabbed fresh from the repository. Is there currently a way to do this?

As a side note, we use timestamp qualifiers for our builds. So if there would be a way to cheese it and gain this behavior using either Hudson, bash fu, or mspecs I'm all ears. Thanks.

Report message to a moderator

Previous Topic:	NPE in p2.site actions
Next Topic:	Materializing binary feature in the workspace

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Apr 24 22:59:56 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter