Plugin API: Web resources

Hi,

I'm working on a simple VCS plugin and noticed that the way to package web
resources is very inconvenient:
http://www.jetbrains.net/confluence/display/TW/Plugin+Development says that to
unpack the web resources of a plugin, one has to edit the main Spring descriptor
"buildServerSpring.xml", but that makes the deployment of a plugin needlessly
complicated, especially between server updates.

At first I added the reference to the WebResourceUnpacker bean (by mistake) to
the plugin's Spring descriptor, but that breaks the unpacking of other plugins'
web resources because the bean is replaced (when using the same ID). With a
different ID it creates a dependency-problem - so this isn't an option either.

My current version (which might be a workaround) looks like this:

public MyVcs(VcsManager mgr, WebResourcesManager resMgr) {
resMgr.addPluginResources(getName(), "my-vcs.jar");
mgr.registerVcsSupport(this, USER_PROPERTY);
}

Though I don't know if this registration might be too late here. Any advice
would be highly appreciated.

IMHO, plugins should be self-contained and deployable without modifying any core
files. Please consider a way to improve this, by either detecting and unpacking
resources automatically or by allowing to declare the resources in the
plugin-descriptor itself.


Thanks,
Sascha

3 comments
Comment actions Permalink

Hello,

Plugin development page was a bit out of date. Your code is correct -
WebResourcesManager is the right place to register your plugin resources.
You should do this while Spring is wiring objects, i.e. in the plugin
constructor.

--
Pavel Sher

"Sascha Weinreuter" <sascha.weinreuter@NOSPAM-cit.de> wrote in message
news:esk8l4$8pr$1@is.intellij.net...

Hi,

>

I'm working on a simple VCS plugin and noticed that the way to package web
resources is very inconvenient:
http://www.jetbrains.net/confluence/display/TW/Plugin+Development says
that to
unpack the web resources of a plugin, one has to edit the main Spring
descriptor
"buildServerSpring.xml", but that makes the deployment of a plugin
needlessly
complicated, especially between server updates.

>

At first I added the reference to the WebResourceUnpacker bean (by
mistake) to
the plugin's Spring descriptor, but that breaks the unpacking of other
plugins'
web resources because the bean is replaced (when using the same ID). With
a
different ID it creates a dependency-problem - so this isn't an option
either.

>

My current version (which might be a workaround) looks like this:

>

public MyVcs(VcsManager mgr, WebResourcesManager resMgr) {
resMgr.addPluginResources(getName(), "my-vcs.jar");
mgr.registerVcsSupport(this, USER_PROPERTY);
}

>

Though I don't know if this registration might be too late here. Any
advice
would be highly appreciated.

>

IMHO, plugins should be self-contained and deployable without modifying
any core
files. Please consider a way to improve this, by either detecting and
unpacking
resources automatically or by allowing to declare the resources in the
plugin-descriptor itself.

>
>

Thanks,
Sascha



0
Comment actions Permalink

Hi Pavel,

Plugin development page was a bit out of date. Your code is correct -
WebResourcesManager is the right place to register your plugin resources.
You should do this while Spring is wiring objects, i.e. in the plugin
constructor.


thanks for the information. However I believe that hard-coding jar-names is
calling for trouble on the long run. Is there no way to do the
registration/extraction automatically?

Sascha

0
Comment actions Permalink

Hello,

"Sascha Weinreuter" <sascha.weinreuter@NOSPAM-cit.de> wrote in message
news:esm38s$h6u$1@is.intellij.net...

Hi Pavel,

>
>> Plugin development page was a bit out of date. Your code is correct -
>> WebResourcesManager is the right place to register your plugin resources.
>> You should do this while Spring is wiring objects, i.e. in the plugin
>> constructor.
>

thanks for the information. However I believe that hard-coding jar-names
is
calling for trouble on the long run. Is there no way to do the
registration/extraction automatically?


Currently no. However, we are open minded for any improvements in our plugin
subsystem. If I understand you right you would prefer to attach a descriptor
of your resources with jar itself? Something like additional fields in
manifest. We can't simply scan all jar files for buildServerResources
directory because we should know which plugin this jar corresponds.

--
Pavel Sher


0

Please sign in to leave a comment.