Eclipse Community Forums: Eclipse 4

Help

Home

Home » Eclipse Projects » Eclipse 4 » Bye bye Eclipse?

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

Bye bye Eclipse? [message #524903]

Sat, 03 April 2010 21:38

Dirk Hoffmann

Messages: 163
Registered: July 2009

Senior Member

Hi,

I've been developing an RCP+EMF based tool for one and a half year now,
starting as an Eclipse newbie in terms of developing on top of the
Eclipse platform. (I had been using eclipse as a Java developer quite
some time before).

The tool was released recently as part of a larger software product.
Nevertheless my boss is considering to stop Eclipse based development.
That's because the productivity when developing against the RCP is just
to low. (My boss was impressed by a Tcl/Tk based tool demoable after two
weeks of time, written by a Tcl/Tk guru).

I'm sending this to the (and maybe others) Eclipse mailing list because
I want the Eclipse core team to know about the typical problems I (and
probably others who are the kind of newbie I am) have been facing and of
course hoping to get tips from the experts how to improve my way of
working with Eclipse.

If this isn't the right place please tell me where to post this instead.

So here some examples of the typical kind of problems:

Example 1
---------
When moving from Eclipse 3.2 to 3.5 I found our product no longer
displayed its name at the top of the application window but instead the
%name placeholder as defined in the plugin.properties file. The most
popular search engine and the documentation I found couldn't help in
this case. After hours of debugging platform code using conditional
breakpoints chasing for the "%name" string I found the problem. As of
Eclipse 3.4 the default location of the bundle resource moved to
OSGI-INF/l10n/bundle.properties. You get the old behavior by putting
Bundle-Localization=plugin into the MANIFEST.MF. After completing my
debugging session I knew what key words to search for and found some
documentation on this.

Example 2
---------
When it goes to developing at the UI level the first question often is:
Do I have to develop these on my own or is there something I can reuse
and if Yes what is the name of the class. Even if I find a class name
Shift+Ctrl-T doesn't find me the class unless it happens to be in a
package mentioned in the list of dependencies. I always have one dummy
plug-in project that depends on a huge number of plug-ins just to let me
find those classes. I even wrote some shell scripts analyzing the
plugins folder to resolve class names to plug-in names.

Example 3
---------
When finished writing some UI stuff very often the problem is to get the
effects to the surface. You never know whether to call the layout(),
update(), refresh(), etc. method or need to set the size on the object.
A colleague of mine presented a case where he had to implement an event
handler that changes the event's data to change the size of some element.

The examples described above are symptomatic for what slowed me down so
often.

So essentially these were the problems:

o Documentation does not exist, is outdated or is hard to find

o If things don't work as expected and this is often the case trial and
error is required or debugging where "debugging" means stepping through
tons of platform code or code generated by some source generator in the
case of EMF eating up hours of development time. In fact the debugging
perspective is the active one most of the time.

o The SWT/JFace-APIs and other APIs are inconsistent.

o Reproducible or even automatic build are a problem of its own with
Eclipse.

o Seems there is just too much to learn for a single person to get an
Eclipse based product rolled out in time. That's what's sometimes called
a steep learning curve (a misnomer in my oppinion).

I wonder how others manage to finish Eclipse-based projects within a
reasonable timeframe. Do they have big teams of Eclipse specialists or
some, possibly commercial, tools helping them with their work?

Please tell me what it needs to write eclipse based software with
reasonable effort.

Thanks and Regards,
Dirk

Report message to a moderator

Re: Bye bye Eclipse? [message #525016 is a reply to message #524903]

Mon, 05 April 2010 06:28

Roland Tepp

Messages: 336
Registered: July 2009

Senior Member

Hi Dirk,

I am probably not the best man to answer your rant, for I am not Eclipse
core developer, but as an RCP application developer myself, I surely can
symphatize with some of the difficulties you might be having with
Eclipse/RCP development.
7
4.04.2010 0:38, Dirk Hoffmann kirjutas:

> The tool was released recently as part of a larger software product.
> Nevertheless my boss is considering to stop Eclipse based development.
> That's because the productivity when developing against the RCP is just
> to low. (My boss was impressed by a Tcl/Tk based tool demoable after two
> weeks of time, written by a Tcl/Tk guru).
>

Bosses get often impressed by people demoing some product or another.
Even more so when the guy doing the demo is a "guru" of the technology
he is demoing. The thing you should remind yourself (and your boss) is
that this guy has probably invested a huge amount of time and resources
to get to the level of experience he is able to show off at the moment,
and this "efficiency" does not come overnight.

Not knowing anything about the tool you are referring to, I bet if he'd
seen an Eclipse guru demoing their version of creating this tool using
bits and pieces from Eclipse, he'd be at least as impressed if not more.

It all comes down to the level of experience and being a beginner in any
sufficiently large and complex framework (which Eclipse surely is), will
certainly hurt your productivity.

> Example 1
> ---------
> When moving from Eclipse 3.2 to 3.5 I found our product no longer
> displayed its name at the top of the application window but instead the
> %name placeholder as defined in the plugin.properties file. The most
> popular search engine and the documentation I found couldn't help in
> this case. After hours of debugging platform code using conditional
> breakpoints chasing for the "%name" string I found the problem. As of
> Eclipse 3.4 the default location of the bundle resource moved to
> OSGI-INF/l10n/bundle.properties. You get the old behavior by putting
> Bundle-Localization=plugin into the MANIFEST.MF. After completing my
> debugging session I knew what key words to search for and found some
> documentation on this.
>

Migrating from one version of base platform to another is certainly
always a risky undertaking and sometimes version diferences may be
manifesting themselves in a subtle ways nobody can really anticipate.
Even more so, if you skip several intermediate versions.

For your concrete example though, I must admit, that I do actually
remember that this little tidbit of localization info location change
was actually mentioned in some of the release notes in between 3.2 and
3.5 releases... Your problem was more that the way the change manifested
itself, did not prompt you to ask the right question.

After debugging the internals of Eclipse launch and bundle loading code,
I bet you came out much more wiser hough about the internals of the
eclipse than just reading the one-lines in the documentation would ever
managed, so I believe this was a net proffit after all... :)

> Example 2
> ---------
> When it goes to developing at the UI level the first question often is:
> Do I have to develop these on my own or is there something I can reuse
> and if Yes what is the name of the class. Even if I find a class name
> Shift+Ctrl-T doesn't find me the class unless it happens to be in a
> package mentioned in the list of dependencies. I always have one dummy
> plug-in project that depends on a huge number of plug-ins just to let me
> find those classes. I even wrote some shell scripts analyzing the
> plugins folder to resolve class names to plug-in names.
>

To be more precise, You are probably talking about target platform
source bundles.

To "fix" that there is actually one quite nice hack you can use to get
all the source of the target platform in your worklspace - just use

File -> Import ... -> External Plug-ins and Fragments

Select to import all plug-ins and fragments from your target platform
with source folders or linked content and you're done.

Now you should be able to access all and any classes available in your
target platform, see and navigate it's source and generally learn from it.

> Example 3
> ---------
> When finished writing some UI stuff very often the problem is to get the
> effects to the surface. You never know whether to call the layout(),
> update(), refresh(), etc. method or need to set the size on the object.
> A colleague of mine presented a case where he had to implement an event
> handler that changes the event's data to change the size of some element.
>
Effects and purpose of layout(), update() and refresh() methods are
fairly well documented in the javadoc and all the source of their
implementation is freely availeble.

What you are alluding at, is actually the fact that SWT is a fairly low
level UI framework and as such sometimes using it requires a fair bit of
more intimate knowledge of the internals of it's workings. Even some of
the higher level ui frameworks (like JavaFX or Flex or even HTML/CSS)
require that you know exactly how the layout works in order to use it as
opposed to be driven by it. Granted, the low level of abstraction of SWT
incurs some overhead and a fair bit of hackery at times (specially when
dealing with some highly dynamic user interfaces), it still requires you
to know your tool just the same as you really need to understand layout
in CSS in order to hack your way through CSS...

> The examples described above are symptomatic for what slowed me down so
> often.
>
> So essentially these were the problems:
>
> o Documentation does not exist, is outdated or is hard to find
>
Welcome to Open Source. Although there are better and worse examples,
the state of documentation is generally poor in OpenSource (just to be
fair it is sometimes just as bad if not worse in commertial software).
And the documentation there is is quite often outdated.

Luclily, there is always source...

> o If things don't work as expected and this is often the case trial and
> error is required or debugging where "debugging" means stepping through
> tons of platform code or code generated by some source generator in the
> case of EMF eating up hours of development time. In fact the debugging
> perspective is the active one most of the time.
>
Welcome to Object Oriented software development - debugger is your best
friend, my friend :)

