incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@wandisco.com>
Subject Re: Managing plugin dependencies WAS: Tests and CI (was: A word on Release 2)
Date Thu, 11 Oct 2012 04:10:09 GMT
On 11.10.2012 05:49, Olemis Lang wrote:
> On 10/10/12, Branko Čibej <brane@wandisco.com> wrote:
>> On 11.10.2012 01:16, Olemis Lang wrote:
>>> On 10/10/12, Peter Koželj <peter@digiverse.si> 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


Mime
View raw message