Hi all ! In the last few days we at the Apache™ Bloodhound project have been performing deep intellectual efforts in order to find ways to obtain a solid, maintainable implementation of multi-products (multi-project) support in a single environment with a fairly reasonable effort .
<joke> ... yes, we have crystal bowls now to see the future ... </joke> We came up with ways to achieve almost-full compatibility at the API level with current multi-environment setups. This is important in order to not to rewrite plugins to make them product-aware . Below you'll find a fragment of a still open discussion in bloodhound-...@incubator.apache.org mailing list . On 11/20/12, Olemis Lang <ole...@gmail.com> wrote: > On 11/20/12, Gary Martin <gary.mar...@wandisco.com> wrote: >> On 20/11/12 09:24, Peter Koželj wrote: [...] >>> I suspect there is no way that we can introduce multiproduct without >>> making >>> plugins aware of it. > > Playing with existing extension points , well , hopefully something > can be done . > >>> Even if we manage to keep API compatibility, >>> multiproduct unaware plugins behavior will very likely be undesired the >>> moment the users creates the second product. So we will need a list of BH >>> compatible/optimized plugins, at which point we can almost beak Trac API >>> compatibility in exchange for more streamlined implementation and user >>> experience. It is a tough problem to crack :( >> >> Well, it is something to look into. API compatibility doesn't seem too >> difficult if we are able to detect the difference between the >> environments and others are willing to play along with the idea. >> > > API compatibility on its own is not the main issue , considering the > fact that for components product-specific world will look exactly the > same as before . Semantically products are also exactly the same thing > . The main obstacle to succeed is database access. The fact that Trac > code base makes use of explicit SQL queries all the time is creating > such a problem due to the fact that current DB schema is not designed > for this particular purpose . If we only had a way to hide database > base access behind DAO [1]_ [2]_ [3[_ it would be much more easy to > override legacy environment-aware DAO and inject equivalent > product-aware DAO so as to make everything work in a magic , beautiful > way . Then we all would be happy, but no . The fact is that Trac-dev > has decided not to do so for a long time (do not ask me about the > reasons). > > <joke> > Oh , mighty Java Beans ! > I miss you so much . If you only were more ... Pythonic > </joke> > > Maybe an option is to refactor Trac code base to introduce DAO (call > them models or not , using ORMs or not ...) before moving forward with > all this. Once that will be done then implement equivalent > product-aware DAO . Of course , in order to make all this work in a > way we can manage it'd be better if Trac-dev accepts the idea and > incorporates such changes into core. > > .. [1] DAO = Data Access Object pattern > (http://en.wikipedia.org/wiki/Data_access_object) > > .. [2] Core J2EE Patterns - Data Access Object > (http://www.oracle.com/technetwork/java/dataaccessobject-138824.html) > > .. [3] DAO = Data Access Object pattern > > (http://www.roseindia.net/tutorial/java/jdbc/dataaccessobjectdesignpattern.html) So ... to the point . Let's consider that we (Apache™ Bloodhound project) spend some time refactoring Trac core in order to encapsulate data-access operations behind some kind of interface. The ultimate goal would be to eliminate the current dependency with hard-coded SQL queries based on current database schema (i.e. things happening on top of DB connection abstraction layer, but beneath Trac business logic layer) so that we could be able to override default implementation (i.e. current SQL queries) with our own implementation . The questions are : 1. What would be the recommended approach to get this done ? 2. Would such changes be committed into Trac trunk (if they work just like before, of course) eventually ? I ask this in order to know whether we could contribute some patches so that both projects could continue in synch and we can continue incorporating further changes from Trac trunk ... in case we decide to do so, of course . I look forward to your comments . Thanks in advance . PS: I know you have rejected the use of ORMs before , but this is substantially different (... I guess ...) and IMO very important for us. -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