If You'd wanted strictly proveable and mathematically solid programs,
you'd never have to debug, you'd have to use some functional language
instead.

> o The SWT/JFace-APIs and other APIs are inconsistent.
>
I for one find SWT and JFace api's remarkably consistent and well
designed, but that is just my perception.

> o Reproducible or even automatic build are a problem of its own with
> Eclipse.
>
Not quite so. Although, setting up automated builds for Eclipse is no
child's play, it is certainly doable:
http://www.eclipse.org/articles/Article-PDE-Automation/autom ation.html

> o Seems there is just too much to learn for a single person to get an
> Eclipse based product rolled out in time. That's what's sometimes called
> a steep learning curve (a misnomer in my oppinion).
>
All much too true.

Heer's where I can only say - take a look at the Eclipse e4 platform. it
really addresses some of the main flaws and complexities of Eclipse RCP
based development.

Sadly, the documentation of e4 is still severely lacking and there are
not nearly enough step-by step tutorials of how to get from day 0 to a
"contacts" or "photo album" application for example.

> I wonder how others manage to finish Eclipse-based projects within a
> reasonable timeframe. Do they have big teams of Eclipse specialists or
> some, possibly commercial, tools helping them with their work?
>
Just plain hard work. Making the usual beginner mistakes, and living
with them until they can be fixed some day...

