Add all "non-openfire" plugins to trunk?

Openfire Openfire Dev
1

Hi,

while even I agree that this may be a bad idea as this requires more testing of a new build it would be very nice to have them all** in SVN. I did update my (web)vCard and my VCard2JiveUser plugin so I have locally new versions which support now Log4j.

Maybe one should add a “last updated” and a “last test date” to every plugin to so every user can see how active / supported the plugin is.

LG

** of course not all as some plugins are really no longer developed and needed.

2

Are you proposing to add all third-party plugins to Openfire? I’m not a big fan of that. Firstly, we’ll have issues with code ownership (or at least, we would be opening the door for those kind of issues). Secondly, I’m concerned with code quality of such plugins. If some of them fail, this will “rub off” to Openfire itself. Lastly, this would require us to give a lot of people write-access to the repository. Althoug we can finetune this, I’m not a big fan of this.

Perhaps we can have a “third party plugin” repository instead? We could for instance write a plugin (irony 101) that allows administrators to update/install third party plugins from a repository that we host here on IgniteRealtime. We could have individual plugin developers upload (compiled) plugins to that repository. This way, we would make them available in a somewhat sandboxed environment. From an Openfire admin perspective, the usage patterns would be quite similar to what we already have for “our native” plugins. We should add big disclaimers though.

3

From another perspective: I do welcome people contributing code in the form of plugins. That’d mean that those plugins will be part of the Openfire project. Contributor agreeements should be in place.

4

I agree. I think making the builds dependent on 3rd party plugins is a bad idea. I think the idea of a 3rd party repo of binaries and/or source is more reasonable.

5

+1

6

I add my vote as well to the 3rd party plugins SVN for both source and binaries

7

Just to be clear I want to vote for a separate 3rd party reprository (more http based not svn to allow admins to install and update their 3rd party plugins) which allows developer to submit their plugins for a central published place. Otherwise plugins which wants to get into “official” repro should therefore send a copyright agreement and the plugin should be reviewed.

8

There is already an location for all released official openfire plugins on igniterealtime.org

Released plugins at

http://www.igniterealtime.org/projects/openfire/plugins.jsp

and beta plugins at

http://www.igniterealtime.org/projects/openfire/plugins-beta.jsp

How do these tie in with your vote? Are you suggesting we should add a new link for released “un-official” 3rd party plugins?

Plugin developers like myself would like to use a central 3rd party SVN at igniterealtime instead of using code.google.com. There are many useful plugins out there. It would be nice to bring them all home

9

Indeed one does not need to offer all plugins on the plugins.jsp page, but I still wonder why it should do any harm to have plugins with different licenses in one repository as long as the plugins do match an open source license. OF-53 or API changes may break plugins and a developer is currently unaware of 3rd party plugins which do no longer work. The build process may of course break if one tries to compile all plugins, but that’s already the case when I try to compile the cluster plugin.So one may need to tweak the build/openfire.xml file to make a build with standard plugins.