Home » Archived » Buckminster » problems with workspace while materializing from headless buckminster
| | | |
| Re: problems with workspace while materializing from headless buckminster [message #649359 is a reply to message #649013] |
Tue, 18 January 2011 21:39   |
 Tamar Cohen
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
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.
When I try to do a buckminster build, after materialization, giving it the properties file and the workspace (even after adding the buckminster.workspace.root property per your suggestion), I get a workspace is closed exception:
java.lang.IllegalStateException: Workspace is closed.
at org.eclipse.core.resources.ResourcesPlugin.getWorkspace(Reso urcesPlugin.java:367)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.<init >(InternalWorkspaceJob.java:27)
at org.eclipse.core.resources.WorkspaceJob.<init>(WorkspaceJob.java:60)
at org.eclipse.buckminster.core.materializer.WorkspaceBindingIn stallJob. <init>(WorkspaceBindingInstallJob.java:60)
Is there a buckminster call that I should be using instead to create the workspace?
There is a lack of documentation on all the steps to do this headlessly, which I will try to remedy once I figure this out.
thanks for all the help
Tamar
[Updated on: Tue, 18 January 2011 21:40] Report message to a moderator |
|
|
| Re: problems with workspace while materializing from headless buckminster [message #649371 is a reply to message #649359] |
Tue, 18 January 2011 23:39 |
Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
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 22:58 |
Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
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 #649629 is a reply to message #649624] |
Thu, 20 January 2011 00:30 |
Tamar Cohen
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
Hi Johannes --
thanks again for your response -- I do think I have a good understanding of invoking a buckminster action, as I have created create.product and create.product.zip which I have invoked from the UI and headless. These actions do operate, and they create p2 update site and copy files around and all that.
HOWEVER when they have done that if I have called it headlessly, there are no compiled java class files in the jars. This tells me the build (ie java compile) did not happen, and when I explore my workspace I see some bin/ folders but they are empty.
So what I am trying to do is explicitly call the build on the workspace such that it will do the eclipse build and generate the java class files. I have checked my full projects into svn so the eclipse builders should be defined.
What should the build action in a script file do? shouldn't it build my workspace? I'm having the feeling that I am missing some core feature or plugins from my headless buckminster install or something.
Thanks
Tamar
[Updated on: Thu, 20 January 2011 00:31] Report message to a moderator |
|
| | | | | | | | | |
| Re: problems with workspace while materializing from headless buckminster [message #650139 is a reply to message #650118] |
Fri, 21 January 2011 21:33 |
Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
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
|
|
| | | | |
Goto Forum:
Current Time: Wed Feb 05 04:00:32 GMT 2025
Powered by FUDForum. Page generated in 0.06525 seconds |
] 
Search
Help
Register
Login
Home
