This message might be a bit OT in the sense that it's mostly about Bloodhound , but related in the sense that it's about multi-product . I'm sending it to the list in spite of clarifying what's the current (and expected) state of MP support in Bloodhound , which might be helpful to the OP .
On 10/10/13, Saint Germain <[email protected]> wrote: > On 10 October 2013 13:54, Brettschneider Falk > <[email protected]> wrote: >> It would be quite a manageable job to integrate the approach of having >> multiple projects in one Trac instance in a way like >> SimpleMultiProjectPlugin or Bloodhound does. But as far as I understood >> the situation, the difficulty, why nobody started to implement it, is that >> such approach should be at the same time generic enough that it is able to >> handle multiple projects spread around multiple Trac instances. I'm not sure I get all the implications of the paragraph above , but jftr Apache™ Bloodhound implements full support for multiple projects , in the sense that new (product) environments are implemented inside the (now global) environment , thus sharing a single DB . https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003 The most obvious evidence of this fact is trac-admin commands . Since Bloodhound >= 0.6 (currently stable=0.7 & dev=0.8) all admin commands are available for products by executing {{{#!sh $ trac-admin /path/to/env product admin <prefix> <admin sub-command> }}} where - prefix = product ID - admin sub-command : is any valid command , e.g. permission list , config ... , wiki ... , version ... , repository ... and so on * exceptions are global commands e.g. initenv, upgrade , deploy , ... Few minutes ago I added some patches with test cases for isolation across product environment boundaries https://issues.apache.org/bloodhound/ticket/388 ... and we'll be working towards improved mechanisms for separation vs sharing of product and global resources . >> If it were >> up to me, I would simply define that complexity as not supported at all, >> but it's more or less planned the way as written down here: >> http://trac.edgewall.org/wiki/TracDev/Proposals/MultipleProject. IMO the >> reason why most people have multiple Trac instances is that this way >> they've found a workaround for the missing multiple-project feature. >> By the way , in Bloodhound it is possible to have multiple (product) environments stored in a single DB (i.e. in a single table) . I'll illustrate a deployment for you to understand a few important aspects of this . In our servers there is 1. a single apache2 server and a single <VirtualHost /> definition . 2. We have separate global environments (i.e. independent FS folders, and DBs) bound to different second-level domains (e.g. blood-hound.net , ... but not olemix.com read below ;) . 3. Inside each environment there are products , bound to sub-domains e.g. dataviz.blood-hound.net , widgets.blood-hound.net , dutest.olemix.com (<= to be deployed ;) ... ... this is pretty much inspired on (babel | genshi | trac).edgewall.org deployment Under the hood at the core of Bloodhound there are some objects we call «web bootstrap handlers» which are responsible for routing web requests to a given (global | product) environment . There's a default bootstrap handler in BH core . Nevertheless , in order to implement (1)-(3) above we have developed our own custom classes powered by Routes web framework (<= btw , this was the original proposal for bep 3 but was rejected) which means that it's possible to bind global + product envs to any imaginable URL scheme (... as long as it will be matched by Routes definitions, of course ...) . Indeed we have recently enhanced our lib to support individual (per-global environment) bindings for global env so that e.g. blood-hound.net will be bound to that global env whereas the global env at olemix.com will be available at projects.olemix.com (<= again to be deployed ;) As a consequence setting up a whole new SLD is just a matter of creating a new env (using BH installer script ;) with a name matching the SLD , configuring users + permissions + DNS <ot> In a recent article (lang=es) I wrote for TuxInfo 61 [1]_ I illustrated the whole installation procedure [2]_ for two environments having different DBs (i.e. PostgreSQL and SQLite) each one with their own products and published via HTTP using a single tracd server (... article series is to be continued , including forthcoming tutorial for sub-domain deployments , in case you want to follow it ;) </ot> Of course there are a few rough edges we still have to polish for 0.8 and/or 0.9 e.g. https://issues.apache.org/bloodhound/ticket/618 . It's just a matter of time to get there ;) >>> >>> Sadly I don't know enough about programming to help implementing this, >>> but I can surely participate financially (at least 500-1000 euros). >> This sounds very cool. >> >>> Do you think that it would be a good idea to crowd funding this ? >> >> I'm sure there are enough freelancers willing to implement with the help >> of such fund. >> I don't have enough skills and time to do that integration. >> > > Ok I can help preparing a proposition for funding. I would just like > the opinion of Trac core developers about this before starting > anything. > If you are interested on sponsoring development of BH plugins you can contact me . My team has developed a few plugins and extensions . With some extra funding I could allocate more resources and move faster . BTW, some of our (near) future targets are listed here http://blood-hound.net/products >>> By the way, is the collaboration with Apache Bloodhound working ? >>> I don't know if there is any exchange of code with Trac (one way or the >>> other). >> >> Likely rjollos is the missing link, 24/7 coder, I've never seen breaks >> between his activities longer than 10 minutes. ;) >> > > I just had a look and it seems that changes from Trac are planned to > be incorporated in Bloodhound. Yes > However the reverse is not really done yet (or maybe I have not looked > hard enough). > All changes we make in our local copy of Trac core that are suitable to be backported into Trac are proposed . I recall for instance IResourceChangeListener interface ... but not limited to that . Ryan has been porting changes in both directions . > It would be better not to end up with 2 different implementations for > this MultiProject feature. > jftr Bloodhound is quite different to SimpleMultiprojectPlugin , just choose the one that better fits your particular purpose . > But well I have read a little on the history behind these 2 projects It's mostly documented in trac-dev ML , in messages sent around mid-2011 or so ... > and I understand that it is not that simple. We merge stable releases of Trac into our copy . Nonetheless as we move forward we diverge more and more wrt Trac core and the task of applying our modifications is not trivial . Trac=1.0.2 will be merged into BH core shortly after it will be released , but some patches have been applied in advance . [...] .. [1] http://www.tuxinfo.com.ar/tuxinfo/?p=948 .. [2] https://issues.apache.org/bloodhound/wiki/BloodhoundInstall -- Regards, Olemis - @olemislc Apache™ Bloodhound contributor http://issues.apache.org/bloodhound http://blood-hound.net Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Popularidad de Python, septiembre 2013 - http://goo.gl/fb/tr0XB -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/groups/opt_out.
