Plugin Manager v 0.1.1
Plugin Manager 0.1.1 is available at:
http://www.intellij.org/twiki/bin/view/Main/PluginManager
Changes since version 0.1:
Corrected a problem with installed plugin detection for plugins whose
plugin.xml file references a DTD. Many thanks to Sascha Weinreuter for
finding the problem and providing the solution! :)
Updated docs
请先登录再写评论。
Hi Chris,
is it possible to specify a proxy server?
Without, I can't use the great plugin :(
ciao
Marc Salm
http://www.codebasket.de
--
My software never has bugs. It just develops random features.
Hi,
I faced the same problem and solved it by adding the following to the constructor of PluginManagerConfigurable:
and I modified my idea.bat file to set the following VM properties:
set PROXY_PORT= set PROXY_USER= :: not used in fact set PROXY_PWD= :: not used in fact :: set JVM_ARGS= %JVM_ARGS% -Dhttp.proxySet=%PROXY_SET% set JVM_ARGS= %JVM_ARGS% -Dhttp.proxyHost=%PROXY_HOST% set JVM_ARGS= %JVM_ARGS% -Dhttp.proxyPort=%PROXY_PORT% set JVM_ARGS= %JVM_ARGS% -Dhttp.proxyUser=%PROXY_USER% :: not used in fact set JVM_ARGS= %JVM_ARGS% -Dhttp.proxyPassword=%PROXY_PWD% :: not used in fact]]>There are no proxy settings in IDEA yet. See http://www.intellij.net/tracker/idea/viewSCR?publicId=3238 and http://www.intellij.net/tracker/idea/viewSCR?publicId=4676 for similar posts.
Regards,
Franck
A couple of things:
The lower list should exclude plugins in the upper list that are the same version.
Ideally, the lower list should only have plugins you do not have at all,
and the upper list should indicate which plugins have updates available.
Also, If you select a line in the upper list, then the lower list,
then select the same line in the upper list again, the right-hand panel
(description) is not updated.
Chris Bartley wrote:
--
Erb
==============================================================
"Most of you are familiar with the virtues of a programmer.
There are three, of course: laziness, impatience, and hubris."
- Larry Wall
==============================================================
Thanks for your comments. See intermixed.
"Erb" <dont@evenbother.com> wrote in message
news:ar16ml$bqd$2@is.intellij.net...
version.
Good suggestions, thanks. Added to the feature request list. However, see
stuff below about tab view.
This is kinda related to one of the known issues (selections in both lists
at the same time). It may just go away altogether if I switch to a tab view
as suggested by Gordon Tyler in the "[Announcement] Plugin Manager v 0.1"
thread. In this case, it might be nice to show all plugins in the Available
Plugins tab, but mark ones you have with either an "Up to Date" or "Update
Available" icon (though what the heck those icons would look like, i have NO
idea). Thoughts? I also thought that, with a tabbed view, a "Check for
Updates" button in the "Installed Plugins" tab would be useful.
thanks for your feeback--definitely appreciated!
chris
I would love a Check for Updates button that not only found updates, but gave me the option to go ahead and install them (ie download the plugin and copy the jar into the plugin directory). The one thing I don't know is how hard it would be to find the jar in whatever your downloading from the site (if it's a .zip, .jar, etc).
Tobin
Added to feature requests list on the Wiki.
thanks,
chris
"Tobin Juday" <tsjuday@checkfree.com> wrote in message
news:5305726.1037316796260.JavaMail.jrun@is.intellij.net...
gave me the option to go ahead and install them (ie download the plugin and
copy the jar into the plugin directory). The one thing I don't know is how
hard it would be to find the jar in whatever your downloading from the site
(if it's a .zip, .jar, etc).
>
Tobin Juday wrote:
There is a problem deploying a new version of a plugin, since IDEA locks the jars...
This could be solved by modifying the batch file to copy the contents of a temporary
folder to the plugins folder (it's ugly, but it works - if you know better way let me know)...
Hmmm, I forgot about that. Ouch. A batch file would be ugly, plus that would break the portability of your code. I can think of all sorts of ways around it, but none of them are pretty. =)
I'm guessing that without IntelliJ support (like adding a OpenAPI method to unlock/lock jars), this task will be really ugly to get around. I'll keep thinking about it, though.
IDEA doesn't lock jars. Java ClassLoaders do.
--
Best regards,
Mike Aizatsky.
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
Mike Aizatsky wrote:
Does IDEA use a separate URLClassLoader for the plugins (or for each
plugin)? If so, it could unload the plugins, releasing the JARs to be
updated and then reload the plugins again.
Ciao,
Gordon
--
Gordon Tyler
Software Developer, R&D
Sitraka (now part of Quest Software)
"Performance is Mission Critical"
Java doesn't support unloading of classes. ClassLoader will be GC'ed only
when all objects from all classes from that classloader will be collected.
So I'm not sure that it's possible to create 100% working feature of plugins
unloading.
--
Best regards,
Mike Aizatsky.
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
What about the hot swapping of classes new to 1.4?
"Mike Aizatsky" <mike@intellij.com> wrote in message
news:ar38vj$pnt$1@is.intellij.net...
plugins
>
>
>
Mike Aizatsky wrote:
Then how does WebLogic, etc. do their hot swapping of EJB JARs? I
thought they did it with ClassLoaders like this.
Ciao,
Gordon
--
Gordon Tyler
Software Developer, R&D
Sitraka (now part of Quest Software)
"Performance is Mission Critical"
Isn't it a debugger feature?
--
Best regards,
Mike Aizatsky.
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
They are deactivating all the beans. And as J2EE spec doesn't allow any kind
of listeners & static fields - it should be enough to GC all the beans. (I
don't know whether they can deal correctly with static fields. Looks like
WebLogic should crash with OutOfMemory after enough number of reloading).
In IDEA OpenApi there're a lot of listeners. If plugin won't unregister all
of them on deactivation listeners will still be called and, in fact, you'll
get 2, 3, 4 and more copies of your plugin.
--
Best regards,
Mike Aizatsky.
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
jEdit has a very nice pugin manager, you may wan to
have a look at that.
You have to restart jEdit after installing or updating
plugins, they did not find a way to hot swap either.
dimiter wrote:
>> I would love a Check for Updates button that not only found updates,
>> but gave me the option to go ahead and install them
"Marius Scurtescu" <mscurtescu@healthmetrx.com> wrote in message
news:ar39on$qr1$1@is.intellij.net...
>
Yeah, I'll probably have another look. I tried JEdit a long time ago
(before becoming an IDEA addict) and do remember liking their plugin
manager.
I checked out the JEdit site again the other day and, though i only visited
briefly, from what i could tell you have to submit plugins for inclusion on
their plugin site. So, i'm guessing they essentially have a managing body
that does all the registration required for their mananger. I assume they
also have fairly strict requirements as to how plugins should be packaged.
Regardless of how jEdit does things with plugin registration, since we have
a very open and free community with the Wiki (a GOOD thing, IMO), i think a
goal such as auto-installation is pretty far down the road. We'd need to
get all plugin developers to agree to package things in such a way that
unpackaging could be automated. I just don't see that happening any time
soon (right now, some are distributed just as a jar, others as a jar in a
zip, etc). I think just getting everyone to agree to consistently update
info required by the plugin manager (i.e. the idea-plugin-registry.xml file)
is/will be hard enough.
On that note, I totally agree with Gordon Tyler's suggestion (see the thread
titled "[Announcement] Plugin Manager v 0.1") that the registry should just
contain pointers to idea-plugin-info.xml files which are managed by
individual plugin developers. Here's the excerpt:
I was thinking that having to update a central
plugin registry every time some detail about a
plugin changes is a tad cumbersome. What if the
Plugin Manager requires that an XML file with
the descriptive parts of your registry be
available in a known location for each plugin?
Probably the best place would be as an attachment
on the Wiki page for the plugin, for example:
http://www.intellij.org/twiki/pub/Main/PluginManager/idea-plugin-info.xml
That way, each plugin developer can individually
update their own plugin's description and the
central registry only has to be updated when
a new plugin is created.
Alternatively, the central plugin registry could
specify the URL to the plugin info xml if it's
not being hosted on the Wiki.
I plan to introduce that kinda scheme with the next version. Once we go
with that scheme, one thing that would be REALLY helpful is if plugin
developers would also package the idea-plugin-info.xml in their plugin's jar
file (probably best to just put it along with plugin.xml in the META-INF
directory)--doing that would really help the plugin manager get info on
installed plugins (and really help in checking for updates).
I'll probably be sending out an RFC kinda email soon on exactly what kinda
info should be included in the idea-plugin-info.xml file, maybe with a
proposed DTD.
As always, comments are welcomed and appreciated! :D
thanks,
chris
When editing idea-plugin-registry.xml with XMLSpy it faild to verify agains the DTD. It claims text is not leagel in description?
Weird...the data type was ANY, so I have no idea why it would complain. I've updated the DTD so the data type is PCDATA (as it probably should be anyway). Maybe XMLSpy will like that better. Thanks.