https://www.redmine.org/https://www.redmine.org/favicon.ico?16793021292012-05-02T16:25:29ZRedmineRedmine - Defect #10813: Rails 3. Redmine plugins are not engines anymore, are they?https://www.redmine.org/issues/10813?journal_id=378292012-05-02T16:25:29ZJean-Philippe Langjp_lang@yahoo.fr
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Closed</i></li><li><strong>Resolution</strong> set to <i>Invalid</i></li></ul><p>John Yani wrote:</p>
<blockquote>
<p>Seems like Redmine maintainers have decided not to use rails engines mechanism. Is it true?</p>
</blockquote>
<p>Yes, Redmine plugins do not rely on Rails engines.</p> Redmine - Defect #10813: Rails 3. Redmine plugins are not engines anymore, are they?https://www.redmine.org/issues/10813?journal_id=378332012-05-02T17:21:25ZJohn Yani
<ul></ul><p>Is it a temporary solution?<br />Do you have any statistics on which Redmine plugins rely on Rails Engines?<br />What's the point of making Redmine plugins independent from Rails Engines?<br />Plugin maintainer will still be required to make changes to support Rails 3.</p>
<p>Jean-Philippe Lang wrote:</p>
<blockquote>
<p>John Yani wrote:</p>
<blockquote>
<p>When plugins were in /vendor/plugins things were so much easier. Why do you think that just changing plugins directory will help plugin maintainers to upgrade their plugins?</p>
</blockquote>
It's not supposed to make the upgrade process easier but they were moved to /plugins for these 2 reasons:
<ul>
<li>having Rails plugins used by the core and Redmine plugins mixed in the same directory was a mess. Some people were just copying the entire old content from vendor/plugins when upgrading</li>
<li>having plugins in vendor/plugins is deprecated in Rails 3.2 and will be removed in a future Rails release</li>
</ul>
</blockquote>
<p>Ok, so these changes were for the future Rails 4.0 release.<br />Now plugin maintainers have 3 options:</p>
<ul>
<li>make their plugin independent from Rails Engine and ask users to put their plugin to the <code>plugins/</code> directory</li>
<li>ask users to put their plugin to the <code>lib/</code> directory</li>
<li>make their plugin a <a href="http://www.igvita.com/2010/08/04/rails-3-internals-railtie-creating-plugins/" class="external">Railtie</a> and ask users to change their <code>Gemfile</code></li>
</ul>
<p>All options require making Rails 3 compatibility changes.</p>
<p>First option require more work for both Redmine and Redmine plugins maintainers. However it has an advantage, like when Rails X will be released, Redmine won't have to be changed to support plugins. But copying rails engine loading code seems like a duplication to me.</p> Redmine - Defect #10813: Rails 3. Redmine plugins are not engines anymore, are they?https://www.redmine.org/issues/10813?journal_id=378342012-05-02T19:12:48ZJean-Philippe Langjp_lang@yahoo.fr
<ul></ul><p>John Yani wrote:</p>
<blockquote>
<p>Is it a temporary solution?</p>
</blockquote>
<p>No it's not.</p>
<blockquote>
<p>Do you have any statistics on which Redmine plugins rely on Rails Engines?</p>
</blockquote>
<p>I don't know any plugin that <strong>depends</strong> on Rails::Engine but I don't know all plugins. So few I guess.</p>
<blockquote>
<p>What's the point of making Redmine plugins independent from Rails Engines?</p>
</blockquote>
<p>To make 1.x plugins easier to upgrade. Redmine 2.0 offers pretty much the same features for plugins as Redmine 1.x, models/controllers/views are loaded just like before, custom routes, locales, tasks, assets and migrations are handled. And Redmine::Plugin API did not change.</p>
<blockquote>
<p>Plugin maintainer will still be required to make changes to support Rails 3.</p>
</blockquote>
<p>Of course, code that runs with Rails 3 has to be Rails 3 compatible.</p>
<blockquote>
<p>Ok, so these changes were for the future Rails 4.0 release.</p>
</blockquote>
<p>...and for reason 1.</p>
<blockquote>
<p>Now plugin maintainers have 3 options:</p>
<ul>
<li>make their plugin independent from Rails Engine and ask users to put their plugin to the <code>plugins/</code> directory</li>
<li>ask users to put their plugin to the <code>lib/</code> directory</li>
<li>make their plugin a <a href="http://www.igvita.com/2010/08/04/rails-3-internals-railtie-creating-plugins/" class="external">Railtie</a> and ask users to change their <code>Gemfile</code></li>
</ul>
<p>All options require making Rails 3 compatibility changes.</p>
</blockquote>
<p>Option 2 is irrelevant. And again, I can't see how Redmine could run with a plugin whose code is not Rails 3 compatible.</p>
<blockquote>
<p>First option require more work for both Redmine and Redmine plugins maintainers. However it has an advantage, like when Rails X will be released, Redmine won't have to be changed to support plugins. But copying rails engine loading code seems like a duplication to me.</p>
</blockquote>
<p>I disagree, option 1 does not require more work than making an existing plugin a Railtie. I have ported a few plugins myself and it was pretty straightforward. Rewriting routes with the new Rails3 route syntax was most of the work. You can have a look at the sample plugin in the repository (<a class="source" href="https://www.redmine.org/projects/redmine/repository/svn/entry/trunk/extra/sample_plugin">source:trunk/extra/sample_plugin</a>), it was ported to Redmine 2.0 without many changes.</p>
<p>Of course, if the internal of the plugin uses a lot of the Rails2 API that is not compatible with Rails3, a bit more work will be required. But I can't see how we can prevent that.</p>