Re: [Pluginbuilder-development] Pluginbuilder experiences

[Werner S. (murphee) <wer...@gm...>]

Markus Barchfeld wrote:
>
> hm, as far is I remember the deletion of postBuild.xml was related to
> the pre-p2 update site. 
Ah yes (from the 0.6 release notes):
"The target of this release is Eclipse 3.3. A user has reported that 
building  with Eclipse 3.4 also works but postBuild.xml must be disabled 
(e.g. by renaming or deleting it)."


> The properties are already included in the Pluginbuilder nightly and
> can be set via the Properties tab of the Pluginbuilder Editor.
>   
Have there been changes in the nightlies? I was watching the CVS for a 
while but there didn't seem to be significant modifications since 0.6? 
(Just wondering if I should move to a nightly update site).

> Have a look at 
> http://rcpsample-3-4.pluginbuilder.org/nightly/p2-updateSite/
> which has been set up with the pluginbuilder nightly.
> Still unclear: how to set a category,
> https://sourceforge.net/forum/message.php?msg_id=6025032.
>   
Yeah - I know.  I sampled code from this and some other blogs, eg
http://aniefer.blogspot.com/2008/06/example-headless-build-for-rcp-product.html
helped me along, mostly by pointing out all the bugs that one needs to 
know about when dealing with p2 (eg. which config option not to use 
because it's broken, etc).

But still - a tool that sets up all the different string identifiers and 
version numbers and whatnot in exactly the way p2 & friends expect would 
be great.
(I spent ages on it - but any kind of approach of working with the PDE 
Build system (when working with a non-trivial RCP product) is marked by 
trying one combination,
waiting 10 minutes for the build to grind to a halt and fails with "Java 
exited with error code -13" - or the alternative of watching the build 
unfold in the debugger, which isn't much more fun.

I know the best way to do this would be to read and fully grok the PDE 
Build system, but I'd like to avoid a mind numbing task like that as 
long as I can.  Mostly because I can't believe that's really the _only_ 
way to build plugins.


>> (I tried for ages to get this right - but apparently one needs to be a
>> Mensa member and infinite patience to get even the most trivial things
>> to work with the PDE Build).
>>     
> I would not blame PDE for that. I think it is intrinsic to all build
> related development because it takes so long to get feedback. 
Weeeeell... the patience bit wasn't so much about the time it take to 
run the builds, but the patience it takes to even find out where to get 
started with the PDE Build system config.

Imagine if there were no PDE editors/tools support and you had to figure 
out all the OSGi/plugin/extension/etc stuff on your own - or figure out 
that your plugin doesn't work because you haven't set up the right 
import statement here or there.  These are all trivial with the PDE 
tools - but setting up a PDE Build means grokking every little 
nook/cranny of the system.

Eg. Alex Blewitt's EclipseCon talk/slides gave me the first light bulb 
moment by explaining the architecture of the PDE Build system (ie. 
basically a kind of OOP/Module/Polymorphism built on Ant callback files).
http://www.eclipsecon.org/2006/Sub.do?id=18
Etc.


murphee