incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Managing plugin dependencies WAS: Tests and CI (was: A word on Release 2)
Date Wed, 10 Oct 2012 23:16:57 GMT
On 10/10/12, Peter Koželj <peter@digiverse.si> wrote:
>
[...]
>
> Just a few use cases for quick "does it float" test:
>

ok , challenge accepted
;)

>
> 1. Let's say we adopt some plugins for multiproducts, ticket relations,
> data import/export and so on...

When you say «adopt» I interpret that it means include them in
Bloodhound source code or install them by default . Otherwise , please
mention what is it about exactly .

<hr /> :P

Well , at the bottom of your message you ask about how to handle
inter-plugin dependencies in cases mentioned below . In general
there's no single magic solution to succeed but a set of tools , hacks
and practices . I'll write some simplistic answers below for each case
. I hope you understand that reality is more rich than anything I
might write in a few lines ...

> 2. Then we want to add user (admin) defined ticket relation per product
> 3. And then we want to support custom ticket workflows per product and per
> ticket type

afaics , the complexity here is related to the «per-product» modifier
. I'm writing right now about that subject in order to elaborate a bit
further the initial TracProposals [1]_ [2]_ [6]_ available on the
subject . In advance I tell you that (IMO) the level of uniformity and
decoupling needed in this particular case is not achieved by using any
other existing approach used ever before in Trac . So it requires a
bit of innovation ... fortunately that's what we are here for ;)

So I suggest you to talk about this once I finish those initial specs
, publish them , and we all analyze it ... It's just that as you can
see I've been working 100% these days and had no time yet to get this
done .

> 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 . For each one it invokes a method (defined
in the interface , so it works like a contract ;) so that each
implementor will fill a well-known data structure (e.g. like the ones
in bd_default.py but might be different if you want ...) in order to
describe the tables and associated data . After doing so
SqlMigrationSystem e.g. outputs a JSON, XML , CSV file ... whatever .

The plugin structure may be anything you want . Components may be
packaged in several ways and Trac component architecture will catch'em
all .

Disclaimer : All this is just a figment of my imagination , used to
illustrate how an hypothetically similar scenario could work . So
please don't pay much attention to the details , focus instead on the
overall picture .

> 5. Add white labeling across Trac and all other plugins

TagsPlugin [3]_ ? works in a similar way

> 6. Implement new search query language that will understand tickets,
> products and relations

idem ... nonetheless there might be some complications in this case ,
but in the end all the pieces are broken down into components
implementing an interface and a coordinator using theme all for a
particular purpose .

> 7. Add REST API's for all of the above

Once again it's the same thing . Nonetheless in this particular case a
lot of economy can be made by following a fairly simple strategy
previously followed by TracGVizPlugin [5]_ (... for other purposes
i.e. implement data sources compatible with Google Visualization API
;) and also experimented in RestOnTracPlugin [4]_ , even if not
published yet ;) . It happens that most of XML-RPC handlers associated
to resources (e.g. tickets , wiki , ...) have an identifier and
provide the following methods

  - getAll
  - get
  - delete
  - update
  - create

have you ever seen anything so RESTful ? ;)
So it's possible to implement a generic REST frontend and perform
automatic translations by mapping REST requests to exsiting RPC
handlers methods , thus reusing existing code .

[...]
>
> Now, all this plugins (products, relations, import, export, search, white
> labeling, new search...) will either have to know filthy little details
> about each other

yes . they only need to know what interface to implement in order to
something they need to do

> (complex inter-plugin dependency)

not necessarily ... if you are familiar with inversion of control ,
aspect oriented programming and similar technologies you'll realize
that this conclusion is not always right . Indeed ExtensionOption may
be seen as some kind of inversion of control mechanism ... I don't
recall if there is a supported generic way to do these kinds of things
(i.e. IoC containers) in Trac , but I've never needed such bloody
monsters ...

> or some super heavy
> shifting in the plugin interface will be necessary.

That's what ITemplateStreamFilter interface is for . E.g. ticket
dependency plugins rely on this interface to insert information
(dependency UI) in existing web pages . And it all follows the same
principle mentioned above .

Aren't Trac & Genshi lovely ?

> And that super heavy
> shifting will have to be pushed back to Trac (if it wants it)

... nope ... no need to

> and only then
> to these plugins

... no ...

> or create new Bloodhound plugin API on top of Trac plugin
> API and then request plugin authors to support it.
>

we should avoid doing these kinds of things .

> Am I missing something?
>

only you can tell ... ;)
we are hanging out around here if you have further questions . always welcome .


.. [1] Project labels
        (http://trac.edgewall.org/wiki/TracDev/Proposals/ProjectLabels)

.. [2] Multiple Projects within a Single Trac Environment
        (http://trac.edgewall.org/wiki/TracMultipleProjects/SingleEnvironment)

.. [3] TagsPlugin
        (http://trac-hacks.org/wiki/TagsPlugin)

.. [4] Publish Trac data via a REST-ful interface
        (http://trac-hacks.org/wiki/RestOnTracPlugin)

.. [5] Integrate Trac with Google Visualization API
        (http://trac-hacks.org/wiki/TracGvizPlugin)

.. [6] Trac Relations
        (http://trac.edgewall.org/wiki/TracDev/Proposals/TracRelations)


-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Mime
View raw message