> Please tell me what it needs to write eclipse based software with
> reasonable effort.
>
learn the ins- and outs of Eclipse platform and try to re-use as much as
you can.

Eclipse is not just an IDE/UI bits. Eclipse has plenty of projects that
you can take advantage of:

In addition to Eclipse RCP and SWT/JFace tere are plenty of interesting
stuff going on:

o EMF, XText, GMF, CDO, are worthwile modeling and DSL development
platforms.

o ECF for communications related stuff (messaging, filetransfer, shared
state and distributed services)

o Equinox is a great OSGi container (take my advice and learn OSGi)

o Riena and e4 are a great runtime platforms to look into, if you need
to provide a highly custom UI (if the IDE background is not what you are
looking for).

There's much more at http://www.eclipse.org/projects/listofprojects.php

--
Roland Tepp

Report message to a moderator

Re: Bye bye Eclipse? [message #525045 is a reply to message #524903]

Mon, 05 April 2010 14:47

Paul Webster

Messages: 6859
Registered: July 2009
Location: Ottawa

Senior Member

I sympathize with your pain :-) While these don't help you after the
fact, I've included some comments inline.

This won't be seen by a wide eclipse audience here, as e4 is an
incubator project to look at technologies for Eclipse 4.0. One of the
goals it to make developing parts easier, but from your point of view it
won't help because 1) it's still an incubator, even the first release
isn't until July and 2) it has even less documentation than the current
eclipse used for RCP development :-)

Dirk Hoffmann wrote:
> The tool was released recently as part of a larger software product.
> Nevertheless my boss is considering to stop Eclipse based development.
> That's because the productivity when developing against the RCP is just
> to low. (My boss was impressed by a Tcl/Tk based tool demoable after two
> weeks of time, written by a Tcl/Tk guru).

