Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Buckminster » Target Platform and buckminster-headless: update, multiple with same name, rmtarget
Target Platform and buckminster-headless: update, multiple with same name, rmtarget [message #516749] Wed, 24 February 2010 23:59 Go to next message
Bernhard Merkle is currently offline Bernhard MerkleFriend
Messages: 88
Registered: July 2009
Member
I have the following questions about eclipse targets and
buckminster-headless (example, please see below)

1. If I update my.target in my Eclipse project do I have to _reimport_
this into my headless bucky ? (or do i only have to do it once and later
it is dome automatically ?)

2. Up to now I reimported my.target always after modification into
headless bucky. However this leads to multiple copies with the same name
(!) which is irritating IMO.. BTW. where are they stored.
Can I avoid the reimport step and what can I do againt the growing
number of nameequal entries ?

3. there is importtarget, lstargets, but no rmtarget "name".
Why ? is it not usefull ?

thanks,
Bernhard.

!ENTRY org.eclipse.buckminster.core 0 293 2010-02-25 00:31:57.750
!MESSAGE Target platform provided by class
org.eclipse.buckminster.pde.internal.PDETargetPlatform
Target platform provided by class
org.eclipse.buckminster.pde.internal.PDETargetPlatform
Running Platform : win32,win32,x86/de_DE
Target One : win32,win32,x86/de_DE
Target One : win32,win32,x86/de_DE
Target One : win32,win32,x86/de_DE
Target One : win32,win32,x86/de_DE
Target Two : win32,win32,x86/de_DE
* Target Two : win32,win32,x86/de_DE
Target Two : win32,win32,x86/de_DE
Target One : win32,win32,x86/de_DE
Re: Target Platform and buckminster-headless: update, multiple with same name, rmtarget [message #516779 is a reply to message #516749] Thu, 25 February 2010 07:20 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
On 02/25/2010 12:59 AM, Bernhard Merkle wrote:
> I have the following questions about eclipse targets and
> buckminster-headless (example, please see below)
>
> 1. If I update my.target in my Eclipse project do I have to _reimport_
> this into my headless bucky ? (or do i only have to do it once and later
> it is dome automatically ?)
>
The target platform definitions are PDE specific. Buckminster provides the headless command to import them but other
then that, it will work just like it does in the IDE. Buckminster will manage or perform automatic imports of the TP.

> 2. Up to now I reimported my.target always after modification into
> headless bucky. However this leads to multiple copies with the same name
> (!) which is irritating IMO.. BTW. where are they stored.
> Can I avoid the reimport step and what can I do againt the growing
> number of nameequal entries ?
>
The simplest way to resolve this is probably to use a target definition that just specifies an empty directory and then
have an RMAP provider that will find a p2 repository that contain the artifacts needed by your target platform.

Buckminster will then find out exactly what you need to have in your target and then use p2 to do the provisioning of
the TP. Subsequent imports will find target updates and changes in your dependencies will get automatically resolved.

> 3. there is importtarget, lstargets, but no rmtarget "name".
> Why ? is it not usefull ?
>
That sounds like an oversight. Please enter an enhancement request for this.

Regards,
Thomas Hallgren
Re: Target Platform and buckminster-headless: update, multiple with same name, rmtarget [message #516784 is a reply to message #516779] Thu, 25 February 2010 03:02 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Oops, I just found a rather serious omission in my answer:

On 02/25/2010 08:20 AM, Thomas Hallgren wrote:
> The target platform definitions are PDE specific. Buckminster provides
> the headless command to import them but other then that, it will work
> just like it does in the IDE. Buckminster will manage or perform
> automatic imports of the TP.
>
The last sentence should read:

"Buckminster will *not* manage or perform automatic imports of the TP."

- thomas
Re: Target Platform and buckminster-headless: update, multiple with same name, rmtarget [message #517903 is a reply to message #516779] Tue, 02 March 2010 13:58 Go to previous messageGo to next message
John is currently offline JohnFriend
Messages: 107
Registered: July 2009
Senior Member
Hi Thomas!

Interesting answer you have here.

Thomas Hallgren wrote on Thu, 25 February 2010 08:20
> 2. Up to now I reimported my.target always after modification into
> headless bucky. However this leads to multiple copies with the same name
> (!) which is irritating IMO.. BTW. where are they stored.
> Can I avoid the reimport step and what can I do againt the growing
> number of nameequal entries ?
>
The simplest way to resolve this is probably to use a target definition that just specifies an empty directory and then
have an RMAP provider that will find a p2 repository that contain the artifacts needed by your target platform.

Buckminster will then find out exactly what you need to have in your target and then use p2 to do the provisioning of
the TP. Subsequent imports will find target updates and changes in your dependencies will get automatically resolved.



I'm currently deciding how we should manage our target platform when our conversion to 3.5 is complete.

One option is to continue using setpref org.eclipse.buckminster.pde.targetPlatformPath. It seems to work quite well.

Then there's the recommendation to use importtargetdefinition.

But I was also thinking about just using an rmap as you suggest here. Would you consider this the preferred approach? Why is it necessary to set the target platform to an empty reference? Is this because it uses the runtime as target platform if one isn't specified and that the target platform takes precedence over what can be found using ramp's?


Thanks.

/John
Re: Target Platform and buckminster-headless: update, multiple with same name, rmtarget [message #517947 is a reply to message #517903] Tue, 02 March 2010 15:17 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi John,

On 03/02/2010 02:58 PM, John wrote:
> Hi Thomas!
>
> Interesting answer you have here.
>
> Thomas Hallgren wrote on Thu, 25 February 2010 08:20
>> > 2. Up to now I reimported my.target always after modification into
>> > headless bucky. However this leads to multiple copies with the same
>> name
>> > (!) which is irritating IMO.. BTW. where are they stored.
>> > Can I avoid the reimport step and what can I do againt the growing
>> > number of nameequal entries ?
>> >
>> The simplest way to resolve this is probably to use a target
>> definition that just specifies an empty directory and then have an
>> RMAP provider that will find a p2 repository that contain the
>> artifacts needed by your target platform.
>>
>> Buckminster will then find out exactly what you need to have in your
>> target and then use p2 to do the provisioning of the TP. Subsequent
>> imports will find target updates and changes in your dependencies will
>> get automatically resolved.
>
>
> I'm currently deciding how we should manage our target platform when our
> conversion to 3.5 is complete.
>
> One option is to continue using setpref
> org.eclipse.buckminster.pde.targetPlatformPath. It seems to work quite
> well.
>
> Then there's the recommendation to use importtargetdefinition.
>
> But I was also thinking about just using an rmap as you suggest here.
> Would you consider this the preferred approach?

Yes. That way you leverage Buckminster's resolver and p2 fully.

> Why is it necessary to
> set the target platform to an empty reference? Is this because it uses
> the runtime as target platform if one isn't specified and that the
> target platform takes precedence over what can be found using ramp's?
>
The important thing is that the target platform has one directory container. It doesn't need to be empty. In fact, you
can preserve it between runs and it will be updated as needed.

Using the actual runtime as the target platform should be avoided in most cases IMO.

HTH,
- thomas
Re: Target Platform and buckminster-headless: update, multiple with same name, rmtarget [message #518030 is a reply to message #517947] Tue, 02 March 2010 19:47 Go to previous messageGo to next message
John is currently offline JohnFriend
Messages: 107
Registered: July 2009
Senior Member
Hi Thomas!


Thanks for the response.

Thomas Hallgren wrote on Tue, 02 March 2010 16:17
The important thing is that the target platform has one directory container. It doesn't need to be empty. In fact, you
can preserve it between runs and it will be updated as needed.


Maybe I misunderstood something here? By Using an rmap I would expect references to be resolved to the workspace as binary projects.

So what do you mean by the above statement? Are you talking abiut something else?


/John.
Re: Target Platform and buckminster-headless: update, multiple with same name, rmtarget [message #518032 is a reply to message #518030] Tue, 02 March 2010 20:09 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
On 03/02/2010 08:47 PM, John wrote:
> Hi Thomas!
>
>
> Thanks for the response.
>
> Thomas Hallgren wrote on Tue, 02 March 2010 16:17
>> The important thing is that the target platform has one directory
>> container. It doesn't need to be empty. In fact, you can preserve it
>> between runs and it will be updated as needed.
>
>
> Maybe I misunderstood something here? By Using an rmap I would expect
> references to be resolved to the workspace as binary projects.
>
The rmap is all about finding things. It doesn't say anything about where things end up. Some things might resolve to
the workspace, others to the target platform. You control where things end up using the mspec.

HTH,
- thomas
Re: Target Platform and buckminster-headless: update, multiple with same name, rmtarget [message #518039 is a reply to message #518032] Tue, 02 March 2010 20:24 Go to previous messageGo to next message
John is currently offline JohnFriend
Messages: 107
Registered: July 2009
Senior Member
Hi Thomas!

Thomas Hallgren wrote on Tue, 02 March 2010 21:09
The rmap is all about finding things. It doesn't say anything about where things end up. Some things might resolve to
the workspace, others to the target platform. You control where things end up using the mspec.


OK, that's what I maybe thought you were getting at.

So will it work just as well if I let it materialize as binary imported projects to the workspace? What do I gain from materializing to the (empty) directory appointed by my target definition instead?

How will it actually work, if I let it materialize to the (empty) directory appointed by my target definition? As far as I understand, using importtargetdefinition, will load the target platform and if it's empty at that point, will it work when the materialization later moves plugins to it?


Thanks.


/John
Re: Target Platform and buckminster-headless: update, multiple with same name, rmtarget [message #518051 is a reply to message #518039] Tue, 02 March 2010 21:06 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
On 03/02/2010 09:24 PM, John wrote:
> So will it work just as well if I let it materialize as binary imported
> projects to the workspace? What do I gain from materializing to the
> (empty) directory appointed by my target definition instead?
>
In order to get things into your workspace, a jar must first be wrapped in a project. That means that the importer must
generate a .project file and a .classpath. It must also extract the manifest and play some tricks with it. You can see
this if you view an imported binary project using the "Navigator" view instead of the package explorer.

If you import things into a target platform, none of that happens. p2 is used as the provisioning mechanism which means
that updates works a lot better then when you have imported projects.

> How will it actually work, if I let it materialize to the (empty)
> directory appointed by my target definition? As far as I understand,
> using importtargetdefinition, will load the target platform and if it's
> empty at that point, will it work when the materialization later moves
> plugins to it?
>
Yes it will work. The materializer (p2 in this case) will update the target platform with the new artifacts and tell PDE
to reload it.

- thomas
Re: Target Platform and buckminster-headless: update, multiple with same name, rmtarget [message #518054 is a reply to message #518039] Tue, 02 March 2010 21:29 Go to previous message
Achim Demelt is currently offline Achim DemeltFriend
Messages: 160
Registered: July 2009
Senior Member
Hi John,

The big advantage of materializing the target platform into a separate
directory IMHO is that you can keep it after the build execution and re-use
the already downloaded artifacts in the next build. Your platform tends to
be pretty stable, while your source code changes frequently. So there's no
need to download several MB worth of target platform bundles every time you
perform a build. => Keep the target platform, but use a new workspace and
source code to avoid left-overs from the last build. This significantly
speeds up your integration build.

To clarify that: *Do* import the target platform in each build run, but re-
use the TP directory every time you do that. Buckminster will check if it
finds better (i.e. newer) versions of the bundles you require. If there are
none, i.e. if your platform is up-to-date, it doesn't download anything.

Cheers,
Achim

John wrote:

> Hi Thomas!
>
> Thomas Hallgren wrote on Tue, 02 March 2010 21:09
>> The rmap is all about finding things. It doesn't say anything about where
>> things end up. Some things might resolve to the workspace, others to the
>> target platform. You control where things end up using the mspec.
>
>
> OK, that's what I maybe thought you were getting at.
>
> So will it work just as well if I let it materialize as binary imported
> projects to the workspace? What do I gain from materializing to the
> (empty) directory appointed by my target definition instead?
>
> How will it actually work, if I let it materialize to the (empty)
> directory appointed by my target definition? As far as I understand, using
> importtargetdefinition, will load the target platform and if it's empty at
> that point, will it work when the materialization later moves plugins to
> it?
>
>
> Thanks.
>
>
> /John
Previous Topic:Problem build an aggregated site headless
Next Topic:Problems resolving from a p2 site with Buckminster 3.5
Goto Forum:
  


Current Time: Tue Aug 03 05:41:29 GMT 2021

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

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

Back to the top