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 ... > 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 . <joke> Titanium eggs never break , sir :D </joke> -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
