Plugin API availability? Follow
I think it is pretty cool that IDEA has a plugin API. Unfortunately, the only
way to get it (that I know of) is to install IDEA yourself. For open source
projects that would like to build some tool support for IDEA, will that API
JAR ever be available separately as a download? Also if so, under what
licensing would that API JAR be available? Hopefully, the licensing for the
API jar will be lenient enough so that it does not inhibit that type of
integration.
Please sign in to leave a comment.
I'm confused. Without IDEA how could you possibly test that you are using the API correctly? Not to mention checking that everything else works correctly...
Also, if you are developing a plugin for IDEA, why would you not use IDEA for that development? What's the point?
John Murph wrote:
Its a question of building and distributing. Of course you would need IDEA to
test it.
The project usually only has the plugin as a help to those who want to use it.
THe plugin is not the project itself.
For example, I have a project that generates meta info for my classes. I would
like to add a plugin to ensure that this happens directly after a build. Not
really a problem. Keep in mind that the plugin is not the project, but merely
a tool to help users of my project if they happen to use IDEA.
Similar plugins would exist for Eclipse or possibly JUnit.
Bear in mind that any potential users of the plugin are going to have the
IDE installed and so have the API anyway. Given that, what need is there for
the API to be a separate download?
Your goal is commendable though!
Vil.
Berin Loritsch wrote:
--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/
DisclaimerThis e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.
Vilya Harvey wrote:
The need is there so that ANYONE who is currently managing the project can
continue to build and distribute the plugin--even if the guy with the plugin
expertise is temporarily not available.
How many of you have set up and developed open source projects? If you haven't,
then you don't know the challenges involved--so your tunnel vision would be
hurting the symbiotic relationship that can evolve here. Not to mention
something like a separately downloadable plugin API JAR is a huge step forward
to embracing the open source community in a two way street.
Just one more notice:
openapi.jar is not functional by all means by itself since it uses classes
from idea.jar. So I can't understand what huge step it appear to make.
--
Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
"Berin Loritsch" <bloritsch@d-haven.org> wrote in message
news:bjkj9p$47c$1@is.intellij.net...
>
plugin
>
haven't,
be
forward
>
I think what Berin is looking for is an easy way to do things like
automated builds and enabling maintainers of the whole project to build
it without having access to IDEA. To do any active development (and run
the plugin) they would of course need IDEA. Sort of like the things you
are doing with the UI-builder runtime -- but without the possibility to
run the code you're compiling. If this would be possible, a lot of
projects would be more inclined to include IDEA-specific tools in their
distros.
cheers,
/Måns
Maxim Shafirov (JetBrains) wrote:
Maxim Shafirov (JetBrains) wrote:
It makes it accessible to compile the plugins without having to download and
install IDEA. While those who develop and support the plugin still have to
have IDEA installed, they are not necessarily the same people responsible for
building the distributions. Open Source projects can have a large number of
people from around the world, and different development environments (or simple
VIM and command line debugging--not for the faint of heart).
The person responsible for creating the official build might live in Paris,
while the person maintaining the IDEA plugin lives in Australia. No matter
the situation, the person who creates the official builds may prefer to use
VIM for code editing.
Not to mention builds are usually done either with either vanilla ANT or Maven.
In order to build the project we need to be able to tell ANT/Maven where to
find the JAR--consistently. It would be very inconvenient to force folks who
build from source code to set environment variables or copy from all kinds of
different locations.
Choice of an IDE can almost be a religious discussion, so the variety of
different IDEs supported by any one project can be as varied as the number
of contributors. You can't force uniformity--even if IDEA rocks and kicks
a**.
Making the openapi.jar more available lowers the barriers of entry to support
these projects. Many times you don't need to have IDEA installed to update
the version of the API supported. Also, considering the changes happening
to the openapi.jar between major release versions, the open source project needs
a way of continuing to support the older installations. IDEA does cost money,
so not all users are going to have the latest and greatest.
Um, not that I would recommend this, because it's probably illegal, but why wouldn't you just give openapi.jar to the hypothetical VIM-enable build manager. Without a license file, he'll still be able to build, but wouldn't be able to run IDEA. Alternatively, the build manager could download an EAP version of openapi.jar.
Am I missing something?
Dave Griffith wrote:
Yes.
Two things:
1) By providing a way to download the OpenAPI.jar separately, it involves making
the license for that JAR very clear. As an open source developer, ensuring
that my projects are complying with all legal requirements is paramount.
2) What you are proposing is working around the system to "just get the job
done". It is not unlike making every single class in your application a
singleton, or making every single method in your application public and
static. You are circumventing the natural protection and design that should
be inherent in a system, which opens the doors to a very fragile future.
My primary concerns are to address the legality of using the openapi.jar for
compilation, and its legal accessibility by someone who has not an interest
in downloading ~40MB of IDE for a 382 KB JAR file. Do you see the economies
of scale here?
Berin Loritsch wrote:
>> Um, not that I would recommend this, because it's probably illegal,
>> but why wouldn't you just give openapi.jar to the hypothetical
>> VIM-enable build manager. Without a license file, he'll still be able
>> to build, but wouldn't be able to run IDEA. Alternatively, the build
>> manager could download an EAP version of openapi.jar.
>>
>> Am I missing something?
One more thing. There is a period of time where there is no EAP available
after a major release. No access at all.
On Mon, 08 Sep 2003 13:02:18 -0400, Berin Loritsch wrote:
I emailed eugene about this awhile ago when I wanted to bundle the
openapi.jar inside my CVS repo to enable anyone to build. But he said no :(
For simple compilation purposes you don't need the implementation, just the api.
In the EU it should be perfectly legal to create a version of the openapi library that contains stub versions of all the public classes and methods, as long as you don't copy the method code.
This is would be covered by the 'must-fit' exemption to design rights, but that may not be the case in the Czech Republic; I'm not sure if their IP laws match the EU's yet?
The easiest thing would be for Jetbrains to release the stub version, since (a) the legal position is not entirely clear, (b) the legal bills would probably make it cheaper to buy IBM, de-merge Rational, and have all their employees write you your own personal IDE, and most importantly (c) it just wouldn't feel right to do this if they had strong objections.
Maybe they could make their offer conditional upon the community creating complete & up-to-date documentation for the API?
What sayeth Prague? :)
Simon
(see http://www.kaltons.co.uk/EUdesprot.htm )
<< Article 7(2) makes designs which are made solely for the reason that, because they need to fit into other articles, they need to be a certain shape (i.e. ?must-fit?), unregistrable. For example, given that the shape of a phone plug is depended on its need to fit into a phone socket, it cannot be protected as a registered design. Moreover, the so-called ?must-match? design - i.e. because of the need to match something of which it forms an integral part (example, car spare parts) an article has to be designed in a certain way ? is also excluded. So, any features of appearance of an article which meet the interface or interconnection (?must-fit? or ?must-match?) criteria, must be excluded. >>
simon SPERO wrote:
Exactly. THat is all I want.
Even better: if the API was completely in terms of implementing a set of
interfaces, then there is no implementation to worry about! In fact the
implementation can change wildly behind the scenes and the plugin will (should)
still work.
The JSR for plugin APIs is at least started. That would make this all unneeded
if IDEA used it. It seems that they probably would seeing as they are on the
expert group ;P. However these things take time, and we shouldn't expect it to
be done by the time IDEA Aroura is done.
That's all I ask for. Truth be told, I don't know what license my plugins
would have to be released under. For all I know it could be that I have to
allow JetBrains to incorporate my plugin without my explicit consent.
Plugin development is encouraged on one hand, but the big licensing question
looms over it. I would really like that cleared up in simple layman language.
Heh, heh. Do you think the community could do a better job of documenting the
API? (Probably so, because it seems to be a very low priority for JetBrains).
Berin,
Thank you for the responses (to me and everyone else). I was asking because I didn't understand, not because I didn't agree. You have definately made a strong case for releasing a set of APIs for compilation purposes. I also agree that this API jar would encourage Intellij to design the API correctly, and not let implementation details bleed over into the API.
I vote for releasing it (but my vote doesn't really count here). Does JetBrains wanna give any reasons that a free (and I mean both kinds of free here) API jar versioned for each release of IDEA can't be made available?
P.S. They don't really have to give reasons, but I think Berin's given some good reasons for his point of view.