Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster dev » Headless Build for Custom Builder
Headless Build for Custom Builder [message #31116] Tue, 03 February 2009 06:55 Go to next message
Eclipse UserFriend
Originally posted by: alex.chatziparaskewas.continental-corporation.com

Hi All

The question below has already been posted to the eclipse platform
newsgroup
( http://www.eclipse.org/newsportal/article.php?id=79883&g roup=eclipse.platform#79883)
However, no replys yet.

However, in the meantime I have received a hint that my problem could
eventually be solved with buckminster. Big question is now: Is that hint
true?

Thanks in Advance & Kind Regards
Alex

-------------------------
original posting:

I have the following problem: I have written a custom builder/nature for
Eclipse, which allows incrementally building a 'custom langugage'. This
all works quite nicely and was relatively simple. Now we require this
build to be able to be run headlessly though. However, the currently
written build infrastructure has dependencies to various Eclipse IDE
concepts, e.g. resources, projects, the 'workspace functionality'. At the
moment I only see two (not so much appealing) solutions:

a) Write a custom 'Eclipse Application', which starts the Eclipse IDE
(without any UI), creates an empty workspace somewhere, loads the poject
to be built 'headlessly' into the workspace, triggers the build and
terminates the entire crap once the build is finished.

b) Remove all dependencies to any of the used Eclipse concepts from the
current implementation (in some way), enabling it to run as a simple Java
application.

Big question is now: Which path to take? Are there any alternatives or
better solutions to this problem?

I would be greatful for any advice (or examples!).
Re: Headless Build for Custom Builder [message #31151 is a reply to message #31116] Tue, 03 February 2009 08:08 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Alex,
I think this sounds like a good match for Buckminster. We do indeed
provide headless builds of the workspace, performed just as if Eclipse
should have done it from the IDE. In addition, we also provide headless
exports of bundles, features, products, and with a little work, update
sites.

Kind Regards,
Thomas Hallgren


Alex Chatziparaskewas wrote:
> Hi All
>
> The question below has already been posted to the eclipse platform
> newsgroup
> ( http://www.eclipse.org/newsportal/article.php?id=79883&g roup=eclipse.platform#79883)
> However, no replys yet.
> However, in the meantime I have received a hint that my problem could
> eventually be solved with buckminster. Big question is now: Is that hint
> true?
>
> Thanks in Advance & Kind Regards
> Alex
>
> -------------------------
> original posting:
>
> I have the following problem: I have written a custom builder/nature for
> Eclipse, which allows incrementally building a 'custom langugage'. This
> all works quite nicely and was relatively simple. Now we require this
> build to be able to be run headlessly though. However, the currently
> written build infrastructure has dependencies to various Eclipse IDE
> concepts, e.g. resources, projects, the 'workspace functionality'. At
> the moment I only see two (not so much appealing) solutions:
>
> a) Write a custom 'Eclipse Application', which starts the Eclipse IDE
> (without any UI), creates an empty workspace somewhere, loads the poject
> to be built 'headlessly' into the workspace, triggers the build and
> terminates the entire crap once the build is finished.
>
> b) Remove all dependencies to any of the used Eclipse concepts from the
> current implementation (in some way), enabling it to run as a simple
> Java application.
>
> Big question is now: Which path to take? Are there any alternatives or
> better solutions to this problem?
>
> I would be greatful for any advice (or examples!).
>
>
>
Re: Headless Build for Custom Builder [message #31186 is a reply to message #31151] Tue, 03 February 2009 08:30 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: alex.chatziparaskewas.continental-corporation.com

Hi Thomas

Thanks for that valueable piece of information. I will look into using
buckminster headlessly now.

Regards
Alex
Re: Headless Build for Custom Builder [message #31220 is a reply to message #31151] Tue, 03 February 2009 09:11 Go to previous messageGo to next message
Achim Demelt is currently offline Achim DemeltFriend
Messages: 160
Registered: July 2009
Senior Member
Hi Alex,

We also have a custom builder in our projects, and yes, Buckminster is the
way to go for this kind of build automation. Here are some things to keep in
mind, though:

1) The first step of build automation would probably be to build the builder
projects themselves. This will require a standard Buckminster headless
setup. The Wiki should have some documentation for this. You can use
Buckminster to compile and package the plug-ins and features, and you will
probably also want to build an update site for it.

2) Be sure to define a feature that contains your builder plug-in(s) and all
its prerequisite plug-ins (e.g. EMF, antlr, etc.). Double check that your
builder code does not contain any UI-related code (i.e. using SWT, JFace,
etc.). Workspace concepts and such are ok, of course, but any UI code will
pull in a number of UI-related bundles which you probably don't want to have
in a headless build setup.

3) *After* you have built your builder plug-ins, you need to install them
into your Buckminster headless product. You can do this by using the
"buckminster install" command. This, however, requires your builder plug-ins
to be on an update site, which you have built in step 1).

4) Only now can you build projects that *use* your custom builder as part of
their build process.

While this may sound a little complicated at first, always think of the
analogy of working interactively with Eclipse: When starting from scratch,
you have a standard Eclipse installation where you code and compile your
builder projects. When these are ready, you deploy them into your Eclipse
IDE, and only then can you create projects that use your builder. Just
having all projects in the same workspace isn't enough. The builder has to
be installed in order to work.

Oh, yes, and after your build is finished, you may want to "buckminster
uninstall" your builder feature, so that your subsequent build won't be
tainted by remains of the previous build.

I hope this helps avoid some of the pitfalls we encountered when setting up
our automated build.

Regards,
Achim

Thomas Hallgren wrote:

