Eclipse Community Forums: Buckminster » Target Platform and buckminster-headless: update, multiple with same name, rmtarget

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 18:59

Eclipse User

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 02:20

Eclipse User

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]

Wed, 24 February 2010 22:02

Eclipse User

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 08:58

Eclipse User

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 10:17

Eclipse User

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 14:47

Eclipse User

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 15:09

Eclipse User

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 15:24

Eclipse User

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 16:06

Eclipse User

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 16:29

Eclipse User

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:

-=] Back to Top [=-

Current Time: Sun May 11 23:36:08 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter