On 11.10.2012 05:49, Olemis Lang wrote: > On 10/10/12, Branko Čibej <[email protected]> wrote: >> On 11.10.2012 01:16, Olemis Lang wrote: >>> On 10/10/12, Peter Koželj <[email protected]> wrote: >>>> 4. And now we want the ticket import/export from/to Jira to work across >>>> Trac and all other plugins (including ticket relations, multiproducts >>>> and >>>> custom per product workflows plugins) >>> That's what Interface class in the component architecture is for . In >>> such a hypothetical case let's limit the discussion to relational SQL >>> DBs . There will be a component that performs actual import / export >>> (let's call it SqlMigrationSystem) an Interface (let's call it >>> ISqlScriptContributor) and multiple components implementing the later >>> (e.g. one for ticket relations, multiproducts , custom per product >>> workflows , users , wiki pages , ...) . >>> >>> So how could all this work . When user decides to e.g. export all data >>> then SqlMigrationSystem relies on Trac core to enumerate all the >>> components implementing that interface . It does not really matter >>> what plugin they belong to . >> Etc. Precisely the point. Every plugin that Bloodhound uses for what it >> considers core functionality must implement this interface, or the whole >> export/import story falls on its face. > Well , that's exactly the point , isn't it ? Build a generic framework > and give components some room to make it more specific in many > different ways > ;) > > ... maybe the interface is part of Trac itself ... > >> Since these are plugins that the >> Apache Bloodhound project does not control, you either have to ask the >> plugin authors very nicely to implement that interface, > step 1 . > >> or do it >> yourself and hope your patches are accepted, > step 2 > >> or maintain a perpetual >> stack of patches for every core plugin, > that's what we do with Trac vendor branch already , yes ... > >> or fork the plugin (for which >> you need a code grant to relicense under ALv2, which ain't gonna happen >> if you couldn't arrange any of the other options with the author), > That depends on the original license . BSD and MIT should not be problematic > ...
Have you read the ASF legal requirements for releases? :) -- Brane -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
