| Loading my plugin when JDT loads [message #333251] |
Mon, 01 December 2008 21:17  |
Eclipse User |
|
|
|
I want to register to get notified of all Java changes. I can do this by
calling JavaCore.addElementChangedListener(). However, I don't want my
plugin to be loaded until org.eclipse.jdt.core is loaded. My hack attempt
to do this was declare a dummy extension to an org.eclipse.jdt.core
extension point, but it doesn't work on all versions of Eclipse. Plus it's
ugly. How can I cleanly ensure that my plugin is loaded when another
plugin is loaded?
Regards,
Kent
|
|
|
|
| Re: Loading my plugin when JDT loads [message #333268 is a reply to message #333265] |
Tue, 02 December 2008 15:41  |
| Eclipse User |
|
|
|
Thanks for the hint. I apologize for being dense, but I don't see how that
would help, unless I can declare BundleListeners somehow in the manifest.
Say I want to write a log file of all Java changes. I write a plugin whose
activator looks like this (and I may have already gone wrong with this
step):
public void start(BundleContext context) throws Exception {
...
JavaCore.addElementChangedListener(myListener);
}
I want to be a good citizen, so I don't force my plugin to load at
startup. I especially don't want to do this because it would cause all of
jdt.core to load.
Unfortunately, this means that my listener never gets registered because
my plugin never gets loaded. This seems to me a weakness of the dynamic
listener model. When listeners are extensions, my plugin gets loaded when
the declaring plugin instantiates the listeners.
The hack I used was to declare a null CompilationParticipant. That way,
when jdt.core goes to compile the first time it instantiates my extension
which loads the plugin, calling start() and away we go.
I find this ugly and fragile, so I was hoping there was some way I could
say in the manifest "when jdt.core loads, please load me as well". I can't
imagine I'm the first person ever to encounter this problem.
Regards,
Kent
|
|
|
|
| Re: Loading my plugin when JDT loads [message #333274 is a reply to message #333272] |
Tue, 02 December 2008 19:25 |
| Eclipse User |
|
|
|
Walter,
Thank you for the additional ideas. I think that even with the
SaveParticipant I'm still left with finding a way to get my plugin
activated.
You asked about the application. It's a bit of a long story, but here you
go:
JUnitMax is a project to enhance the value of tests. I noticed that one of
the costs of developer testing is the cost of waiting for tests to finish.
It's more than just the 10 seconds/run * 100 runs/day * $50/hour
(~$12/day). A bigger component of the cost is the distraction from the
inner loop of development. If there was a way to get most or all of value
of running tests without a distracting pause, development would go more
smoothly without any loss of feedback. I'd expect to see tests run more
often and progress on code to be steadier.
It's that last proposition that I would like to validate empirically. I
want to run an experiment where volunteers code the way they usually code
for a week then introduce the Max runner and code for another week. At the
end of that time I'll analyze the log files of their testing and coding
activities, tell them what I find, and see if there are any characteristic
changes of rhythm between programming with the old runner and the Max
runner. I'd like to make supportable conclusions about development--using
the Max runner results in X% less time between starting tests and the next
new bit of code (eventually resulting in higher productivity).
I want to capture minimal information about development (HackyStat or
DevCreek UltraLite)--when tests start, when they stop, and when changes to
Java files happen. To do this I wrote an eentsy-weentsy plugin that
listens for Java changes and test starts and stops--no UI, it just writes
data to a log. The problem is, the plugin is so minimal it never gets
activated.
At this point I'm almost resigned to the CompilerParticipant hack. It
works but it seems ugly and fragile to me. I also tried attaching a
fragment to jdt.core, but I had the same problem--finding a entry point
that is sure to be called.
As I said, I can't imagine I'm the first person to encounter this problem.
Either that or I'm not thinking about the problem The Eclipse Way. Thanks
for your help setting me straight.
Regards,
Kent
|
|
|
|
| Re: Loading my plugin when JDT loads [message #333278 is a reply to message #333274] |
Wed, 03 December 2008 03:40 |
| Eclipse User |
|
|
|
If you can change your configuration, you can try to use Equinox Adaptor
Hooks http://wiki.eclipse.org/index.php/Adaptor_Hooks. Bundle Watcher
Hook is possibly the most suitable.
Snjeza
Kent Beck wrote:
> Walter,
>
> Thank you for the additional ideas. I think that even with the
> SaveParticipant I'm still left with finding a way to get my plugin
> activated.
>
> You asked about the application. It's a bit of a long story, but here
> you go:
>
> JUnitMax is a project to enhance the value of tests. I noticed that one
> of the costs of developer testing is the cost of waiting for tests to
> finish. It's more than just the 10 seconds/run * 100 runs/day * $50/hour
> (~$12/day). A bigger component of the cost is the distraction from the
> inner loop of development. If there was a way to get most or all of
> value of running tests without a distracting pause, development would go
> more smoothly without any loss of feedback. I'd expect to see tests run
> more often and progress on code to be steadier.
>
> It's that last proposition that I would like to validate empirically. I
> want to run an experiment where volunteers code the way they usually
> code for a week then introduce the Max runner and code for another week.
> At the end of that time I'll analyze the log files of their testing and
> coding activities, tell them what I find, and see if there are any
> characteristic changes of rhythm between programming with the old runner
> and the Max runner. I'd like to make supportable conclusions about
> development--using the Max runner results in X% less time between
> starting tests and the next new bit of code (eventually resulting in
> higher productivity).
>
> I want to capture minimal information about development (HackyStat or
> DevCreek UltraLite)--when tests start, when they stop, and when changes
> to Java files happen. To do this I wrote an eentsy-weentsy plugin that
> listens for Java changes and test starts and stops--no UI, it just
> writes data to a log. The problem is, the plugin is so minimal it never
> gets activated.
>
> At this point I'm almost resigned to the CompilerParticipant hack. It
> works but it seems ugly and fragile to me. I also tried attaching a
> fragment to jdt.core, but I had the same problem--finding a entry point
> that is sure to be called.
>
> As I said, I can't imagine I'm the first person to encounter this
> problem. Either that or I'm not thinking about the problem The Eclipse
> Way. Thanks for your help setting me straight.
>
> Regards,
>
> Kent
>
>
>
>
>
|
|
|
|
| Re: Loading my plugin when JDT loads [message #333367 is a reply to message #333274] |
Fri, 05 December 2008 20:24 |
| Eclipse User |
|
|
|
"Kent Beck" <kentb@earthlink.net> wrote in message
news:a9761f13ba839d6af66aceaa70ad16eb$1@www.eclipse.org...
> I want to capture minimal information about development (HackyStat or
> DevCreek UltraLite)--when tests start, when they stop, and when changes to
> Java files happen. To do this I wrote an eentsy-weentsy plugin that
> listens for Java changes and test starts and stops--no UI, it just writes
> data to a log. The problem is, the plugin is so minimal it never gets
> activated.
Eh, in a situation like that I think loading at startup is probably a
reasonable thing to do. Your plug-in is small and you don't expect to be
shipping it to many people, especially to many people who don't do Java
development. If you know that functionality is going to be used, then
loading it lazily is not always right...
As a reference point, when I worked on the BEA Weblogic plugins, we had some
logging functionality, to instrument user actions for feedback on what
features were being used. It turned out to be the best option to load a
(very small) plug-in at startup time.
You're quite right to be concerned about it - even small plug-ins still take
time and resources to load, and in general startup plugins should be avoided
like the plague. But action logging seems to be one of the cases where it
is hard to avoid.
I'm not aware of a "bundle loaded" extension point but it does seem like an
interesting idea.
|
|
|
Powered by
FUDForum. Page generated in 0.27533 seconds
Home