Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of brane@wandisco.com designates
 209.85.212.177 as permitted sender)
Message-ID: <507634FC.6060209@wandisco.com>
Date: Thu, 11 Oct 2012 04:54:52 +0200
From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@wandisco.com>
Organization: WANdisco
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: bloodhound-dev@incubator.apache.org
Subject: Re: Managing plugin dependencies WAS: Tests and CI (was: A word on
 Release 2)
References: 
 <CAGMZAuON0QMd0VsQHmMBwGnpcx+uDW10bvmEh9DuND1NixTHdg@mail.gmail.com>
In-Reply-To: 
 <CAGMZAuON0QMd0VsQHmMBwGnpcx+uDW10bvmEh9DuND1NixTHdg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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. 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, or do it
yourself and hope your patches are accepted, or maintain a perpetual
stack of patches for every core plugin, 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), or
write your own plugin providing the same functionality.

None of the above is a showstopper, but the interlocked dependencies
will make managing feature-stable Bloodhound releases a bit like
juggling eggs. It can be done, but you'd better not drop one. :)

-- Brane

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download