Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Buckminster » buckminster headless & p2/dropins folder
buckminster headless & p2/dropins folder [message #383507] Wed, 18 March 2009 06:52 Go to next message
Alex Chatziparaskewas is currently offline Alex ChatziparaskewasFriend
Messages: 52
Registered: July 2009
Member
Hi

We have run into a problem with the p2/dropins folder when using
buckminster in an headless build. What we have done is the following: We
simple installed the buckminster headless functionality into our normal
Eclipse installation, with the idea to use both worlds the IDE and
buckminster headless to compile our stuff. The one thing to note now: Some
of our (own) plugins live in the dropins folder. However, if buckminster
is now started 'headlessly' the p2 functionality of Eclipse is not
enabled, hence the dropins folder is not taken into account, hence 'our'
plugins are missing.

Three questions arise from this:
1) Is the approach we took in general dodgy?
2) Is the p2 functionality not enabled deliberately?
3) Does anyone know how to enable it in a buckminster headless build? (I
tried and failed...)

Thanks & Regards
Alex
Re: buckminster headless & p2/dropins folder [message #383508 is a reply to message #383507] Wed, 18 March 2009 07:11 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Alex Chatziparaskewas wrote:
> Hi
>
> We have run into a problem with the p2/dropins folder when using
> buckminster in an headless build. What we have done is the following: We
> simple installed the buckminster headless functionality into our normal
> Eclipse installation, with the idea to use both worlds the IDE and
> buckminster headless to compile our stuff. The one thing to note now:
> Some of our (own) plugins live in the dropins folder. However, if
> buckminster is now started 'headlessly' the p2 functionality of Eclipse
> is not enabled, hence the dropins folder is not taken into account,
> hence 'our' plugins are missing.
>
> Three questions arise from this:
> 1) Is the approach we took in general dodgy?

If all you want is to be able to run the headless commands from the
command line, you can do that by just installing the normal core
feature. It contains the command line interpreter application.

The headless features does not bring anything into the equation. They
just contain a lot of bundles that are already present in your IDE. You
might risk getting version conflicts but other then that, it should be
both harmless (and pointless).

> 2) Is the p2 functionality not enabled deliberately?
>
In Buckminster for 3.4 yes. We didn't have enough time to make the full
switch so we decided to defer that work until 3.5. The current (not yet
released) code base is fully P2 enabled.

> 3) Does anyone know how to enable it in a buckminster headless build? (I
> tried and failed...)
>
I think you should wait until the next 3.5 release of Buckminster (a
milestone will be out of the door in the couple of days) and then try
using that. It will build 3.4 sources too without problems.

Regards,
Thomas Hallgren
Re: buckminster headless & p2/dropins folder [message #383509 is a reply to message #383508] Wed, 18 March 2009 08:34 Go to previous messageGo to next message
Carsten Reckord is currently offline Carsten ReckordFriend
Messages: 139
Registered: July 2009
Senior Member
On 18.03.2009 08:11, Thomas Hallgren wrote:
>> 1) Is the approach we took in general dodgy?
>
> If all you want is to be able to run the headless commands from the
> command line, you can do that by just installing the normal core
> feature. It contains the command line interpreter application.
>
> The headless features does not bring anything into the equation. They
> just contain a lot of bundles that are already present in your IDE. You
> might risk getting version conflicts but other then that, it should be
> both harmless (and pointless).

Actually, if you use anything requiring draw2d in your IDE, you might run into this:

java.lang.NoClassDefFoundError: com/ibm/icu/text/Bidi
at org.eclipse.draw2d.text.BidiProcessor.process(BidiProcessor. java:190)

It suddenly started happening to me whenever I tried to open a GEF editor.

The problem here is that one of the headless features (don't remember which) brings the com.ibm.icu_base plugin with it, that is a stripped
down version of the com.ibm.icu plugin normally used by draw2d. Now, since draw2d depends on the icu plugin only through a package import
(due to #134789), it might get the _base plugin instead since that exports the same package, just without the required Bidi class.

I guess it only started to happen to me a while after I installed BM headless into the IDE was because of some indexing process of exported
packages or some such getting the two plugins in a (for me) unfortunate order...

I originally posted this to the gef group to see if they consider this a problem on their end. But when I didn't get an answer and work
happened, I forgot about it.

Anyway, if you run into this, it should work to just delete the icu_base plugin from your installation.


Regards,
Carsten
Re: buckminster headless & p2/dropins folder [message #383510 is a reply to message #383509] Wed, 18 March 2009 10:04 Go to previous message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Carsten,
I stand corrected. They are not harmless. Just pointless. So please
avoid installing the headless features into the IDE. Their sole purpose
is to provide the required bundles normally provided by the IDE. They
have no other purpose.

Regards,
Thomas Hallgren


Carsten Reckord wrote:
> On 18.03.2009 08:11, Thomas Hallgren wrote:
>>> 1) Is the approach we took in general dodgy?
>>
>> If all you want is to be able to run the headless commands from the
>> command line, you can do that by just installing the normal core
>> feature. It contains the command line interpreter application.
>>
>> The headless features does not bring anything into the equation. They
>> just contain a lot of bundles that are already present in your IDE.
>> You might risk getting version conflicts but other then that, it
>> should be both harmless (and pointless).
>
> Actually, if you use anything requiring draw2d in your IDE, you might
> run into this:
>
> java.lang.NoClassDefFoundError: com/ibm/icu/text/Bidi
> at org.eclipse.draw2d.text.BidiProcessor.process(BidiProcessor. java:190)
>
> It suddenly started happening to me whenever I tried to open a GEF editor.
>
> The problem here is that one of the headless features (don't remember
> which) brings the com.ibm.icu_base plugin with it, that is a stripped
> down version of the com.ibm.icu plugin normally used by draw2d. Now,
> since draw2d depends on the icu plugin only through a package import
> (due to #134789), it might get the _base plugin instead since that
> exports the same package, just without the required Bidi class.
>
> I guess it only started to happen to me a while after I installed BM
> headless into the IDE was because of some indexing process of exported
> packages or some such getting the two plugins in a (for me) unfortunate
> order...
>
> I originally posted this to the gef group to see if they consider this a
> problem on their end. But when I didn't get an answer and work happened,
> I forgot about it.
>
> Anyway, if you run into this, it should work to just delete the icu_base
> plugin from your installation.
>
>
> Regards,
> Carsten
Previous Topic:How do I avoid pruning empty directories when resolving from CVS?
Next Topic:svn authentication issue
Goto Forum:
  


Current Time: Wed Sep 25 17:50:31 GMT 2024

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

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

Back to the top