Home » Archived » Buckminster » problems with workspace while materializing from headless buckminster
| problems with workspace while materializing from headless buckminster [message #648882] |
Fri, 14 January 2011 16:48  |
Eclipse User |
|
|
|
Hello Buckminsterers --
I'm now working on calling Buckminster headlessly from the command line to do a cross platform build.
I've installed Buckminster, installed a target platform with the delta pack, imported a target platform into buckminster, told it to always use that. I've listed my target definitions and seen it there with the proper workspace
I've checked out my main feature project into my workspace
THE PROBLEM:
When I tell buckminster to import it is not looking in my workspace for the feature that is already there.
The buckminster command I'm running is roughly:
buckminster import -P /usr/local/bla/workspace/features/_feature_my.feature/buckmi nster.properties -C -consoleLog -data /usr/local/bla/workspace/ /usr/local/bla/workspace/features/_feature_my.feature/_featu re_my.feature.cquery
As an experiment, I made a subdirectory:
/usr/local/bla/workspace/workspace
and a subdirectory in that
/usr/local/bla/workspace/workspace/features
checked out my feature into that subdirectory
Then I ran a similar import referencing that nested workspace directory
buckminster import -P /usr/local/bla/workspace/workspace/features/_feature_my.feat ure/buckminster.properties -data /usr/local/bla/workspace/ -C -consoleLog /usr/local/bla/workspace/workspace/features/_feature_my.feat ure/_feature_my.feature.cquery
This worked, and materialized all the components into the parent workspace directory where I wanted them.
SO ... any suggestions as to how I can force and confirm what workspace buckminster is using?
thanks
Tamar
|
|
| | | | |
| Re: problems with workspace while materializing from headless buckminster [message #649371 is a reply to message #649359] |
Tue, 18 January 2011 18:39  |
| Eclipse User |
|
|
|
Hi Tamar
On 18.01.2011 22:39, Tamar Cohen wrote:
> Thanks, Johannes -- it seems I am having a general problem with the
> workspace. I created it by just doing a mkdir, an svn checkout of the
> main feature, and then telling buckminster where the workspace was with
> -data during each command.
I am not quite sure where your problems come from. Are you executing
both these commmands in a script file, or as individual commands from a
e.g. batch script? If the later is the case, could it be possible that
the second invocation gets executed before the first invocation has shut
down and that your workspace is therefore still locked?
That's just random guessing though...
Here is how I (and AFAIK quite a few other people) work with the local
resolver:
I do my builds in Hudson and Hudson is doing the checkout from the
repository. Now Buckminster is started with -data pointing to the folder
containing all the checked out projects and a script file that contains
one or more resolves/import and the actions I want executed.
The RMAP contains two separate readers for the projects that come from
the repository. The first reader is a local reader that expects all
projects to be in the workspace root. This is for the build
machine/hudson since the checkout is done by an external tool in that case.
The second reader is for developer machines and fetches everything
directly from the source repository.
Here's an example of how such a setup could look like:
<rm:searchPath name="yoursources">
<rm:provider componentTypes="osgi.bundle,eclipse.feature"
readerType="local">
<rm:uri format="file:///{0}/{1}/">
<bc:propertyRef key="workspace.root"/>
<bc:propertyRef key="buckminster.component"/>
</rm:uri>
</rm:provider>
<rm:provider
componentTypes="eclipse.feature,osgi.bundle,buckminster" readerType="cvs">
<rm:uri
format=":extssh:{0}@yourserver:22/var/share/cvs/,your/module{1} ">
<bc:propertyRef key="cvs.user"/>
<bc:propertyRef key="buckminster.component"/>
</rm:uri>
</rm:provider>
</rm:searchPath>
Best regards,
Johannes
|
|
| | | | |
| Re: problems with workspace while materializing from headless buckminster [message #649624 is a reply to message #649583] |
Wed, 19 January 2011 17:58 |
| Eclipse User |
|
|
|
Hi Tamar,
please see comments inline.
On 19.01.2011 20:39, Tamar Cohen wrote:
> Questions:
> Do you think it's possible that my parameters are not getting passed in
> in general if I am not using a script?
>
No, it should work without a script, but command lines can be quite
tricky with quoting, shell magic and so on...
I just find it helpful to limit down the potential problem sources when
something isn't working, that's why I asked you to switch to a script
file for the time being.
> Is there a place to look for .log files that may tell me more information?
>
The regular eclipse mechanism is used, so the logfile appears in
WORKSPACE/.metadata/.log, but that should contain about the same
information that gets printed out with loglevel debug.
> I run my script this way:
> buckminster -data /usr/local/irg/path/workspace/ -L DEBUG -consoleLog -P
> /usr/local/path/buckminster.properties -S build_simple3.script
>
> is passing properties that way correct? If not, how should I set the
> buckminster properties?
>
Yes, that's fine
> When I run the script, it says eclipse.buildId=unknown. Is this a problem?
>
No, that's fine.
> Here is the output when it runs, if it is helpful:
> !SESSION 2011-01-19 11:30:04.912
> -----------------------------------------------
....
Your output seems to be just fine, I see no errors.
However, you don't seem to invoke a build action, so I'm not sure what
you expect to happen.
Just in case this is unclear:
The 'build' command simply triggers a full workspace build (same as when
you hit 'clean' in eclipse). So this does not create any artifacts, it
just executes all the project builders.
If you want to create an artifact of some sort you need a
'perform your.component.id#your.attribute' command
So let's say you want to build a p2 update site from an eclipse feature
called 'org.example.foobar'. The command to do this would be
perform org.example.foobar#site.p2
Which attributes (or build actions if you want to call it that way) are
available on a specific component depend on the type of component (plain
java, maven, osgi, eclipse feature,...).
It's best to try this out in your IDE before working with headless
buckminster. Right click on a project (for example an osgi bundle or
eclipse feature) -> buckminster -> invoke action
The artifacts will end up in ${buckminster.output.root} which defaults
to user.tmp if not specified in your properties file.
Best regards,
Johannes
|
|
| | | | | | | | | | |
| Re: problems with workspace while materializing from headless buckminster [message #650139 is a reply to message #650118] |
Fri, 21 January 2011 16:33 |
| Eclipse User |
|
|
|
Hi Tamar,
On 21.01.2011 20:39, Tamar Cohen wrote:
> Hi Henrik --
>
> yes, I am checking in .project and .settings and all associated files
> into version control. I can open eclipse on that workspace -- however,
> it shows no projects! probably because the projects are under features/
> and plugins/ as this is how Buckminster materialized them.
>
No, something was not correct in that workspace. If the projects would
have been materialized correctly, they should have been visible when you
open that workspace with a regular eclipse.
> After I 'import projects into workspace' from the gui, and then exit
> eclipse and run buckminster / build from my script, it finally builds.
>
> So it seems that despite the fact that I used buckminster to materialize
> the projects, since they were placed in child features/ and plugins/
> folders they were not added to the workspace.
>
> Where can I tell Buckminster to put them at the root of the workspace
> during materialization?
>
You can do that with an mspec, but the features/ plugins/ layout was not
your problem. Eclipse decides according to the settings in .metadata
what projects are contained in the workspace. The physical location in
the filesystem doesn't matter.
The question remains though why your projects did not get imported
correctly. Is there maybe a prebind action defined in one of the bundles
that could have crashed during the import?
If you start with a completely new and empty workspace, does it still
not work?
Best regards,
Johannes
|
|
| | | |
| Re: problems with workspace while materializing from headless buckminster [message #650434 is a reply to message #650371] |
Mon, 24 January 2011 15:25 |
| Eclipse User |
|
|
|
Hi Tamar,
it's great that it's finally working for you.
Am 24.01.2011 17:36, schrieb Tamar Cohen:
>
> I'm wondering if there's a way for Buckminster to populate the workspace
> with projects as they are materialized? It seems to me this issue would
> cause compilation errors but given that the source code existed in the
> workspace it would have been less confusing if the workspace knew about
> the projects...
That is what buckminster is doing. When it resolves and materializes
components, it binds them into the Eclipse workspace. If that isn't
working for you then something is going wrong. The only thing that comes
to mind is a buckminster.prebind action that fails, or, as Henrik
mentioned, that your eclipse crashes/doesn't properly shut down at some
point and therefore doesn't persist the metadata.
Best regards,
Johannes
|
|
|
Goto Forum:
Current Time: Sun Jul 06 08:42:18 EDT 2025
Powered by FUDForum. Page generated in 0.11558 seconds |
Home