Prototypes are easy ... production quality tools are hard. You will
always be able to whip up a new prototype that looks snazzy in a short
amount of time. The question would be "is everything I need to write
the functionality already in the prototype/Tcl/Tk support?":
preferences, parts of some kind, communication between parts,
save/restore, file system organization, etc. But if it is, then maybe
Tcl/Tk is more suitable for your tool.

> Example 2
> ---------
> When it goes to developing at the UI level the first question often is:
> Do I have to develop these on my own or is there something I can reuse
> and if Yes what is the name of the class. Even if I find a class name
> Shift+Ctrl-T doesn't find me the class unless it happens to be in a
> package mentioned in the list of dependencies. I always have one dummy
> plug-in project that depends on a huge number of plug-ins just to let me
> find those classes. I even wrote some shell scripts analyzing the
> plugins folder to resolve class names to plug-in names.

Some of these types of questions are answered in
http://wiki.eclipse.org/The_Official_Eclipse_FAQs (which has been
available since 3.0, and online for a couple of releases). In
particular,
http://wiki.eclipse.org/FAQ_How_do_I_find_a_particular_class _from_an_Eclipse_plug-in%3F
allows eclipse to manage your "big project for your target platform" for
you.

If you can find an example in your SDK, you can also use ALT+SHIFT+F1,
PDE Plug-in Spy. It will provide information about the focus control
related to PDE (IDs in use, implementing class, contributing plugin,
etc) if it is available.

> o Documentation does not exist, is outdated or is hard to find

I agree, it's often hard to find the answer to a specific question. I
tend to use:

http://help.eclipse.org/
http://wiki.eclipse.org/The_Official_Eclipse_FAQs
http://www.eclipse.org/articles/

> o Reproducible or even automatic build are a problem of its own with
> Eclipse.

While hard to set up, as Roland mentioned PDE Build allows automatic
builds. There is also the Tycho plugin for Maven, Buckmeister, and
other systems that can help. The initial setup requires some trial and
error, though.

> o Seems there is just too much to learn for a single person to get an
> Eclipse based product rolled out in time. That's what's sometimes called
> a steep learning curve (a misnomer in my oppinion).

It's a definite problem. The more libraries you consume to support your
functionality, the more different pieces of the puzzle you have. Aside
from more documentation (which everybody wants, even us, but is hard to
do) or efforts like the Release Train (project versions that are all
built together to minimize incompatibilities) I'm not sure how to
address this.

I expect your experiences are unfortunately common. I hope you can see
some improvements.

Later,
PW

--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm

Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions

Report message to a moderator