> Hi Alex,
> I think this sounds like a good match for Buckminster. We do indeed
> provide headless builds of the workspace, performed just as if Eclipse
> should have done it from the IDE. In addition, we also provide headless
> exports of bundles, features, products, and with a little work, update
> sites.
>
> Kind Regards,
> Thomas Hallgren
>
>
> Alex Chatziparaskewas wrote:
>> Hi All
>>
>> The question below has already been posted to the eclipse platform
>> newsgroup
>>
( http://www.eclipse.org/newsportal/article.php?id=79883&g roup=eclipse.platform#79883)
>> However, no replys yet.
>> However, in the meantime I have received a hint that my problem could
>> eventually be solved with buckminster. Big question is now: Is that hint
>> true?
>>
>> Thanks in Advance & Kind Regards
>> Alex
>>
>> -------------------------
>> original posting:
>>
>> I have the following problem: I have written a custom builder/nature for
>> Eclipse, which allows incrementally building a 'custom langugage'. This
>> all works quite nicely and was relatively simple. Now we require this
>> build to be able to be run headlessly though. However, the currently
>> written build infrastructure has dependencies to various Eclipse IDE
>> concepts, e.g. resources, projects, the 'workspace functionality'. At
>> the moment I only see two (not so much appealing) solutions:
>>
>> a) Write a custom 'Eclipse Application', which starts the Eclipse IDE
>> (without any UI), creates an empty workspace somewhere, loads the poject
>> to be built 'headlessly' into the workspace, triggers the build and
>> terminates the entire crap once the build is finished.
>>
>> b) Remove all dependencies to any of the used Eclipse concepts from the
>> current implementation (in some way), enabling it to run as a simple
>> Java application.
>>
>> Big question is now: Which path to take? Are there any alternatives or
>> better solutions to this problem?
>>
>> I would be greatful for any advice (or examples!).
>>
>>
>>
Re: Headless Build for Custom Builder [message #31256 is a reply to message #31220] Mon, 09 February 2009 13:03 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: alex.chatziparaskewas.continental-corporation.com

Hi Achim

Thanks for the feedback. The steps 1 to 4 as outlined sound completely
logical and I have in the meantime diggged deeper into headless
buckminster and buckminster in general (so far we have only been using to
for populating our workspace).

In terms of building something with buckminster, from what I understand
right now, there should be (almost) no difference in building a project
headlessly or via the 'Buckminster -> Invoke Action...' menu item. So
before setting up the complete headless buckminster process (including the
steps 1 to 4) I thought, let just try buckminster's action on my project.
However, while the project (a plugin project) with the custom builder
works perfectly when used through the Eclipse IDE, the custom builder is
not triggered by buckminster when its build action is run. Why?

I see log messages of the format:
[...:osgi.bundle$1.0.0.qualifier#OSGi#eclipse.build]
(whatever eclipse.build means)

I would have assumed that buckminster simply looks into the project's
definition, i.e. the project's natures/builders and triggers the same
build process as the Eclipse IDE does it. Do I have to somehow ammend the
project cspec, passing the information about the custom builder manually
to buckminster?

Thanks & Regards
Alex


exquisitus wrote:

> Hi Alex,

> We also have a custom builder in our projects, and yes, Buckminster is the
> way to go for this kind of build automation. Here are some things to keep in
> mind, though:

> 1) The first step of build automation would probably be to build the builder
> projects themselves. This will require a standard Buckminster headless
> setup. The Wiki should have some documentation for this. You can use
> Buckminster to compile and package the plug-ins and features, and you will
> probably also want to build an update site for it.

> 2) Be sure to define a feature that contains your builder plug-in(s) and all
> its prerequisite plug-ins (e.g. EMF, antlr, etc.). Double check that your
> builder code does not contain any UI-related code (i.e. using SWT, JFace,
> etc.). Workspace concepts and such are ok, of course, but any UI code will
> pull in a number of UI-related bundles which you probably don't want to have
> in a headless build setup.

> 3) *After* you have built your builder plug-ins, you need to install them
> into your Buckminster headless product. You can do this by using the
> "buckminster install" command. This, however, requires your builder plug-ins
> to be on an update site, which you have built in step 1).

> 4) Only now can you build projects that *use* your custom builder as part of
> their build process.

> While this may sound a little complicated at first, always think of the
> analogy of working interactively with Eclipse: When starting from scratch,
> you have a standard Eclipse installation where you code and compile your
> builder projects. When these are ready, you deploy them into your Eclipse
> IDE, and only then can you create projects that use your builder. Just
> having all projects in the same workspace isn't enough. The builder has to
> be installed in order to work.

> Oh, yes, and after your build is finished, you may want to "buckminster
> uninstall" your builder feature, so that your subsequent build won't be
> tainted by remains of the previous build.

> I hope this helps avoid some of the pitfalls we encountered when setting up
> our automated build.

> Regards,
> Achim

> Thomas Hallgren wrote:

