Hello,

Please take a look at https://www.chiliproject.org/projects/chiliproject/wiki/Plugin_Compatibility first if you want to have a good idea of which plugins are/are not supported.

As chiliproject is slowly moving away from being redmine but with fixes (becoming an identity of his own), plugins will slowly start not being compatible between redmine and chiliproject.

AFAIK, the plugin system relies on how ruby itself works, that is, using duck typing, or adding new functionalities to already existing class/module definitions. It works great as long as the methods in the modules are the same in both redmine and chiliproject. The plugins works because chiliproject is not so different from redmine, but it is slowly changing/evolving.

I'm not an extremely knowledgeable RoR/ruby developer, but since the code start to diverge between the two (as well as the needs), there will be a time when some plugins will work, while some won't.

As for chiliproject dying because plugins are not available, that is quite a statement. Many users use chiliproject "vanilla", that is without any plugin.

If you feel that chiliproject doesn't respond to your needs and redmine does, it might be better for you to stay with redmine.

You might want to get in touch with the developer of the Redmine plugin. Unfortunately, last I read the feature request at his sourceforge account, he wasn't so positive towards Chiliproject. Your best bet is to develop your own Mylyn plugin version that will work with Chiliproject.

Hello Hans,

Hans Kaiser wrote:

My decision to switch to chiliproject was the compatibility to redmine plugins. And my first test failed.

So I am asking me, was it a good decision?
Can someone tell me, how the plugin compatibility is managed to redmine?

I'm sorry that you started off on a wrong assumption: we will try to retain compatibility where possible, not at all cost, i.e. as the codebases diverge, there are and will be incompatibilities, and probably more as time passes. We try to help plugin developers and maintainers if they have problems or questions keeping their plugins compatible with both though.

Hello all,

I am a developer for some languages. So I do not unterstand the point, that chiliproject is slowly giving up its plugin compatibility to redmine.

If you get the story from the users perspective:
The possible user analyses the market and finds typically some different and well developed project/issue-management tools.
Are there some forks and why?
The next step is to check the activity of the community and to check the velocity and commit-profile of the projects. Cool everything was pro chiliproject.

The next step was to analyse the possibility to extend the chiliproject. And this was a huge list on redmine. Chiliproject has only a very small list. So checking the forums it seems to be, that chiliproject has a good sort of compatibility to redmine. Okay a next step to give it a try.

Doing the setup, which in my point of view is unclear and many steps are undocumented was a hard job to pass. The next step was to extend the chiliproject with the plugins for the own needs. This is a integration into our needed tools (eclipse, excel/openoffice-calc). But none of the plugins was working.So I am usually a user, who explicitly tries to get project which follow the Open Source idea to share the knowledge and the open management of the project, but only if the project fits to my needs. And my needs - and I think of many other new users - are integrations to other tools and extensions, which solve some user problems.

You can image, that I have stopped my effort in using chiliproject. I am currently checking if redmine will be the better solution.
But why?

In my opinion it is only necessary to define a stable plugin-API/ABI which is and will be stable to the newest redmine plugin-API/ABI. Thats all, I know it needs some additional effort for the development, but this would solve the problems, that the plugin developers are not willig to support to competing issue-management tools redmine and chiliproject.

I hope there will be a discussion on the plugin compatibility at the project lead team. And I hope you will decide to get back to the plugin compatibility to redmine. I think that is your only way to get more users from redmine to chiliproject and to get new plugin developers to support chiliproject.
Compare it to other open source projects, which made a fork. The forks had only a possiblity to survive if the had an easy option for the users to switch to the new fork. To chiliproject I can switch, but I am loosing the huge amount of plugins in redmine.

So would you switch to chiliproject in such a case?

bye hans

Hans Kaiser wrote:

In my opinion it is only necessary to define a stable plugin-API/ABI which is and will be stable to the newest redmine plugin-API/ABI. Thats all, I know it needs some additional effort for the development, but this would solve the problems, that the plugin developers are not willig to support to competing issue-management tools redmine and chiliproject.

That's exactly the core of the problem: there has never been and there is currently no "public" plugin-API, neither has or is there one for Redmine, nor (sadly) for ChiliProject. The root cause for this is how Redmine/ChiliProject plugins work, they make heavy (and encouraged!) use of monkey-patching and willy-nilly code injection creating tight couplings, and thus any difference between Redmine and ChiliProject is a potential source of incompatibility as there's no way to know if a plugin might monkey-patch things there or to properly deprecate it.

I agree with you that this is a far from ideal solution, though more common than not in the ruby and rails worlds, and hopefully one we'll be able to better address someday, but that's probably not going to happen soon, and I fear that a 100% compatibility with Redmine (should they be willing to cooperate on this) was thrown out of the window the day we forked.

Hans Kaiser wrote:

Doing the setup, which in my point of view is unclear and many steps are undocumented was a hard job to pass.

Could you please tell us more about what was unclear to you or undocumented in either another forum thread or in an issue? "It's bad" is rather subjective and not something we can fix well :-)

Hans Kaiser wrote:

So would you switch to chiliproject in such a case?

Our reasons for forking have been discussed many times over and can be found in the Wiki and in some forum threads, I won't rehash them here unless you have specific (unanswered) questions, sorry.