bloodhound-dev mailing list archives

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

> or
> write your own plugin providing the same functionality.

... well ... afaics you have many options at hand . I don't get it . I
thought you were saying you were locked-in somehow .

You want a tomato . You either buy the seeds , take care of the plants
make them grow , then harvest all of it and then eat it ... or just go
to the supermarket and buy some tomatoes . There's no almighty tomato

> 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. :)

well ... that has already happened . Trac-devs changed component
architecture slightly in 1.0 . Hence ThemeEnginePlugin didn't work
anymore . So we submitted a patch to t-h.o issue tracker .
ThemeEnginePlugin has not been updated since 2 years ago , nobody
cared . We managed to patch our own copy of Trac to make it work
without requiring any changes in ThemeEnginePlugin . That's exactly
what we are all using nowadays , otherwise the new design would not be
a reality . I requested maintainership of ThemeEnginePlugin days ago
and I'm in charge now ... so I don't see the storm coming yet .

Titanium eggs never break , sir



Blog ES:
Blog EN:

Featured article:

View raw message