>> Hi Alex,
>> I think this sounds like a good match for Buckminster. We do indeed
>> provide headless builds of the workspace, performed just as if Eclipse
>> should have done it from the IDE. In addition, we also provide headless
>> exports of bundles, features, products, and with a little work, update
>> sites.
>>
>> Kind Regards,
>> Thomas Hallgren
>>
>>
>> Alex Chatziparaskewas wrote:
>>> Hi All
>>>
>>> The question below has already been posted to the eclipse platform
>>> newsgroup
>>>
>
( http://www.eclipse.org/newsportal/article.php?id=79883&g roup=eclipse.platform#79883)
>>> However, no replys yet.
>>> However, in the meantime I have received a hint that my problem could
>>> eventually be solved with buckminster. Big question is now: Is that hint
>>> true?
>>>
>>> Thanks in Advance & Kind Regards
>>> Alex
>>>
>>> -------------------------
>>> original posting:
>>>
>>> I have the following problem: I have written a custom builder/nature for
>>> Eclipse, which allows incrementally building a 'custom langugage'. This
>>> all works quite nicely and was relatively simple. Now we require this
>>> build to be able to be run headlessly though. However, the currently
>>> written build infrastructure has dependencies to various Eclipse IDE
>>> concepts, e.g. resources, projects, the 'workspace functionality'. At
>>> the moment I only see two (not so much appealing) solutions:
>>>
>>> a) Write a custom 'Eclipse Application', which starts the Eclipse IDE
>>> (without any UI), creates an empty workspace somewhere, loads the poject
>>> to be built 'headlessly' into the workspace, triggers the build and
>>> terminates the entire crap once the build is finished.
>>>
>>> b) Remove all dependencies to any of the used Eclipse concepts from the
>>> current implementation (in some way), enabling it to run as a simple
>>> Java application.
>>>
>>> Big question is now: Which path to take? Are there any alternatives or
>>> better solutions to this problem?
>>>
>>> I would be greatful for any advice (or examples!).
>>>
>>>
>>>
Re: Headless Build for Custom Builder [message #31316 is a reply to message #31256] Tue, 10 February 2009 08:45 Go to previous messageGo to next message
Achim Demelt is currently offline Achim DemeltFriend
Messages: 160
Registered: July 2009
Senior Member
Hi Alex,

To be honest, I've never built a project with a custom builder using a
Buckminster action interactively. Your report made me curious, so I tried it
out. I was surprised to find out that, indeed, the custom builder was not
invoked.

I can reassure you that in our headless Buckminster build, all custom
builders are called. I don't know why there is a difference between headless
and interactive Buckminster. We're using a slightly older version of
Buckmisnter for our headless build, so maybe it is a bug that was introduced
in some recent version.

Perhaps Thomas can shed some light on this?

Achim

Alex Chatziparaskewas wrote:

> Hi Achim
>
> Thanks for the feedback. The steps 1 to 4 as outlined sound completely
> logical and I have in the meantime diggged deeper into headless
> buckminster and buckminster in general (so far we have only been using to
> for populating our workspace).
>
> In terms of building something with buckminster, from what I understand
> right now, there should be (almost) no difference in building a project
> headlessly or via the 'Buckminster -> Invoke Action...' menu item. So
> before setting up the complete headless buckminster process (including the
> steps 1 to 4) I thought, let just try buckminster's action on my project.
> However, while the project (a plugin project) with the custom builder
> works perfectly when used through the Eclipse IDE, the custom builder is
> not triggered by buckminster when its build action is run. Why?
>
> I see log messages of the format:
> [...:osgi.bundle$1.0.0.qualifier#OSGi#eclipse.build]
> (whatever eclipse.build means)
>
> I would have assumed that buckminster simply looks into the project's
> definition, i.e. the project's natures/builders and triggers the same
> build process as the Eclipse IDE does it. Do I have to somehow ammend the
> project cspec, passing the information about the custom builder manually
> to buckminster?
>
> Thanks & Regards
> Alex
>
>
> exquisitus wrote:
>
>> Hi Alex,
>
>> We also have a custom builder in our projects, and yes, Buckminster is
>> the way to go for this kind of build automation. Here are some things to
>> keep in mind, though:
>
>> 1) The first step of build automation would probably be to build the
>> builder projects themselves. This will require a standard Buckminster
>> headless setup. The Wiki should have some documentation for this. You can
>> use Buckminster to compile and package the plug-ins and features, and you
>> will probably also want to build an update site for it.
>
>> 2) Be sure to define a feature that contains your builder plug-in(s) and
>> all its prerequisite plug-ins (e.g. EMF, antlr, etc.). Double check that
>> your builder code does not contain any UI-related code (i.e. using SWT,
>> JFace, etc.). Workspace concepts and such are ok, of course, but any UI
>> code will pull in a number of UI-related bundles which you probably don't
>> want to have in a headless build setup.
>
>> 3) *After* you have built your builder plug-ins, you need to install them
>> into your Buckminster headless product. You can do this by using the
>> "buckminster install" command. This, however, requires your builder
>> plug-ins to be on an update site, which you have built in step 1).
>
>> 4) Only now can you build projects that *use* your custom builder as part
>> of their build process.
>
>> While this may sound a little complicated at first, always think of the
>> analogy of working interactively with Eclipse: When starting from
>> scratch, you have a standard Eclipse installation where you code and
>> compile your builder projects. When these are ready, you deploy them into
>> your Eclipse IDE, and only then can you create projects that use your
>> builder. Just having all projects in the same workspace isn't enough. The
>> builder has to be installed in order to work.
>
>> Oh, yes, and after your build is finished, you may want to "buckminster
>> uninstall" your builder feature, so that your subsequent build won't be
>> tainted by remains of the previous build.
>
>> I hope this helps avoid some of the pitfalls we encountered when setting
>> up our automated build.
>
>> Regards,
>> Achim
>
>> Thomas Hallgren wrote:
>
>>> Hi Alex,
>>> I think this sounds like a good match for Buckminster. We do indeed
>>> provide headless builds of the workspace, performed just as if Eclipse
>>> should have done it from the IDE. In addition, we also provide headless
>>> exports of bundles, features, products, and with a little work, update
>>> sites.
>>>
>>> Kind Regards,
>>> Thomas Hallgren
>>>
>>>
>>> Alex Chatziparaskewas wrote:
>>>> Hi All
>>>>
>>>> The question below has already been posted to the eclipse platform
>>>> newsgroup
>>>>
>>
>
( http://www.eclipse.org/newsportal/article.php?id=79883&g roup=eclipse.platform#79883)
>>>> However, no replys yet.
>>>> However, in the meantime I have received a hint that my problem could
>>>> eventually be solved with buckminster. Big question is now: Is that
>>>> hint true?
>>>>
>>>> Thanks in Advance & Kind Regards
>>>> Alex
>>>>
>>>> -------------------------
>>>> original posting:
>>>>
>>>> I have the following problem: I have written a custom builder/nature
>>>> for Eclipse, which allows incrementally building a 'custom langugage'.
>>>> This all works quite nicely and was relatively simple. Now we require
>>>> this build to be able to be run headlessly though. However, the
>>>> currently written build infrastructure has dependencies to various
>>>> Eclipse IDE concepts, e.g. resources, projects, the 'workspace
>>>> functionality'. At the moment I only see two (not so much appealing)
>>>> solutions:
>>>>
>>>> a) Write a custom 'Eclipse Application', which starts the Eclipse IDE
>>>> (without any UI), creates an empty workspace somewhere, loads the
>>>> poject to be built 'headlessly' into the workspace, triggers the build
>>>> and terminates the entire crap once the build is finished.
>>>>
>>>> b) Remove all dependencies to any of the used Eclipse concepts from the
>>>> current implementation (in some way), enabling it to run as a simple
>>>> Java application.
>>>>
>>>> Big question is now: Which path to take? Are there any alternatives or
>>>> better solutions to this problem?
>>>>
>>>> I would be greatful for any advice (or examples!).
>>>>
>>>>
>>>>
Re: Headless Build for Custom Builder [message #31397 is a reply to message #31316] Tue, 10 February 2009 09:29 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Alex and Achim,
Buckminster will indeed just invoke the Eclipse builder. We never parse
any .project files or such. That's all up to the builder so the custom
builder should indeed be invoked the same way in headless mode and this
should be considered a bug.

I would very much appreciate if someone could take the time to report
this in our bugzilla and attach a test-case.

Regards,
Thomas Hallgren


Achim Demelt wrote:
> Hi Alex,
>
> To be honest, I've never built a project with a custom builder using a
> Buckminster action interactively. Your report made me curious, so I tried it
> out. I was surprised to find out that, indeed, the custom builder was not
> invoked.
>
> I can reassure you that in our headless Buckminster build, all custom
> builders are called. I don't know why there is a difference between headless
> and interactive Buckminster. We're using a slightly older version of
> Buckmisnter for our headless build, so maybe it is a bug that was introduced
> in some recent version.
>
> Perhaps Thomas can shed some light on this?
>
> Achim
>
> Alex Chatziparaskewas wrote:
>
>> Hi Achim
>>
>> Thanks for the feedback. The steps 1 to 4 as outlined sound completely
>> logical and I have in the meantime diggged deeper into headless
>> buckminster and buckminster in general (so far we have only been using to
>> for populating our workspace).
>>
>> In terms of building something with buckminster, from what I understand
>> right now, there should be (almost) no difference in building a project
>> headlessly or via the 'Buckminster -> Invoke Action...' menu item. So
>> before setting up the complete headless buckminster process (including the
>> steps 1 to 4) I thought, let just try buckminster's action on my project.
>> However, while the project (a plugin project) with the custom builder
>> works perfectly when used through the Eclipse IDE, the custom builder is
>> not triggered by buckminster when its build action is run. Why?
>>
>> I see log messages of the format:
>> [...:osgi.bundle$1.0.0.qualifier#OSGi#eclipse.build]
>> (whatever eclipse.build means)
>>
>> I would have assumed that buckminster simply looks into the project's
>> definition, i.e. the project's natures/builders and triggers the same
>> build process as the Eclipse IDE does it. Do I have to somehow ammend the
>> project cspec, passing the information about the custom builder manually
>> to buckminster?
>>
>> Thanks & Regards
>> Alex
>>
>>
>> exquisitus wrote:
>>
>>> Hi Alex,
>>> We also have a custom builder in our projects, and yes, Buckminster is
>>> the way to go for this kind of build automation. Here are some things to
>>> keep in mind, though:
>>> 1) The first step of build automation would probably be to build the
>>> builder projects themselves. This will require a standard Buckminster
>>> headless setup. The Wiki should have some documentation for this. You can
>>> use Buckminster to compile and package the plug-ins and features, and you
>>> will probably also want to build an update site for it.
>>> 2) Be sure to define a feature that contains your builder plug-in(s) and
>>> all its prerequisite plug-ins (e.g. EMF, antlr, etc.). Double check that
>>> your builder code does not contain any UI-related code (i.e. using SWT,
>>> JFace, etc.). Workspace concepts and such are ok, of course, but any UI
>>> code will pull in a number of UI-related bundles which you probably don't
>>> want to have in a headless build setup.
>>> 3) *After* you have built your builder plug-ins, you need to install them
>>> into your Buckminster headless product. You can do this by using the
>>> "buckminster install" command. This, however, requires your builder
>>> plug-ins to be on an update site, which you have built in step 1).
>>> 4) Only now can you build projects that *use* your custom builder as part
>>> of their build process.
>>> While this may sound a little complicated at first, always think of the
>>> analogy of working interactively with Eclipse: When starting from
>>> scratch, you have a standard Eclipse installation where you code and
>>> compile your builder projects. When these are ready, you deploy them into
>>> your Eclipse IDE, and only then can you create projects that use your
>>> builder. Just having all projects in the same workspace isn't enough. The
>>> builder has to be installed in order to work.
>>> Oh, yes, and after your build is finished, you may want to "buckminster
>>> uninstall" your builder feature, so that your subsequent build won't be
>>> tainted by remains of the previous build.
>>> I hope this helps avoid some of the pitfalls we encountered when setting
>>> up our automated build.
>>> Regards,
>>> Achim
>>> Thomas Hallgren wrote:
>>>> Hi Alex,
>>>> I think this sounds like a good match for Buckminster. We do indeed
>>>> provide headless builds of the workspace, performed just as if Eclipse
>>>> should have done it from the IDE. In addition, we also provide headless
>>>> exports of bundles, features, products, and with a little work, update
>>>> sites.
>>>>
>>>> Kind Regards,
>>>> Thomas Hallgren
>>>>
>>>>
>>>> Alex Chatziparaskewas wrote:
>>>>> Hi All
>>>>>
>>>>> The question below has already been posted to the eclipse platform
>>>>> newsgroup
>>>>>
> ( http://www.eclipse.org/newsportal/article.php?id=79883&g roup=eclipse.platform#79883)
>>>>> However, no replys yet.
>>>>> However, in the meantime I have received a hint that my problem could
>>>>> eventually be solved with buckminster. Big question is now: Is that
>>>>> hint true?
>>>>>
>>>>> Thanks in Advance & Kind Regards
>>>>> Alex
>>>>>
>>>>> -------------------------
>>>>> original posting:
>>>>>
>>>>> I have the following problem: I have written a custom builder/nature
>>>>> for Eclipse, which allows incrementally building a 'custom langugage'.
>>>>> This all works quite nicely and was relatively simple. Now we require
>>>>> this build to be able to be run headlessly though. However, the
>>>>> currently written build infrastructure has dependencies to various
>>>>> Eclipse IDE concepts, e.g. resources, projects, the 'workspace
>>>>> functionality'. At the moment I only see two (not so much appealing)
>>>>> solutions:
>>>>>
>>>>> a) Write a custom 'Eclipse Application', which starts the Eclipse IDE
>>>>> (without any UI), creates an empty workspace somewhere, loads the
>>>>> poject to be built 'headlessly' into the workspace, triggers the build
>>>>> and terminates the entire crap once the build is finished.
>>>>>
>>>>> b) Remove all dependencies to any of the used Eclipse concepts from the
>>>>> current implementation (in some way), enabling it to run as a simple
>>>>> Java application.
>>>>>
>>>>> Big question is now: Which path to take? Are there any alternatives or
>>>>> better solutions to this problem?
>>>>>
>>>>> I would be greatful for any advice (or examples!).
>>>>>
>>>>>
>>>>>
>
>
Re: Headless Build for Custom Builder [message #31411 is a reply to message #31397] Tue, 10 February 2009 13:16 Go to previous messageGo to next message
Achim Demelt is currently offline Achim DemeltFriend
Messages: 160
Registered: July 2009
Senior Member
Well, it's fine in headless mode. It's just when invoking the action
interactively that the builder seems to be skipped.

I investigated a little more. It seems that invoking the "bundle.jar"
action, which claims to execute an "eclipse.build" action, does not trigger
any builder at all. Not even the Java builder. It merely packages the bundle
JAR file. The "buckminster.clean" action, however, does invoke all builders,
including any custom builder. Alex, can you confirm this?

I'm not sure if this is the intended behavior. I will file a bug if it
isn't.

Achim

Thomas Hallgren wrote:

> Hi Alex and Achim,
> Buckminster will indeed just invoke the Eclipse builder. We never parse
> any .project files or such. That's all up to the builder so the custom
> builder should indeed be invoked the same way in headless mode and this
> should be considered a bug.
>
> I would very much appreciate if someone could take the time to report
> this in our bugzilla and attach a test-case.
>
> Regards,
> Thomas Hallgren
>
>
> Achim Demelt wrote:
>> Hi Alex,
>>
>> To be honest, I've never built a project with a custom builder using a
>> Buckminster action interactively. Your report made me curious, so I tried
>> it out. I was surprised to find out that, indeed, the custom builder was
>> not invoked.
>>
>> I can reassure you that in our headless Buckminster build, all custom
>> builders are called. I don't know why there is a difference between
>> headless and interactive Buckminster. We're using a slightly older
>> version of Buckmisnter for our headless build, so maybe it is a bug that
>> was introduced in some recent version.
>>
>> Perhaps Thomas can shed some light on this?
>>
>> Achim
>>
>> Alex Chatziparaskewas wrote:
>>
>>> Hi Achim
>>>
>>> Thanks for the feedback. The steps 1 to 4 as outlined sound completely
>>> logical and I have in the meantime diggged deeper into headless
>>> buckminster and buckminster in general (so far we have only been using
>>> to for populating our workspace).
>>>
>>> In terms of building something with buckminster, from what I understand
>>> right now, there should be (almost) no difference in building a project
>>> headlessly or via the 'Buckminster -> Invoke Action...' menu item. So
>>> before setting up the complete headless buckminster process (including
>>> the steps 1 to 4) I thought, let just try buckminster's action on my
>>> project. However, while the project (a plugin project) with the custom
>>> builder works perfectly when used through the Eclipse IDE, the custom
>>> builder is not triggered by buckminster when its build action is run.
>>> Why?
>>>
>>> I see log messages of the format:
>>> [...:osgi.bundle$1.0.0.qualifier#OSGi#eclipse.build]
>>> (whatever eclipse.build means)
>>>
>>> I would have assumed that buckminster simply looks into the project's
>>> definition, i.e. the project's natures/builders and triggers the same
>>> build process as the Eclipse IDE does it. Do I have to somehow ammend
>>> the project cspec, passing the information about the custom builder
>>> manually to buckminster?
>>>
>>> Thanks & Regards
>>> Alex
>>>
>>>
>>> exquisitus wrote:
>>>
>>>> Hi Alex,
>>>> We also have a custom builder in our projects, and yes, Buckminster is
>>>> the way to go for this kind of build automation. Here are some things
>>>> to keep in mind, though:
>>>> 1) The first step of build automation would probably be to build the
>>>> builder projects themselves. This will require a standard Buckminster
>>>> headless setup. The Wiki should have some documentation for this. You
>>>> can use Buckminster to compile and package the plug-ins and features,
>>>> and you will probably also want to build an update site for it.
>>>> 2) Be sure to define a feature that contains your builder plug-in(s)
>>>> and all its prerequisite plug-ins (e.g. EMF, antlr, etc.). Double check
>>>> that your builder code does not contain any UI-related code (i.e. using
>>>> SWT, JFace, etc.). Workspace concepts and such are ok, of course, but
>>>> any UI code will pull in a number of UI-related bundles which you
>>>> probably don't want to have in a headless build setup.
>>>> 3) *After* you have built your builder plug-ins, you need to install
>>>> them into your Buckminster headless product. You can do this by using
>>>> the "buckminster install" command. This, however, requires your builder
>>>> plug-ins to be on an update site, which you have built in step 1).
>>>> 4) Only now can you build projects that *use* your custom builder as
>>>> part of their build process.
>>>> While this may sound a little complicated at first, always think of the
>>>> analogy of working interactively with Eclipse: When starting from
>>>> scratch, you have a standard Eclipse installation where you code and
>>>> compile your builder projects. When these are ready, you deploy them
>>>> into your Eclipse IDE, and only then can you create projects that use
>>>> your builder. Just having all projects in the same workspace isn't
>>>> enough. The builder has to be installed in order to work.
>>>> Oh, yes, and after your build is finished, you may want to "buckminster
>>>> uninstall" your builder feature, so that your subsequent build won't be
>>>> tainted by remains of the previous build.
>>>> I hope this helps avoid some of the pitfalls we encountered when
>>>> setting up our automated build.
>>>> Regards,
>>>> Achim
>>>> Thomas Hallgren wrote:
>>>>> Hi Alex,
>>>>> I think this sounds like a good match for Buckminster. We do indeed
>>>>> provide headless builds of the workspace, performed just as if Eclipse
>>>>> should have done it from the IDE. In addition, we also provide
>>>>> headless exports of bundles, features, products, and with a little
>>>>> work, update sites.
>>>>>
>>>>> Kind Regards,
>>>>> Thomas Hallgren
>>>>>
>>>>>
>>>>> Alex Chatziparaskewas wrote:
>>>>>> Hi All
>>>>>>
>>>>>> The question below has already been posted to the eclipse platform
>>>>>> newsgroup
>>>>>>
>>
( http://www.eclipse.org/newsportal/article.php?id=79883&g roup=eclipse.platform#79883)
>>>>>> However, no replys yet.
>>>>>> However, in the meantime I have received a hint that my problem could
>>>>>> eventually be solved with buckminster. Big question is now: Is that
>>>>>> hint true?
>>>>>>
>>>>>> Thanks in Advance & Kind Regards
>>>>>> Alex
>>>>>>
>>>>>> -------------------------
>>>>>> original posting:
>>>>>>
>>>>>> I have the following problem: I have written a custom builder/nature
>>>>>> for Eclipse, which allows incrementally building a 'custom
>>>>>> langugage'. This all works quite nicely and was relatively simple.
>>>>>> Now we require this build to be able to be run headlessly though.
>>>>>> However, the currently written build infrastructure has dependencies
>>>>>> to various Eclipse IDE concepts, e.g. resources, projects, the
>>>>>> 'workspace functionality'. At the moment I only see two (not so much
>>>>>> appealing) solutions:
>>>>>>
>>>>>> a) Write a custom 'Eclipse Application', which starts the Eclipse IDE
>>>>>> (without any UI), creates an empty workspace somewhere, loads the
>>>>>> poject to be built 'headlessly' into the workspace, triggers the
>>>>>> build and terminates the entire crap once the build is finished.
>>>>>>
>>>>>> b) Remove all dependencies to any of the used Eclipse concepts from
>>>>>> the current implementation (in some way), enabling it to run as a
>>>>>> simple Java application.
>>>>>>
>>>>>> Big question is now: Which path to take? Are there any alternatives
>>>>>> or better solutions to this problem?
>>>>>>
>>>>>> I would be greatful for any advice (or examples!).
>>>>>>
>>>>>>
>>>>>>
>>
>>
Re: Headless Build for Custom Builder [message #31580 is a reply to message #31411] Wed, 11 February 2009 10:29 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: alex.chatziparaskewas.continental-corporation.com

Hi All

New day, new luck. I tried it again. The 'custom' builder stuff now works
from the command line as well as using through the UI. Do not ask me why
it did not work yesterday. What I did though before testing it again
ensuring something happens (and is not 'optimized' away): I disabled
Eclipse's autobuild, I called buckminster.clean, I called whether target.

So currently, I am very happy.

Regards
Alex

PS: I have never read it anywhere, this ability of buckminster to
facilitate the IDE adds another 'pro buckminster' over the
use/implementation of a classic command line build (e.g. maven, ant; and I
think it is a strong argument): There is always the project, which needs a
'custom ant' builder or a more sophistaced version of a custom builder, or
some other thing, the 'standard project' does not provide out of the box.
In the classic approach, any solutions to these problems have to be
implemented twice - in the command line build and in the IDE (if provided
in the IDE at all). Buckminster only requires everything to be done
through the IDE. It would be a more consequent implementation of a 'one
source for the build' approach.

Achim Demelt wrote:

> Well, it's fine in headless mode. It's just when invoking the action
> interactively that the builder seems to be skipped.

> I investigated a little more. It seems that invoking the "bundle.jar"
> action, which claims to execute an "eclipse.build" action, does not trigger
> any builder at all. Not even the Java builder. It merely packages the bundle
> JAR file. The "buckminster.clean" action, however, does invoke all builders,
> including any custom builder. Alex, can you confirm this?

> I'm not sure if this is the intended behavior. I will file a bug if it
> isn't.

> Achim

> Thomas Hallgren wrote:

>> Hi Alex and Achim,
>> Buckminster will indeed just invoke the Eclipse builder. We never parse
>> any .project files or such. That's all up to the builder so the custom
>> builder should indeed be invoked the same way in headless mode and this
>> should be considered a bug.
>>
>> I would very much appreciate if someone could take the time to report
>> this in our bugzilla and attach a test-case.
>>
>> Regards,
>> Thomas Hallgren
>>
>>
>> Achim Demelt wrote:
>>> Hi Alex,
>>>
>>> To be honest, I've never built a project with a custom builder using a
>>> Buckminster action interactively. Your report made me curious, so I tried
>>> it out. I was surprised to find out that, indeed, the custom builder was
>>> not invoked.
>>>
>>> I can reassure you that in our headless Buckminster build, all custom
>>> builders are called. I don't know why there is a difference between
>>> headless and interactive Buckminster. We're using a slightly older
>>> version of Buckmisnter for our headless build, so maybe it is a bug that
>>> was introduced in some recent version.
>>>
>>> Perhaps Thomas can shed some light on this?
>>>
>>> Achim
>>>
>>> Alex Chatziparaskewas wrote:
>>>
>>>> Hi Achim
>>>>
>>>> Thanks for the feedback. The steps 1 to 4 as outlined sound completely
>>>> logical and I have in the meantime diggged deeper into headless
>>>> buckminster and buckminster in general (so far we have only been using
>>>> to for populating our workspace).
>>>>
>>>> In terms of building something with buckminster, from what I understand
>>>> right now, there should be (almost) no difference in building a project
>>>> headlessly or via the 'Buckminster -> Invoke Action...' menu item. So
>>>> before setting up the complete headless buckminster process (including
>>>> the steps 1 to 4) I thought, let just try buckminster's action on my
>>>> project. However, while the project (a plugin project) with the custom
>>>> builder works perfectly when used through the Eclipse IDE, the custom
>>>> builder is not triggered by buckminster when its build action is run.
>>>> Why?
>>>>
>>>> I see log messages of the format:
>>>> [...:osgi.bundle$1.0.0.qualifier#OSGi#eclipse.build]
>>>> (whatever eclipse.build means)
>>>>
>>>> I would have assumed that buckminster simply looks into the project's
>>>> definition, i.e. the project's natures/builders and triggers the same
>>>> build process as the Eclipse IDE does it. Do I have to somehow ammend
>>>> the project cspec, passing the information about the custom builder
>>>> manually to buckminster?
>>>>
>>>> Thanks & Regards
>>>> Alex
>>>>
>>>>
>>>> exquisitus wrote:
>>>>
>>>>> Hi Alex,
>>>>> We also have a custom builder in our projects, and yes, Buckminster is
>>>>> the way to go for this kind of build automation. Here are some things
>>>>> to keep in mind, though:
>>>>> 1) The first step of build automation would probably be to build the
>>>>> builder projects themselves. This will require a standard Buckminster
>>>>> headless setup. The Wiki should have some documentation for this. You
>>>>> can use Buckminster to compile and package the plug-ins and features,
>>>>> and you will probably also want to build an update site for it.
>>>>> 2) Be sure to define a feature that contains your builder plug-in(s)
>>>>> and all its prerequisite plug-ins (e.g. EMF, antlr, etc.). Double check
>>>>> that your builder code does not contain any UI-related code (i.e. using
>>>>> SWT, JFace, etc.). Workspace concepts and such are ok, of course, but
>>>>> any UI code will pull in a number of UI-related bundles which you
>>>>> probably don't want to have in a headless build setup.
>>>>> 3) *After* you have built your builder plug-ins, you need to install
>>>>> them into your Buckminster headless product. You can do this by using
>>>>> the "buckminster install" command. This, however, requires your builder
>>>>> plug-ins to be on an update site, which you have built in step 1).
>>>>> 4) Only now can you build projects that *use* your custom builder as
>>>>> part of their build process.
>>>>> While this may sound a little complicated at first, always think of the
>>>>> analogy of working interactively with Eclipse: When starting from
>>>>> scratch, you have a standard Eclipse installation where you code and
>>>>> compile your builder projects. When these are ready, you deploy them
>>>>> into your Eclipse IDE, and only then can you create projects that use
>>>>> your builder. Just having all projects in the same workspace isn't
>>>>> enough. The builder has to be installed in order to work.
>>>>> Oh, yes, and after your build is finished, you may want to "buckminster
>>>>> uninstall" your builder feature, so that your subsequent build won't be
>>>>> tainted by remains of the previous build.
>>>>> I hope this helps avoid some of the pitfalls we encountered when
>>>>> setting up our automated build.
>>>>> Regards,
>>>>> Achim
>>>>> Thomas Hallgren wrote:
>>>>>> Hi Alex,
>>>>>> I think this sounds like a good match for Buckminster. We do indeed
>>>>>> provide headless builds of the workspace, performed just as if Eclipse
>>>>>> should have done it from the IDE. In addition, we also provide
>>>>>> headless exports of bundles, features, products, and with a little
>>>>>> work, update sites.
>>>>>>
>>>>>> Kind Regards,
>>>>>> Thomas Hallgren
>>>>>>
>>>>>>
>>>>>> Alex Chatziparaskewas wrote:
>>>>>>> Hi All
>>>>>>>
>>>>>>> The question below has already been posted to the eclipse platform
>>>>>>> newsgroup
>>>>>>>
>>>
>
( http://www.eclipse.org/newsportal/article.php?id=79883&g roup=eclipse.platform#79883)
>>>>>>> However, no replys yet.
>>>>>>> However, in the meantime I have received a hint that my problem could
>>>>>>> eventually be solved with buckminster. Big question is now: Is that
>>>>>>> hint true?
>>>>>>>
>>>>>>> Thanks in Advance & Kind Regards
>>>>>>> Alex
>>>>>>>
>>>>>>> -------------------------
>>>>>>> original posting:
>>>>>>>
>>>>>>> I have the following problem: I have written a custom builder/nature
>>>>>>> for Eclipse, which allows incrementally building a 'custom
>>>>>>> langugage'. This all works quite nicely and was relatively simple.
>>>>>>> Now we require this build to be able to be run headlessly though.
>>>>>>> However, the currently written build infrastructure has dependencies
>>>>>>> to various Eclipse IDE concepts, e.g. resources, projects, the
>>>>>>> 'workspace functionality'. At the moment I only see two (not so much
>>>>>>> appealing) solutions:
>>>>>>>
>>>>>>> a) Write a custom 'Eclipse Application', which starts the Eclipse IDE
>>>>>>> (without any UI), creates an empty workspace somewhere, loads the
>>>>>>> poject to be built 'headlessly' into the workspace, triggers the
>>>>>>> build and terminates the entire crap once the build is finished.
>>>>>>>
>>>>>>> b) Remove all dependencies to any of the used Eclipse concepts from
>>>>>>> the current implementation (in some way), enabling it to run as a
>>>>>>> simple Java application.
>>>>>>>
>>>>>>> Big question is now: Which path to take? Are there any alternatives
>>>>>>> or better solutions to this problem?
>>>>>>>
>>>>>>> I would be greatful for any advice (or examples!).
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
Re: Headless Build for Custom Builder [message #31615 is a reply to message #31580] Wed, 11 February 2009 19:20 Go to previous messageGo to next message
Achim Demelt is currently offline Achim DemeltFriend
Messages: 160
Registered: July 2009
Senior Member
Hi Alex,

That's good news!

As for your "PS" note: Yes, you're absolutely right. I also find the
"single-source-build" idea one of Buckminster's most compelling features.
Even more so since the exact same build steps are executed both
interactively and in headless mode. I always point out this fact whenever I
get the chance of talking about Buckminster. I hope Thomas and Henrik will
do the same in their upcoming talk at EclipseCon (hint, hint)

Achim

Alex Chatziparaskewas wrote:

> Hi All
>
> New day, new luck. I tried it again. The 'custom' builder stuff now works
> from the command line as well as using through the UI. Do not ask me why
> it did not work yesterday. What I did though before testing it again
> ensuring something happens (and is not 'optimized' away): I disabled
> Eclipse's autobuild, I called buckminster.clean, I called whether target.
>
> So currently, I am very happy.
>
> Regards
> Alex
>
> PS: I have never read it anywhere, this ability of buckminster to
> facilitate the IDE adds another 'pro buckminster' over the
> use/implementation of a classic command line build (e.g. maven, ant; and I
> think it is a strong argument): There is always the project, which needs a
> 'custom ant' builder or a more sophistaced version of a custom builder, or
> some other thing, the 'standard project' does not provide out of the box.
> In the classic approach, any solutions to these problems have to be
> implemented twice - in the command line build and in the IDE (if provided
> in the IDE at all). Buckminster only requires everything to be done
> through the IDE. It would be a more consequent implementation of a 'one
> source for the build' approach.
>
> Achim Demelt wrote:
>
>> Well, it's fine in headless mode. It's just when invoking the action
>> interactively that the builder seems to be skipped.
>
>> I investigated a little more. It seems that invoking the "bundle.jar"
>> action, which claims to execute an "eclipse.build" action, does not
>> trigger any builder at all. Not even the Java builder. It merely packages
>> the bundle JAR file. The "buckminster.clean" action, however, does invoke
>> all builders, including any custom builder. Alex, can you confirm this?
>
>> I'm not sure if this is the intended behavior. I will file a bug if it
>> isn't.
>
>> Achim
>
>> Thomas Hallgren wrote:
>
>>> Hi Alex and Achim,
>>> Buckminster will indeed just invoke the Eclipse builder. We never parse
>>> any .project files or such. That's all up to the builder so the custom
>>> builder should indeed be invoked the same way in headless mode and this
>>> should be considered a bug.
>>>
>>> I would very much appreciate if someone could take the time to report
>>> this in our bugzilla and attach a test-case.
>>>
>>> Regards,
>>> Thomas Hallgren
>>>
>>>
>>> Achim Demelt wrote:
>>>> Hi Alex,
>>>>
>>>> To be honest, I've never built a project with a custom builder using a
>>>> Buckminster action interactively. Your report made me curious, so I
>>>> tried it out. I was surprised to find out that, indeed, the custom
>>>> builder was not invoked.
>>>>
>>>> I can reassure you that in our headless Buckminster build, all custom
>>>> builders are called. I don't know why there is a difference between
>>>> headless and interactive Buckminster. We're using a slightly older
>>>> version of Buckmisnter for our headless build, so maybe it is a bug
>>>> that was introduced in some recent version.
>>>>
>>>> Perhaps Thomas can shed some light on this?
>>>>
>>>> Achim
>>>>
>>>> Alex Chatziparaskewas wrote:
>>>>
>>>>> Hi Achim
>>>>>
>>>>> Thanks for the feedback. The steps 1 to 4 as outlined sound completely
>>>>> logical and I have in the meantime diggged deeper into headless
>>>>> buckminster and buckminster in general (so far we have only been using
>>>>> to for populating our workspace).
>>>>>
>>>>> In terms of building something with buckminster, from what I
>>>>> understand right now, there should be (almost) no difference in
>>>>> building a project headlessly or via the 'Buckminster -> Invoke
>>>>> Action...' menu item. So before setting up the complete headless
>>>>> buckminster process (including the steps 1 to 4) I thought, let just
>>>>> try buckminster's action on my project. However, while the project (a
>>>>> plugin project) with the custom builder works perfectly when used
>>>>> through the Eclipse IDE, the custom builder is not triggered by
>>>>> buckminster when its build action is run. Why?
>>>>>
>>>>> I see log messages of the format:
>>>>> [...:osgi.bundle$1.0.0.qualifier#OSGi#eclipse.build]
>>>>> (whatever eclipse.build means)
>>>>>
>>>>> I would have assumed that buckminster simply looks into the project's
>>>>> definition, i.e. the project's natures/builders and triggers the same
>>>>> build process as the Eclipse IDE does it. Do I have to somehow ammend
>>>>> the project cspec, passing the information about the custom builder
>>>>> manually to buckminster?
>>>>>
>>>>> Thanks & Regards
>>>>> Alex
>>>>>
>>>>>
>>>>> exquisitus wrote:
>>>>>
>>>>>> Hi Alex,
>>>>>> We also have a custom builder in our projects, and yes, Buckminster
>>>>>> is the way to go for this kind of build automation. Here are some
>>>>>> things to keep in mind, though:
>>>>>> 1) The first step of build automation would probably be to build the
>>>>>> builder projects themselves. This will require a standard Buckminster
>>>>>> headless setup. The Wiki should have some documentation for this. You
>>>>>> can use Buckminster to compile and package the plug-ins and features,
>>>>>> and you will probably also want to build an update site for it.
>>>>>> 2) Be sure to define a feature that contains your builder plug-in(s)
>>>>>> and all its prerequisite plug-ins (e.g. EMF, antlr, etc.). Double
>>>>>> check that your builder code does not contain any UI-related code
>>>>>> (i.e. using SWT, JFace, etc.). Workspace concepts and such are ok, of
>>>>>> course, but any UI code will pull in a number of UI-related bundles
>>>>>> which you probably don't want to have in a headless build setup.
>>>>>> 3) *After* you have built your builder plug-ins, you need to install
>>>>>> them into your Buckminster headless product. You can do this by using
>>>>>> the "buckminster install" command. This, however, requires your
>>>>>> builder plug-ins to be on an update site, which you have built in
>>>>>> step 1). 4) Only now can you build projects that *use* your custom
>>>>>> builder as part of their build process.
>>>>>> While this may sound a little complicated at first, always think of
>>>>>> the analogy of working interactively with Eclipse: When starting from
>>>>>> scratch, you have a standard Eclipse installation where you code and
>>>>>> compile your builder projects. When these are ready, you deploy them
>>>>>> into your Eclipse IDE, and only then can you create projects that use
>>>>>> your builder. Just having all projects in the same workspace isn't
>>>>>> enough. The builder has to be installed in order to work.
>>>>>> Oh, yes, and after your build is finished, you may want to
>>>>>> "buckminster uninstall" your builder feature, so that your subsequent
>>>>>> build won't be tainted by remains of the previous build.
>>>>>> I hope this helps avoid some of the pitfalls we encountered when
>>>>>> setting up our automated build.
>>>>>> Regards,
>>>>>> Achim
>>>>>> Thomas Hallgren wrote:
>>>>>>> Hi Alex,
>>>>>>> I think this sounds like a good match for Buckminster. We do indeed
>>>>>>> provide headless builds of the workspace, performed just as if
>>>>>>> Eclipse should have done it from the IDE. In addition, we also
>>>>>>> provide headless exports of bundles, features, products, and with a
>>>>>>> little work, update sites.
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>> Thomas Hallgren
>>>>>>>
>>>>>>>
>>>>>>> Alex Chatziparaskewas wrote:
>>>>>>>> Hi All
>>>>>>>>
>>>>>>>> The question below has already been posted to the eclipse platform
>>>>>>>> newsgroup
>>>>>>>>
>>>>
>>
>
( http://www.eclipse.org/newsportal/article.php?id=79883&g roup=eclipse.platform#79883)
>>>>>>>> However, no replys yet.
>>>>>>>> However, in the meantime I have received a hint that my problem
>>>>>>>> could eventually be solved with buckminster. Big question is now:
>>>>>>>> Is that hint true?
>>>>>>>>
>>>>>>>> Thanks in Advance & Kind Regards
>>>>>>>> Alex
>>>>>>>>
>>>>>>>> -------------------------
>>>>>>>> original posting:
>>>>>>>>
>>>>>>>> I have the following problem: I have written a custom
>>>>>>>> builder/nature for Eclipse, which allows incrementally building a
>>>>>>>> 'custom langugage'. This all works quite nicely and was relatively
>>>>>>>> simple. Now we require this build to be able to be run headlessly
>>>>>>>> though. However, the currently written build infrastructure has
>>>>>>>> dependencies to various Eclipse IDE concepts, e.g. resources,
>>>>>>>> projects, the 'workspace functionality'. At the moment I only see
>>>>>>>> two (not so much appealing) solutions:
>>>>>>>>
>>>>>>>> a) Write a custom 'Eclipse Application', which starts the Eclipse
>>>>>>>> IDE (without any UI), creates an empty workspace somewhere, loads
>>>>>>>> the poject to be built 'headlessly' into the workspace, triggers
>>>>>>>> the build and terminates the entire crap once the build is
>>>>>>>> finished.
>>>>>>>>
>>>>>>>> b) Remove all dependencies to any of the used Eclipse concepts from
>>>>>>>> the current implementation (in some way), enabling it to run as a
>>>>>>>> simple Java application.
>>>>>>>>
>>>>>>>> Big question is now: Which path to take? Are there any alternatives
>>>>>>>> or better solutions to this problem?
>>>>>>>>
>>>>>>>> I would be greatful for any advice (or examples!).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>>>
Re: Headless Build for Custom Builder [message #31650 is a reply to message #31186] Thu, 12 February 2009 08:03 Go to previous messageGo to next message
Dann Martens is currently offline Dann MartensFriend
Messages: 65
Registered: July 2009
Member
Hi Alex,

On my previous project we started with specific custom Builders (the
Eclipse concept), but ended up with specialized Buckminster Actors for
packaging and 'version branding'.

If I'm not mistaken, the reason to do that has to do with the fact that
Builders are always run (in their specific stacked order), while with
the Actors you can work more target-specific (through a Buckminster
context menu, or the command line).

Best regards,
Dann

Alex Chatziparaskewas wrote:
> Hi Thomas
>
> Thanks for that valueable piece of information. I will look into using
> buckminster headlessly now.
>
> Regards
> Alex
>
Re: Headless Build for Custom Builder [message #31686 is a reply to message #31650] Tue, 17 February 2009 10:07 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi,
I agree with Dann. The primary objective for the builders defined in the
..project file is to keep the workspace in a consistent state at all
times. That means that those builders are triggered by events such as
when you save a file, check things out, or by the workspace automated
build timer.

Such builders are convenient when they can execute quickly since they
catch errors very early but they tend to become a nuisance when used for
time consuming tasks like creating archives, packaging etc. since you're
not in full control of when they execute.

Regards,
Thomas Hallgren


Dann Martens wrote:
> Hi Alex,
>
> On my previous project we started with specific custom Builders (the
> Eclipse concept), but ended up with specialized Buckminster Actors for
> packaging and 'version branding'.
>
> If I'm not mistaken, the reason to do that has to do with the fact that
> Builders are always run (in their specific stacked order), while with
> the Actors you can work more target-specific (through a Buckminster
> context menu, or the command line).
>
> Best regards,
> Dann
>
> Alex Chatziparaskewas wrote:
>> Hi Thomas
>>
>> Thanks for that valueable piece of information. I will look into using
>> buckminster headlessly now.
>>
>> Regards
>> Alex
>>
Re: Headless Build for Custom Builder [message #31721 is a reply to message #31686] Tue, 17 February 2009 15:15 Go to previous message
Achim Demelt is currently offline Achim DemeltFriend
Messages: 160
Registered: July 2009
Senior Member
Hi all,

I absolutely agree: Only the things you need for a consistent project should
be a builder. Code generators are probably the best example for this
category.

Thinking of Buckminster's "Build, Assembly & Deploy" paradigm, anything
related to assembly and deployment are better off as Actors instead of
builders.

Achim

Thomas Hallgren wrote:

> Hi,
> I agree with Dann. The primary objective for the builders defined in the
> .project file is to keep the workspace in a consistent state at all
> times. That means that those builders are triggered by events such as
> when you save a file, check things out, or by the workspace automated
> build timer.
>
> Such builders are convenient when they can execute quickly since they
> catch errors very early but they tend to become a nuisance when used for
> time consuming tasks like creating archives, packaging etc. since you're
> not in full control of when they execute.
>
> Regards,
> Thomas Hallgren
>
>
> Dann Martens wrote:
>> Hi Alex,
>>
>> On my previous project we started with specific custom Builders (the
>> Eclipse concept), but ended up with specialized Buckminster Actors for
>> packaging and 'version branding'.
>>
>> If I'm not mistaken, the reason to do that has to do with the fact that
>> Builders are always run (in their specific stacked order), while with
>> the Actors you can work more target-specific (through a Buckminster
>> context menu, or the command line).
>>
>> Best regards,
>> Dann
>>
>> Alex Chatziparaskewas wrote:
>>> Hi Thomas
>>>
>>> Thanks for that valueable piece of information. I will look into using
>>> buckminster headlessly now.
>>>
>>> Regards
>>> Alex
>>>
Previous Topic:P2 work on Buckminster
Next Topic:feature.exports coming up empty
Goto Forum:
  


Current Time: Tue Mar 19 06:37:19 GMT 2024

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

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

Back to the top