Re: Bye bye Eclipse? [message #525795 is a reply to message #525016]

Wed, 07 April 2010 19:48

Dirk Hoffmann

Messages: 163
Registered: July 2009

Senior Member

Hi Roland,

many thanks for your warm words and valuable tips. More comments below.

Roland Tepp schrieb:
> Hi Dirk,
>
> I am probably not the best man to answer your rant, for I am not Eclipse
> core developer, but as an RCP application developer myself, I surely can
> symphatize with some of the difficulties you might be having with
> Eclipse/RCP development.
> 7
> 4.04.2010 0:38, Dirk Hoffmann kirjutas:
>
>> The tool was released recently as part of a larger software product.
>> Nevertheless my boss is considering to stop Eclipse based development.
>> That's because the productivity when developing against the RCP is just
>> to low. (My boss was impressed by a Tcl/Tk based tool demoable after two
>> weeks of time, written by a Tcl/Tk guru).
>>
>
> Bosses get often impressed by people demoing some product or another.
> Even more so when the guy doing the demo is a "guru" of the technology
> he is demoing. The thing you should remind yourself (and your boss) is
> that this guy has probably invested a huge amount of time and resources
> to get to the level of experience he is able to show off at the moment,
> and this "efficiency" does not come overnight.
>
> Not knowing anything about the tool you are referring to, I bet if he'd
> seen an Eclipse guru demoing their version of creating this tool using
> bits and pieces from Eclipse, he'd be at least as impressed if not more.
>
> It all comes down to the level of experience and being a beginner in any
> sufficiently large and complex framework (which Eclipse surely is), will
> certainly hurt your productivity.
>
>> Example 1
>> ---------
>> When moving from Eclipse 3.2 to 3.5 I found our product no longer
>> displayed its name at the top of the application window but instead the
>> %name placeholder as defined in the plugin.properties file. The most
>> popular search engine and the documentation I found couldn't help in
>> this case. After hours of debugging platform code using conditional
>> breakpoints chasing for the "%name" string I found the problem. As of
>> Eclipse 3.4 the default location of the bundle resource moved to
>> OSGI-INF/l10n/bundle.properties. You get the old behavior by putting
>> Bundle-Localization=plugin into the MANIFEST.MF. After completing my
>> debugging session I knew what key words to search for and found some
>> documentation on this.
>>
>
> Migrating from one version of base platform to another is certainly
> always a risky undertaking and sometimes version diferences may be
> manifesting themselves in a subtle ways nobody can really anticipate.
> Even more so, if you skip several intermediate versions.
>
> For your concrete example though, I must admit, that I do actually
> remember that this little tidbit of localization info location change
> was actually mentioned in some of the release notes in between 3.2 and
> 3.5 releases... Your problem was more that the way the change manifested
> itself, did not prompt you to ask the right question.
Yes you're right. May be I read that info some time ago but couldn't
identify that as the source of the symptoms I saw. And I guess that's
happening all too often.
>
> After debugging the internals of Eclipse launch and bundle loading code,
> I bet you came out much more wiser hough about the internals of the
> eclipse than just reading the one-lines in the documentation would ever
> managed, so I believe this was a net proffit after all... :)
Yes, but there's so much code I had to walk through that I believe I
don't remember the relevant pieces of information when I should. What
was the name of the class building the INF-OSGI/l10n/bundle.properties
path again? :)
>
>
>> Example 2
>> ---------
>> When it goes to developing at the UI level the first question often is:
>> Do I have to develop these on my own or is there something I can reuse
>> and if Yes what is the name of the class. Even if I find a class name
>> Shift+Ctrl-T doesn't find me the class unless it happens to be in a
>> package mentioned in the list of dependencies. I always have one dummy
>> plug-in project that depends on a huge number of plug-ins just to let me
>> find those classes. I even wrote some shell scripts analyzing the
>> plugins folder to resolve class names to plug-in names.
>>
>
> To be more precise, You are probably talking about target platform
> source bundles.
Yes, of course
>
> To "fix" that there is actually one quite nice hack you can use to get
> all the source of the target platform in your worklspace - just use
>
> File -> Import ... -> External Plug-ins and Fragments
Hm, yes I read about that but was afraid that it would fill up my
workspace with projects I do not actually need. That would force me to
use Working Sets I suppose. Nevertheless I will try that. I could do
that in an extra workspace because after all I just want to know in
which package I can find a class. I also read about a plug-in that helps
in that respect.
>
> Select to import all plug-ins and fragments from your target platform
> with source folders or linked content and you're done.
>
> Now you should be able to access all and any classes available in your
> target platform, see and navigate it's source and generally learn from it.
>
>
>> Example 3
>> ---------
>> When finished writing some UI stuff very often the problem is to get the
>> effects to the surface. You never know whether to call the layout(),
>> update(), refresh(), etc. method or need to set the size on the object.
>> A colleague of mine presented a case where he had to implement an event
>> handler that changes the event's data to change the size of some element.
>>
> Effects and purpose of layout(), update() and refresh() methods are
> fairly well documented in the javadoc and all the source of their
> implementation is freely availeble.
>
> What you are alluding at, is actually the fact that SWT is a fairly low
> level UI framework and as such sometimes using it requires a fair bit of
> more intimate knowledge of the internals of it's workings. Even some of
> the higher level ui frameworks (like JavaFX or Flex or even HTML/CSS)
> require that you know exactly how the layout works in order to use it as
> opposed to be driven by it. Granted, the low level of abstraction of SWT
> incurs some overhead and a fair bit of hackery at times (specially when
> dealing with some highly dynamic user interfaces), it still requires you
> to know your tool just the same as you really need to understand layout
> in CSS in order to hack your way through CSS...
>
>
>
>> The examples described above are symptomatic for what slowed me down so
>> often.
>>
>> So essentially these were the problems:
>>
>> o Documentation does not exist, is outdated or is hard to find
>>
> Welcome to Open Source. Although there are better and worse examples,
> the state of documentation is generally poor in OpenSource (just to be
> fair it is sometimes just as bad if not worse in commertial software).
> And the documentation there is is quite often outdated.
>
> Luclily, there is always source...
>
>> o If things don't work as expected and this is often the case trial and
>> error is required or debugging where "debugging" means stepping through
>> tons of platform code or code generated by some source generator in the
>> case of EMF eating up hours of development time. In fact the debugging
>> perspective is the active one most of the time.
>>
> Welcome to Object Oriented software development - debugger is your best
> friend, my friend :)
I absolutely agree and consider the Eclipse bugger a great tool. Without
it I would have had to give up the whole project very soon
>
> If You'd wanted strictly proveable and mathematically solid programs,
> you'd never have to debug, you'd have to use some functional language
> instead.
Hm, really?
>
>> o The SWT/JFace-APIs and other APIs are inconsistent.
>>
> I for one find SWT and JFace api's remarkably consistent and well
> designed, but that is just my perception.
>
>> o Reproducible or even automatic build are a problem of its own with
>> Eclipse.
>>
> Not quite so. Although, setting up automated builds for Eclipse is no
> child's play, it is certainly doable:
> http://www.eclipse.org/articles/Article-PDE-Automation/autom ation.html
Of course its doable, but at which costs. We abandoned that idea and
fell back to a well defined and documented manual build procedure.
>
>
>
>> o Seems there is just too much to learn for a single person to get an
>> Eclipse based product rolled out in time. That's what's sometimes called
>> a steep learning curve (a misnomer in my oppinion).
>>
> All much too true.
>
> Heer's where I can only say - take a look at the Eclipse e4 platform. it
> really addresses some of the main flaws and complexities of Eclipse RCP
> based development.
Looking forward to that.
>
> Sadly, the documentation of e4 is still severely lacking and there are
> not nearly enough step-by step tutorials of how to get from day 0 to a
> "contacts" or "photo album" application for example.
>
>
>> I wonder how others manage to finish Eclipse-based projects within a
>> reasonable timeframe. Do they have big teams of Eclipse specialists or
>> some, possibly commercial, tools helping them with their work?
>>
> Just plain hard work. Making the usual beginner mistakes, and living
> with them until they can be fixed some day...
>
>
>> Please tell me what it needs to write eclipse based software with
>> reasonable effort.
>>
> learn the ins- and outs of Eclipse platform and try to re-use as much as
> you can.
>
> Eclipse is not just an IDE/UI bits. Eclipse has plenty of projects that
> you can take advantage of:
>
> In addition to Eclipse RCP and SWT/JFace tere are plenty of interesting
> stuff going on:
>
> o EMF, XText, GMF, CDO, are worthwile modeling and DSL development
> platforms.
Yes, I know the first three of your list.
>
> o ECF for communications related stuff (messaging, filetransfer, shared
> state and distributed services)
>
> o Equinox is a great OSGi container (take my advice and learn OSGi)
>
> o Riena and e4 are a great runtime platforms to look into, if you need
> to provide a highly custom UI (if the IDE background is not what you are
> looking for).
>
> There's much more at http://www.eclipse.org/projects/listofprojects.php
>

