Eclipse Community Forums: Buckminster » How to deal properly with referenced plugins/features

Home » Archived » Buckminster » How to deal properly with referenced plugins/features(Best practice RCP product organization of external features)

Show: Today's Messages :: Show Polls :: Message Navigator

How to deal properly with referenced plugins/features [message #547257]

Fri, 16 July 2010 06:57

Tomsen

Messages: 42
Registered: July 2010

Member

Hi there,
we are starting to use Buckminster as the tool for assembly of an RCP app and I am in the process of reading and getting a feel for things.
Apologies for incorrect use of terminology Embarrassed

I read the BuckyBook and had a look at the mailapp project. After assembly the workspace was filled with the source projects for the various features/plugins the mailapp apparently depends on like Apache commons io/http etc.
I rather expected these plugins in binary form than in source as I would not want to fiddle with them.
My questions here now

is it best practice to do it like this rather than having only your own code in the workspace to work with? It took me some seconds to find the projects that actually belonged to the mailapp and I think this is irritating at least. Is the idea that these foreign features are build with the product and available from the update site? This does not sound right to me, I would rather expect a dependency to the download site for the Apache plugins for example.
is it possible to have the referenced features / plugins present in the workspace as binaries only?

Any comments/explanation welcome.

Report message to a moderator

Re: How to deal properly with referenced plugins/features [message #547271 is a reply to message #547257]

Fri, 16 July 2010 07:15

Henrik Lindberg

Messages: 2509
Registered: July 2009

Senior Member

Which version of Buckminster are you using?

I am asking since the 3.6 version directs binary things by default to
the TP instead of the Workspace. In earlier versions you have to use a
MSPEC to define this even for the simplest cases.

I don't know if it is available in a SR of 3.5, if so, it is not turned
on by default (as that would break API). Thomas, can you clarify?

Regards
- henrik

On 7/16/10 8:57 AM, Tomsen wrote:
> Hi there, we are starting to use Buckminster as the tool for assembly of
> an RCP app and I am in the process of reading and getting a feel for
> things. Apologies for incorrect use of terminology :blush: I read the
> http://www.eclipse.org/downloads/download.php?file=/tools/bu ckminster/doc/BuckyBook.pdf
> and had a look at the mailapp project. After assembly the workspace was
> filled with the source projects for the various features/plugins the
> mailapp apparently depends on like Apache commons io/http etc.
> I rather expected these plugins in binary form than in source as I would
> not want to fiddle with them. My questions here now
> is it best practice to do it like this rather than having only your own
> code in the workspace to work with? It took me some seconds to find the
> projects that actually belonged to the mailapp and I think this is
> irritating at least. Is the idea that these foreign features are build
> with the product and available from the update site? This does not sound
> right to me, I would rather expect a dependency to the download site for
> the Apache plugins for example. is it possible to have the referenced
> features / plugins present in the workspace as binaries only?
>
>
> Any comments/explanation welcome.

Report message to a moderator

Re: How to deal properly with referenced plugins/features [message #547391 is a reply to message #547271]

Fri, 16 July 2010 14:42

Tomsen

Messages: 42
Registered: July 2010

Member

Henrik,
I have
Buckminster - Core 1.1.350.r11409
Buckminster - PDE support 1.1.350.r11409
Buckminster - Subclipse support 1.0.0.r11162
Buckminster Aggregator Editor 1.0.0.r11409

obviously on Galileo as this currently is the target platform for the app in question. We'll move to Helios with the next release though. What is the "TP" as opposed to the workspace?

best regards

Thomas

Report message to a moderator

Re: How to deal properly with referenced plugins/features [message #547396 is a reply to message #547391]

Fri, 16 July 2010 14:56

Johannes Utzig

Messages: 329
Registered: July 2009

Senior Member

Am 16.07.2010 16:42, schrieb Tomsen:
>
> obviously on Galileo as this currently is the target platform for the
> app in question.

Hi Thomas,

You need to make a distinction here between the build tool (buckminster)
and your target platform. You can easily use Buckminster 3.6 to build
for a 3.5 or even a 3.4 target platform.
Buckminster is your 'compiler' of a sort while your Target Platform
contains the 'libraries' that you compile against.

> What is the "TP" as opposed to the workspace?

TP = Target Platform

Best regards,
Johannes

Report message to a moderator

Re: How to deal properly with referenced plugins/features [message #547611 is a reply to message #547396]

Mon, 19 July 2010 07:16

Tomsen

Messages: 42
Registered: July 2010

Member

Johannes,
thx for pointing this out! I assumed the Buckminster version was tied to the Eclipse rev somehow.
My revised internal model of Buckminster now assumes that the runtime for Buckminster is the same revision as the Buckminster rev (e.g. 3.5) but it is absolutely possible to build against a different TP. Or can I even install Buckminster 3.6 into a Galileo runtime?

-Thomas

Johannes Utzig wrote on Fri, 16 July 2010 10:56

Report message to a moderator

Re: How to deal properly with referenced plugins/features [message #547839 is a reply to message #547611]

Mon, 19 July 2010 17:52

Henrik Lindberg

Messages: 2509
Registered: July 2009

Senior Member

On 7/19/10 9:16 AM, Tomsen wrote:
Or can I even install Buckminster 3.6 into a
> Galileo runtime?
>
No. An older buckminster *may* be installable in a later runtime, but
the reverse would almost never work. For instance, the 3.6 version of
Buckminster uses the new p2 API. This API is not available in 3.5.

- henrik

Report message to a moderator

Re: How to deal properly with referenced plugins/features [message #547902 is a reply to message #547839]

Tue, 20 July 2010 07:09

Tomsen

Messages: 42
Registered: July 2010

Member

Henrik,
so from what was said so far I assume at least from 3.6 onward binary plugins can be added to the TP rather than be expanded in the workspace in source? Would you have any pointer to documentation for this feature? How do I get this to work?

many thanks

-Thomas

Report message to a moderator

Re: How to deal properly with referenced plugins/features [message #547945 is a reply to message #547902]

Tue, 20 July 2010 07:37

Johannes Utzig

Messages: 329
Registered: July 2009

Senior Member

Am 20.07.2010 09:09, schrieb Tomsen:
> so from what was said so far I assume at least from 3.6 onward binary
> plugins can be added to the TP rather than be expanded in the workspace
> in source?

Hi Thomas,

no, it has been possible to add binary bundles to the TP for a long time
already. The difference is before 3.6 you had to use an MSPEC to tell
Buckminster to materialize certain bundles to the TP. Starting with 3.6
the TP is the default materialization choice for binary bundles, so you
no longer need an mspec.

Best regards,
Johannes

Report message to a moderator