could somebody write a JINI plugin ?
I am seeing more plugins come about for Eclipse. I am using IDEA and loving it but its a thorn on my side to see the plugins I could really use for my development efforts pop-up for Eclipse every other day.
check this out from Inca.
http://www.incax.com/index.htm?http://www.incax.com/de-eclipse-plugin.htm
Why don't I shut up and write one myself ?
don't have time.
J.
Please sign in to leave a comment.
Em Mon, 21 Jun 2004 16:07:17 +0400, john lukar escreveu:
And guess why we don't do that? We don't have time.
Eclipse is an unique position: it has the love of all those open source
zealots, writing plugins when they should be sleeping, and also a lot of
corporate backing, writing plugins to drive sales for other products.
IDEA is not open source, and has only one company behind it, JetBrains.
Given the situation, I find the current plugin land for IDEA incredbly
good. We have Dave Griffith, Eclipse has just a bunch of wankers writing mostly useless plugins. -- Marcus Brito ]]>
Looks reasonably sweet, if possibly a bit pricy for what it offers. My guess, however, is that the answer to your question is "No", simply because of Jini's persistent market penetration problems. There's just not that many developers using Jini as of yet, and it is possible that the various web services initiatives have sucked the air out of it. I can't imagine that IncaX is expecting to sell all that many licenses to their plugin, particularly to the notoriously price-shy Eclipse community.
--Dave Griffith
Hi,
If there is sufficient commercial interest in a Jini plugin for IntelliJ we would be pleased to develop one as we have done for Eclipse and NetBeans.
Please let us know at info@incax.com
Thank you
Inca X
http://www.incax.com
Hi All
Have a look at
http://innominds.com/anki/EzJava.html.
Instead of plug-ins or stuff, I thought of this a long ago but unable to finish it. But now with Annotations feature of JDK1.5
We can create a PreProcessing tool for such kind of things.
Something like
and then the client is
Something like that :)
What do you say ;) ?
The problem is getMyService is not available in the code yet, so the Editor shows it as error :(. Donno how to resolve it.
I think it's pretty clear that this sort of annotation-based component construction/configuration/deployment idea is going to become big. The recently-unveiled EJB 3.0 proposed spec includes a lot of stuff like this, and plenty of other folk have been talking about using annotations to make the "top-level" of application structure more explicit and checkable.
As for the specifics, here's some ideas you might not have thought of:
1) The service annotation need not be unique on the class.
So you should be able to say
2) A better way of specifying the client would be
Your PreProcessing tool would then be responsible for binding the service field, presumably by generating some sort of initializer block which calls out to whatever continer you have actually doing the remote binding work. Any editor error checking works fine (although it might complain about possibly uninitialized variables). The code could also be tested outside of the container, if you have some other way of hooking up the service field (say, to an in-memory mock object).
3) A clever man might not ever require code generation for the above at all. Instead, it might all be done with reflection, since the JDK1.5 annotations may be specified as available at runtime. Might need some AOP to hook into the object construction process, though. Harumph. If the solution is "use AOP", you know you've gone wrong somewhere in identifying the problem. Time to rethink.
Interesting times ahead. It'll be great fun building the tools for them.
--Dave Griffith
I think it's pretty clear that this sort of annotation-based component construction/configuration/deployment idea is going to become big. The recently-unveiled EJB 3.0 proposed spec includes a lot of stuff like this, and plenty of other folk have been talking about using annotations to make the "top-level" of application structure more explicit and checkable.
ANKI>>> Could you please pinpoint more links.
2) A better way of specifying the client would be
public class MyClient {
@bind_service(type = "jini", id = "MyService" ...);
private MyRMIService service;
*ANKI>>> Very neat. *
A clever man might not ever require code generati .....................
*ANKI>>> :) I agree *
Thanks for the comments
-Anki.N