Report message to a moderator

Re: Bye bye Eclipse? [message #525800 is a reply to message #525045]

Wed, 07 April 2010 20:02

Dirk Hoffmann

Messages: 163
Registered: July 2009

Senior Member

Hi Paul,

many thanks to you also.

Paul Webster schrieb:
> I sympathize with your pain :-) While these don't help you after the
> fact, I've included some comments inline.
>
> This won't be seen by a wide eclipse audience here, as e4 is an
> incubator project to look at technologies for Eclipse 4.0. One of the
> goals it to make developing parts easier, but from your point of view it
> won't help because 1) it's still an incubator, even the first release
> isn't until July and 2) it has even less documentation than the current
> eclipse used for RCP development :-)
Actually I was believing that the eclipse core type of guru is reading
this list :)
>
>
> Dirk Hoffmann wrote:
>> The tool was released recently as part of a larger software product.
>> Nevertheless my boss is considering to stop Eclipse based development.
>> That's because the productivity when developing against the RCP is
>> just to low. (My boss was impressed by a Tcl/Tk based tool demoable
>> after two weeks of time, written by a Tcl/Tk guru).
>
> Prototypes are easy ... production quality tools are hard. You will
> always be able to whip up a new prototype that looks snazzy in a short
> amount of time. The question would be "is everything I need to write
> the functionality already in the prototype/Tcl/Tk support?":
> preferences, parts of some kind, communication between parts,
> save/restore, file system organization, etc. But if it is, then maybe
> Tcl/Tk is more suitable for your tool.
>
>> Example 2
>> ---------
>> When it goes to developing at the UI level the first question often
>> is: Do I have to develop these on my own or is there something I can
>> reuse and if Yes what is the name of the class. Even if I find a class
>> name Shift+Ctrl-T doesn't find me the class unless it happens to be in
>> a package mentioned in the list of dependencies. I always have one
>> dummy plug-in project that depends on a huge number of plug-ins just
>> to let me find those classes. I even wrote some shell scripts
>> analyzing the plugins folder to resolve class names to plug-in names.
>
> Some of these types of questions are answered in
> http://wiki.eclipse.org/The_Official_Eclipse_FAQs (which has been
> available since 3.0, and online for a couple of releases). In
> particular,
> http://wiki.eclipse.org/FAQ_How_do_I_find_a_particular_class _from_an_Eclipse_plug-in%3F
Cool, I really didn't know about this one.
> allows eclipse to manage your "big project for your target platform" for
> you.
>
> If you can find an example in your SDK, you can also use ALT+SHIFT+F1,
> PDE Plug-in Spy. It will provide information about the focus control
> related to PDE (IDs in use, implementing class, contributing plugin,
> etc) if it is available.
Well, as you mention it I remember I heard about it. Thanks for the hint.
>
>
>> o Documentation does not exist, is outdated or is hard to find
>
> I agree, it's often hard to find the answer to a specific question. I
> tend to use:
>
> http://help.eclipse.org/
> http://wiki.eclipse.org/The_Official_Eclipse_FAQs
> http://www.eclipse.org/articles/
>
>
>> o Reproducible or even automatic build are a problem of its own with
>> Eclipse.
>
> While hard to set up, as Roland mentioned PDE Build allows automatic
> builds. There is also the Tycho plugin for Maven, Buckmeister, and
> other systems that can help. The initial setup requires some trial and
> error, though.
And lets see how b3 evolves.
>
>
>> o Seems there is just too much to learn for a single person to get an
>> Eclipse based product rolled out in time. That's what's sometimes
>> called a steep learning curve (a misnomer in my oppinion).
>
> It's a definite problem. The more libraries you consume to support your
> functionality, the more different pieces of the puzzle you have. Aside
> from more documentation (which everybody wants, even us, but is hard to
> do) or efforts like the Release Train (project versions that are all
> built together to minimize incompatibilities) I'm not sure how to
> address this.
>
> I expect your experiences are unfortunately common. I hope you can see
> some improvements.
>
> Later,
> PW
>

I really feel a bit better now thanks to your and Roland's postings.

Cheers,
Dirk

Report message to a moderator