[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis Diff URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=30 Revision 30 Comment: bep:0003 Listing tickets in reference implementation section . Status = Accepted Changes: ---8--8--8--8--8--8--8--8 Index: Proposals/BEP-0003 = --- Proposals/BEP-0003 (version: 29) +++ Proposals/BEP-0003 (version: 30) @@ -8,7 +8,7 @@ || '''Version''' || || || '''Last-Modified''' || || || '''Author''' || The Bloodhound project || -|| '''Status''' || Draft || +|| '''Status''' || Accepted || || '''Type''' || Standards Track || || '''Content-Type''' || [wiki:PageTemplates/Proposals text/x-trac-wiki] || || '''Created''' || || @@ -682,6 +682,8 @@ }}} +[[Widget(TicketQuery, query=keywords=~bep-0003, title=BEP 3 ticket summary)]] + == Resources #resources Source code management is powered by [http://subversion.apache.org/ Apache™ Subversion]. ---8--8--8--8--8--8--8--8 -- Page URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003 Apache Bloodhound https://issues.apache.org/bloodhound/ The Apache Bloodhound (incubating) issue tracker This is an automated message. Someone added your email address to be notified of changes on 'Proposals/BEP-0003' page. If it was not you, please report to .
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis Diff URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=31 Revision 31 Comment: bep:0003 Columns in ticket list Changes: ---8--8--8--8--8--8--8--8 Index: Proposals/BEP-0003 = --- Proposals/BEP-0003 (version: 30) +++ Proposals/BEP-0003 (version: 31) @@ -682,7 +682,7 @@ }}} -[[Widget(TicketQuery, query=keywords=~bep-0003, title=BEP 3 ticket summary)]] +[[Widget(TicketQuery, query=keywords=~bep-0003col=idcol=summarycol=statuscol=prioritycol=milestone, title=BEP 3 ticket summary)]] == Resources #resources ---8--8--8--8--8--8--8--8 -- Page URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003 Apache Bloodhound https://issues.apache.org/bloodhound/ The Apache Bloodhound (incubating) issue tracker This is an automated message. Someone added your email address to be notified of changes on 'Proposals/BEP-0003' page. If it was not you, please report to .
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis
Diff URL:
https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=29
Revision 29
Comment: [BEP-0003] Product-specific file system area . Attachments .
Changes:
---8--8--8--8--8--8--8--8
Index: Proposals/BEP-0003
=
--- Proposals/BEP-0003 (version: 28)
+++ Proposals/BEP-0003 (version: 29)
@@ -255,6 +255,23 @@
||= Command =||= Parameters =||= Description =||
|| `deploy-multiproduct` || '''TODO''' || In a way similar to built-in
''deploy'' command it will extract environment assets and create scripts for
[#url-mapping default deployment] via CGI, FastCGI or mod_wsgi. ||
+=== Product file system hierarchy #fs
+
+The subfolder `./products/product prefix` relative to the top-level
directory of the global environment will contain the product file system area.
Attachments for resources owned by a product will be stored in there . Moreover
plugins (e.g. trachacks:GraphvizPlugin) may use it to store files as they did
in single environment deployments .
+
+{{{
+#!div class=well
+{{{
+#!span class=label label-info
+
+Implementation notes
+}}}
+The code of Trac components structures file-system access using paths relative
to the environment's top-level folder . Considering the fact that plugins
migration towards multi-product support should be as smooth as possible the
layout of product file-system area will be exactly the same as before . In
other words , if the global environment's root folder is `/path/to/env` then
the root folder of file-system area for product (prefix) `P` will be
`/path/to/env/products/P` . Attachment `foo.txt` for ticket `42` in product `P`
will be located at
`/path/to/env/products/P/files/attachments/ticket/92c/92cfceb39d57d914ed8b14d0e37643de0797ae56/9206ac42b532ef8e983470c251f4e1a365fd636c.txt`
whereas attachment `foo.txt` for ticket `42` in the global environment will be
located at
`/path/to/env/files/attachments/ticket/92c/92cfceb39d57d914ed8b14d0e37643de0797ae56/9206ac42b532ef8e983470c251f4e1a365fd636c.txt`.
+
+Product-aware components may do a different thing if they need to .
+
+}}}
+
== Rationale #rationale
The following is a list of proposed features for multi product support in
''Bloodhound''. Goals related to compatibility are considered in
[#backwards-compatibility Backwards compatibility] below. In each case you'll
find notes explaining how candidate implementation will solve related issues.
@@ -606,6 +623,10 @@
- ''Sourceforce.net'' and other instances of
[http://incubator.apache.org/projects/allura.html Allura]
- [https://www.assembla.com/features/bug-tracking Assembla]
+=== Product attachments #attachments
+
+Each product will have a separate set of attachments . This means that ticket
`1` in product `P1` and ticket `1` in product `P2` may have attachments with
the same name but different contents .
+
=== Other minor features #misc
System information has to be consistent across product environments .
---8--8--8--8--8--8--8--8
--
Page URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003
Apache Bloodhound https://issues.apache.org/bloodhound/
The Apache Bloodhound (incubating) issue tracker
This is an automated message. Someone added your email address to be
notified of changes on 'Proposals/BEP-0003' page.
If it was not you, please report to .
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis
Diff URL:
https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=28
Revision 28
Comment: [BEP-0003] Sync with comment:7:ticket:115
Changes:
---8--8--8--8--8--8--8--8
Index: Proposals/BEP-0003
=
--- Proposals/BEP-0003 (version: 27)
+++ Proposals/BEP-0003 (version: 28)
@@ -42,7 +42,7 @@
=== Product extensions to the trac.env.Environment API #product-env-api
-There is no need to create ''product environments'' explicitly via [TracAdmin
trac-admin] commands. Provided that the target product exists in the database,
they will be instantiated like shown in the following code snippet. The
instance of `trac.env.Environment` representing the global environment will be
accessed via `parent_env` attribute. The target product will be available in
`product` attribute.
+There is no need to create ''product environments'' explicitly via [TracAdmin
trac-admin] commands. Provided that the target product exists in the database,
they will be instantiated like shown in the following code snippet. The
instance of `trac.env.Environment` representing the global environment will be
accessed via `parent` attribute. The target product will be available in
`product` attribute.
{{{
#!py
@@ -51,7 +51,7 @@
trac.env.Environment object at 0x7faacb1e9490
from multiproduct.env import ProductEnvironment
product_env = ProductEnvironment(env, product_prefix)
- product_env.parent_env
+ product_env.parent
trac.env.Environment object at 0x7faacb1e9490
product_env.product
multiproduct.model.Product object at 0x35566d0
@@ -96,30 +96,61 @@
}}}
-''Product environments'' will implement both `trac.core.ComponentManager` and
`trac.core.Component` APIs. As a consequence instances will have its own
components cache, which means that every active component class will only have
a single instance for every product environment. They will inherit most of the
properties of the global `trac.env.Environment` by acting as wrappers often
forwarding method calls to be handled by the parent global environment.
-
-The following list explains how product environments will adapt existing
environment API while still being compatible with it.
-
- - '''[=#product-env-config] config''' will contain an
-instance of `trac.config.Configuration` (or equivalent) setup in
+''Product environments'' will implement both `trac.core.ComponentManager` and
`trac.core.Component` APIs. As a consequence instances will have their own
components cache, which means that every active component class will only have
a single instance for every product environment. They will inherit most of the
properties of the global `trac.env.Environment` by acting as wrappers often
forwarding method calls to be handled by the parent global environment.
+
+[=#product-env-members] The following list explains how product environments
will adapt existing environment API while still being compatible with it.
+
+ - [=#product-env-config] '''config''' will contain an
+instance of `multiproduct.config.Configuration` (or equivalent) setup in
such a way that it reads product-specific
-settings from a file located at path
-`./conf/product_product prefix.ini` relative
-to the global environment's directory and
-inherits globals settings stored in
-`./conf/trac.ini` file. Some exceptions needs to
+settings from the database . It will inherit globals settings stored in
+`./conf/trac.ini` file and relative paths will be resolved with respect
+to `./conf` sub-folder. Some exceptions to common behavior need to
be installed in place.
* '''TODO'''
- - '''[=#product-env-shared_plugins_dir] shared_plugins_dir''' will always be
empty . There
+ - [=#product-env-shared_plugins_dir] '''shared_plugins_dir''' will always be
empty . There
will be no way to deploy plugins for a particular
product, just enable/disable those installed in
the global environment.
- - '''[=#product-env-system_info_providers] system_info_providers''' will
enumerate
+ - [=#product-env-system_info_providers] '''system_info_providers''' will
enumerate
components in the global environment implementing `ISystemInfoProvider`.
- - '''[=#product-env-setup_participants] setup_participants''' will always be
empty.
- - '''TODO'''
-
-[=#product-env-idem] The following methods and options will behave exactly the
same as the corresponding `parent_env`'s methods: ''get_system_info'' ,
''components_section'' , '''TODO''' .
+ - [=#product-env-setup_participants] '''setup_participants''' will always be
empty.
+ - [=#product-env-base_url] '''base_url''' '''TODO'''
+ - [=#product-env-base_url_for_redirect] '''base_url_for_redirect'''
'''TODO'''
+ - [=#product-env-project_name] '''project_name''' will be the product name
+ -
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis
Diff URL:
https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=27
Revision 27
Comment: [BEP-0003] Product environment as parametric singletons . Summary of
debate in #bloodhound @ freenode and feedback from brane .
Changes:
---8--8--8--8--8--8--8--8
Index: Proposals/BEP-0003
=
--- Proposals/BEP-0003 (version: 26)
+++ Proposals/BEP-0003 (version: 27)
@@ -69,6 +69,30 @@
TypeError: Initializer must be called with
trac.env.Environment instance as first argument
(got multiproduct.env.ProductEnvironment instance instead)
+
+}}}
+
+''Product environments'' are [http://www.jot.fm/issues/issue_2007_03/column2/
parametric singletons] on the combination of environment and product prefix .
In other words this means that
+
+{{{
+#!py
+
+ ProductEnvironment(env, prefix) is ProductEnvironment(env, prefix)
+True
+
+}}}
+
+
+{{{
+#!div class=well
+
+{{{
+#!span class=label label-info
+
+ Implementation notes
+}}}
+
+In order to make this happen and yet avoid object explosion , some caching
strategy (e.g.
[http://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used LRU cache]
like [http://docs.python.org/dev/library/functools.html#functools.lru_cache
functools.lru_cache] or equivalent) should be installed in place , maybe
combined with [http://docs.python.org/2.7/library/weakref.html weak references]
.
}}}
---8--8--8--8--8--8--8--8
--
Page URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003
Apache Bloodhound https://issues.apache.org/bloodhound/
The Apache Bloodhound (incubating) issue tracker
This is an automated message. Someone added your email address to be
notified of changes on 'Proposals/BEP-0003' page.
If it was not you, please report to .
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis Diff URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=25 Revision 25 Comment: [BEP-0003] Product environment and setup participants (e.g. database upgrades) Changes: ---8--8--8--8--8--8--8--8 Index: Proposals/BEP-0003 = --- Proposals/BEP-0003 (version: 24) +++ Proposals/BEP-0003 (version: 25) @@ -90,6 +90,9 @@ will be no way to deploy plugins for a particular product, just enable/disable those installed in the global environment. + - '''[=#product-env-system_info_providers] system_info_providers''' will enumerate +components in the global environment implementing `ISystemInfoProvider`. + - '''[=#product-env-setup_participants] setup_participants''' will always be empty. - '''TODO''' [=#product-env-idem] The following methods and options will behave exactly the same as the corresponding `parent_env`'s methods: ''get_system_info'' , ''components_section'' , '''TODO''' . @@ -167,7 +170,7 @@ Another change required is the change of the fore mentioned table keys. As it currently stands, the key used in these tables is limited to the 'name' field. As this (in the modified schema) prevents users from creating versions/milestones/... with the same name for different products, key should be extended with the 'product' field. - Legacy schema compatibility + Legacy schema compatibility #db-compatibility As changing trac database schema (by adding product column) to the required tables will brake compatibility with existing trac code/3rd party plugins, a solution is required to solve that. @@ -188,7 +191,7 @@ * queries targeted at 3rd party plugin tables are modified to prefix 3rd party plugin table names with product prefix * in addition to DML, DDL statements (CREATE TABLE/INDEX, ALTER TABLE/CONSTRAINT, DROP TABLE) are also translated -= trac tables += Trac tables #sql-tx-trac Some examples: @@ -319,7 +322,7 @@ AND name=%s }}} -= 3rd party plugin tables += 3rd party plugin tables #sql-tx-plugins Similar to trac tables, 3rd party plugin SQLs are translated before hitting the SQL server. The difference is that in addition to productizing the trac tables, @@ -412,7 +415,14 @@ }}} Product environments are meant to implement `trac.core.ComponentManager` API and inherit global plugins installations by design. Hence every component class will have a singleton instance for each product (besides the one for the global environment). Components are enabled/disabled via `[components]` section in configuration file. The fact that each product will have a [#config separate configuration file] also means that there will be one such section to enable/disable each class on a per product basis. -This situation is quite similar to what happens nowadays in multi-environment installations. +This situation is quite similar to what happens nowadays in multi-environment installations. The main difference will be that a component may be enabled for a given product only if it's been previously enabled for the global environment . This constraint is aimed at scoping environment setup tasks (e.g. database updgrades) in the context of the global environment. Product environments will not participate at all in this process so as to avoid some undesired side-effects . One of them is explained below . + +Let's suppose plugins may be enabled at will in both global environment and product environments. Initially environment state is steady . Component `C` is installed but it has never been enabled . It requires a database upgrade . Suddenly it's enabled for product `P1` . As a consequence environment upgrade should be applied (new tables, etc ...) . Such upgrade will only be possible if an instance of `C` announces that such changes must be carried out. However there will be no such setup participant neither in the global environment list nor any other product environment besides `P1` . Summarizing, allowing for such scattered differences may lead to + + 1. Inconsistences across products requiring different upgrades but sharing the same underlying database . + 2. Complicated administration commands and related architecture . + 3. Annoying 'needs upgrade' messages showing any time and degrading user experience . + 4. Unnecessary administration overhead . }}} @@ -739,6 +749,10 @@ - ''Sourceforce.net'' and other instances of [http://incubator.apache.org/projects/allura.html Allura] - [https://www.assembla.com/features/bug-tracking Assembla] +=== Other minor features #misc + +System information has to be consistent across product environments . + == Rejected ideas #rejected Many interesting ideas have been proposed but not all could make their way into final specification because of conceptual, practical or
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by jure
Diff URL:
https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=23
Revision 23
Comment: Legacy schema compatibility
Changes:
---8--8--8--8--8--8--8--8
Index: Proposals/BEP-0003
=
--- Proposals/BEP-0003 (version: 22)
+++ Proposals/BEP-0003 (version: 23)
@@ -167,6 +167,226 @@
Another change required is the change of the fore mentioned table keys. As it
currently stands, the key used in these tables is limited to the 'name' field.
As this (in the modified schema) prevents users from creating
versions/milestones/... with the same name for different products, key should
be extended with the 'product' field.
+ Legacy schema compatibility
+
+As changing trac database schema (by adding product column) to the required
tables will brake compatibility with existing trac code/3rd party plugins, a
solution is required to solve that.
+
+Requirements for this solution:
+* no code changes are required within trac/3rd party plugins to operate within
this new schema/environment
+* trac/3rd party plugins should see a view of the database depending on what
product scope is currently active
+
+As existing trac/3rd party plugin code should remain unchanged, the only way
of accomplishing legacy compatibility with the new database schema is to
develop a component, that installs itself directly above the database access
layer. By intercepting SQL statements and transforming them, trac/3rd party
plugins are given a view of the database that corresponds to the currently
active product scope.
+
+Currently all database access is handled by trac class `IterableCursor`. A new
class is implemented called `BloodhoundIterableCursor` that replaces the
`IterableCursor` in runtime.
+
+Functionality of this class is the following:
+* parse SQLs targeted at the database
+* depending to which table the SQL is targeted, the following transformation
is done on the SQL
+ * for system tables or tables that do not require productization, SQL is
passed unchanged
+ * for 'productized' trac tables mentioned above, a product view of the table
is presented to the code
+* only DML statements (SELECT, INSERT, UPDATE, DELETE) are translated
+ * queries targeted at 3rd party plugin tables are modified to prefix 3rd
party plugin table names with product prefix
+* in addition to DML, DDL statements (CREATE TABLE/INDEX, ALTER
TABLE/CONSTRAINT, DROP TABLE) are also translated
+
+= trac tables
+
+Some examples:
+
+**SELECT**
+
+A query targeted at productized trac tables:
+
+{{{#!sql
+SELECT COUNT(*)
+FROM
+ (SELECT t.id AS id,
+ t.summary AS summary,
+ t.owner AS OWNER,
+ t.status AS status,
+ t.priority AS priority,
+ t.milestone AS milestone,
+ t.time AS time,
+ t.changetime AS changetime,
+ priority.value AS priority_value
+ FROM ticket AS t
+ LEFT OUTER JOIN enum AS priority ON (priority.type='priority'
+AND priority.name=priority)
+ LEFT OUTER JOIN milestone ON (milestone.name=milestone)
+ WHERE ((COALESCE(t.status,'')!=%s)
+ AND (COALESCE(t.OWNER,'')=%s))
+ ORDER BY COALESCE(t.milestone,'')='',
+COALESCE(milestone.completed,0)=0,
+milestone.completed,
+COALESCE(milestone.due,0)=0,
+milestone.due,
+t.milestone,
+COALESCE(priority.value,'')='' DESC,
+CAST(priority.value AS integer) DESC,
+t.id) AS x
+}}}
+
+... would be, when executed within 'MYPRODUCT' scope, translated into ...
+
+{{{#!sql
+SELECT COUNT(*)
+FROM
+ (SELECT t.id AS id,
+ t.summary AS summary,
+ t.owner AS OWNER,
+ t.status AS status,
+ t.priority AS priority,
+ t.milestone AS milestone,
+ t.time AS time,
+ t.changetime AS changetime,
+ priority.value AS priority_value
+ FROM
+ (SELECT *
+ FROM ticket
+ WHERE product=MYPRODUCT) AS t
+ LEFT OUTER JOIN
+ (SELECT *
+ FROM enum
+ WHERE product=MYPRODUCT) AS priority ON (priority.type='priority'
+ AND priority.name=priority)
+ LEFT OUTER JOIN
+ (SELECT *
+ FROM milestone
+ WHERE product=MYPRODUCT) AS milestone ON (milestone.name=milestone)
+ WHERE ((COALESCE(t.status,'')!=%s)
+ AND (COALESCE(t.OWNER,'')=%s))
+ ORDER BY COALESCE(t.milestone,'')='',
+COALESCE(milestone.completed,0)=0,
+milestone.completed,
+COALESCE(milestone.due,0)=0,
+milestone.due,
+t.milestone,
+COALESCE(priority.value,'')='' DESC,
+CAST(priority.value AS integer) DESC,
+t.id) AS x
+}}}
+
+**INSERT**
+
+INSERTs are translated by adding 'product' column with
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by jure Diff URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=24 Revision 24 Comment: Legacy schema compatibility typos ... Changes: ---8--8--8--8--8--8--8--8 Index: Proposals/BEP-0003 = --- Proposals/BEP-0003 (version: 23) +++ Proposals/BEP-0003 (version: 24) @@ -353,13 +353,13 @@ GROUP BY bklg_id, status }}} -***UPDATE, DELETE, INSERT*** +**UPDATE, DELETE, INSERT** UPDATE, DELETE and INSERT statements are not modified for 3rd party plugin tables, except for prefixing the table name with the active scope product prefix. -***CREATE, ALTER, DROP*** +**CREATE, ALTER, DROP** For 3rd party plugin tables, DDL SQLs are also translated by prefixing table names and constraint names. ---8--8--8--8--8--8--8--8 -- Page URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003 Apache Bloodhound https://issues.apache.org/bloodhound/ The Apache Bloodhound (incubating) issue tracker This is an automated message. Someone added your email address to be notified of changes on 'Proposals/BEP-0003' page. If it was not you, please report to .
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis Diff URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=21 Revision 21 Comment: [BEP-0003] Oops ! PEP = BEP Changes: ---8--8--8--8--8--8--8--8 Index: Proposals/BEP-0003 = --- Proposals/BEP-0003 (version: 20) +++ Proposals/BEP-0003 (version: 21) @@ -3,7 +3,7 @@ [[PageOutline]] -|| '''PEP''' || 3 || +|| '''BEP''' || 3 || || '''Title''' || Multi-product architecture || || '''Version''' || || || '''Last-Modified''' || || ---8--8--8--8--8--8--8--8 -- Page URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003 Apache Bloodhound https://issues.apache.org/bloodhound/ The Apache Bloodhound (incubating) issue tracker This is an automated message. Someone added your email address to be notified of changes on 'Proposals/BEP-0003' page. If it was not you, please report to .
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by jure Diff URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=17 Revision 17 Changes: ---8--8--8--8--8--8--8--8 Index: Proposals/BEP-0003 = --- Proposals/BEP-0003 (version: 16) +++ Proposals/BEP-0003 (version: 17) @@ -94,6 +94,23 @@ [=#product-env-idem] The following methods and options will behave exactly the same as the corresponding `parent_env`'s methods: ''get_system_info'' , ''components_section'' , '''TODO''' . +=== Database schema changes #database-schema-changes + +Products shall become a first-class citizen in ''Bloodhound''. To make this possible, some changes will be required at the database schema level, especially as multiple product environments are meant to be hosted in the same database instance. + +Currently, products are only supported in relation to tickets. Current implementation of `bloodhound_multiproduct` plugin extends the `ticket` table by adding custom field `product`. This field is used to reference products as defined in the `bloodhound_product` table. + +In addition to tickets, other entities should also be made ''product aware''. The product support should be, in a similar way to tickets, extended to (at least) the following database entities within ''Bloodhound'': +* versions +* milestones +* components +* priorities +* ... + +This could be accomplished using the same approach as used in relation to tickets - by extending the database tables with the 'product' field that would reference the product that the specified entities belong to. + +Another change required is the change of the fore mentioned table keys. As it currently stands, the key used in these tables is limited to the 'name' field. As this (in the modified schema) prevents users from creating versions/milestones/... with the same name for different products, key should be extended with the 'product' field. + == Rationale #rationale The following is a list of proposed features for multi product support in ''Bloodhound''. Goals related to compatibility are considered in [#backwards-compatibility Backwards compatibility] below. In each case you'll find notes explaining how candidate implementation will solve related issues. ---8--8--8--8--8--8--8--8 -- Page URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003 Apache Bloodhound https://issues.apache.org/bloodhound/ The Apache Bloodhound (incubating) issue tracker This is an automated message. Someone added your email address to be notified of changes on 'Proposals/BEP-0003' page. If it was not you, please report to .
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis
Diff URL:
https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=18
Revision 18
Comment: [BEP-0003] External environment routes (using Routes framework)
Changes:
---8--8--8--8--8--8--8--8
Index: Proposals/BEP-0003
=
--- Proposals/BEP-0003 (version: 17)
+++ Proposals/BEP-0003 (version: 18)
@@ -94,6 +94,58 @@
[=#product-env-idem] The following methods and options will behave exactly the
same as the corresponding `parent_env`'s methods: ''get_system_info'' ,
''components_section'' , '''TODO''' .
+=== Product routes #routes
+
+[http://routes.groovie.org/ Routes] framework will be used to match URLs based
on predefined patterns and use this information to dispatch requests addressed
to product environments. This will introduce an explicit installation
dependency with that framework.
+
+In first place there will be an instance of `routes.mapper.Mapper`. It will
contain the definitions of the routes used to access product environments and
their resources. Some variables in routes definitions will have special meaning
though.
+
+||= Variable =||= Purpose =||= Observations =||
+|| `controller` || ''Ignored'' || ||
+|| `action` || ''Ignored'' || ||
+|| `envname` || Target environment name || Only used in multiple environment
mode to determine target environment folder. Ignored otherwise. ||
+|| `product` || Target product prefix || Represents ||
+|| `path_info` || Path to product resource or view || Since paths under
product base URL will be used to access anything that could be considered as
belonging to the product, route definitions often will include
[http://routes.readthedocs.org/en/latest/setting_up.html#magic-path-info
path_info] to shift `SCRIPT_NAME` and `PATH_INFO` ''WSGI'' variables as
expected ||
+
+Considering the previous discussion ''Bloodhound'' will provide a modified
copy of the main entry point for the web interface (i.e. the
[http://www.python.org/dev/peps/pep-0333/ WSGI] function
`trac.web.main.dispatch_request`) to make it aware of external routing
information. It will be wrapped by a `routes.middleware.RoutesMiddleware`
object responsible for route matching and ''WSGI'' environment updates. This
fact is important to understand subsequent discussion taking place in this
section.
+
+Aforementioned data will be considered to dispatch requests in addition to the
existing ''WSGI'' environment variables (i.e. `trac.env_path`,
`trac.env_parent_dir`, `trac.env_index_template`, `trac.template_vars`,
`trac.base_url`, `trac.env_paths`) or the equivalent global variables (i.e.
`TRAC_ENV`, `TRAC_ENV_PARENT_DIR`, `TRAC_ENV_INDEX_TEMPLATE`,
`TRAC_TEMPLATE_VARS`, `TRAC_BASE_URL`). The updated copy of
`trac.web.main.dispatch_request` will read routing information like shown below
+
+{{{
+#!py
+
+route = environ.get('routes.route')
+match = environ.get('wsgiorg.routing_args', (None, {}) )[1]
+
+}}}
+
+As a result the following rules will be used to determine the environment
performing subsequent request dispatching :
+
+ - If `match == {}` (equivalent to `route is None`)
+then no route was matched, hence respond with a
+404 (''Not Found'') HTTP status code.
+ - ... else if `match['envname']` is empty then no
+specific environment was requested.
+* For multi-environment deployments
+ (i.e. `TRAC_ENV_PARENT_DIR`) just render an
+ environment index page.
+* For single-environment deployments always
+ instantiate configured environment.
+ - ... for multi-environment deployments, if
+`match['envname']` is not empty then
+instantiate the environment at the corresponding
+child folder of the parent directory.
+ - ... if `match['product']` is empty then the
+global environment found up to this point will dispatch the
+request
+ - ... else if `match['product']` is set then
+[#product-env-api instantiate the product environment]
+for the corresponding product prefix. There will
+an instance of `trac.web.main.RequestDispatcher`
+responsible for dispatching the request.
+
+Sub-paths will be handled from there as usual.
+
=== Database schema changes #database-schema-changes
Products shall become a first-class citizen in ''Bloodhound''. To make this
possible, some changes will be required at the database schema level,
especially as multiple product environments are meant to be hosted in the same
database instance.
@@ -110,6 +162,13 @@
This could be accomplished using the same approach as used in relation to
tickets - by extending the database tables with the 'product' field that would
reference the product that the specified entities belong to.
Another change required is the change of the fore mentioned table keys. As it
currently stands, the key used in these tables is limited to the 'name' field.
As
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis
Diff URL:
https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=12
Revision 12
Comment: [BEP-0003] Disabled State for Multiproduct Components API (rejected)
Changes:
---8--8--8--8--8--8--8--8
Index: Proposals/BEP-0003
=
--- Proposals/BEP-0003 (version: 11)
+++ Proposals/BEP-0003 (version: 12)
@@ -32,7 +32,7 @@
[[Image(Product_envs_small.png, align=right)]]
-In a few words the current proposal tries to reproduce a well-known
[./MultienvParentDir multi-environment setup] inside a single enviroment. In
this section you'll find the most important details necessary to implement
multi-product support. In order to understand the reasons that make this is a
valid and reliable specification, please see [#rationale Rationale] below. In
order and know more about similar alternatives rejected along the way, please
consult [#rejected Rejected ideas] below.
+In a few words the current proposal tries to reproduce a well-known
[./MultienvParentDir multi-environment setup] inside a single enviroment. In
this section you'll find the most important details necessary to implement
multi-product support. In order to understand the reasons that make this a
valid and reliable specification, please see [#rationale Rationale] below. In
order to know more about similar alternatives rejected along the way, please
consult [#rejected Rejected ideas] below.
=== Product environments #product-envs
@@ -70,17 +70,6 @@
trac.env.Environment instance as first argument
(got multiproduct.env.ProductEnvironment instance instead)
-}}}
-
-Instantiating a component involved in multi-product architecture will always
return `None`, just like if it was disabled e.g.
-
-{{{
-#!py
-
- from multiproduct.api import MultiProductSystem
- ps = product_env[MultiProductSystem]
- repr(ps)
-None
}}}
''Product environments'' will implement both `trac.core.ComponentManager` and
`trac.core.Component` APIs. As a consequence instances will have its own
components cache, which means that every active component class will only have
a single instance for every product environment. They will inherit most of the
properties of the global `trac.env.Environment` by acting as wrappers often
forwarding method calls to be handled by the parent global environment.
@@ -259,7 +248,20 @@
Many interesting ideas have been proposed but not all could make their way
into final specification because of conceptual, practical or other reasons.
Below you'll find the most relevant instances together with brief comments
explaining the decision as well as links to relevant messages in
[http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/
bloodhound-dev mailing list archive] .
- '''TODO''' : nothing rejected so far.
+=== Disabled State for Multiproduct Components API (rejected)
#rejected-product-api-disabled
+
+It was suggested that instantiating a component involved in multi-product
architecture should always return `None`, just like if it was disabled e.g.
+
+{{{
+#!py
+
+ from multiproduct.api import MultiProductSystem
+ ps = product_env[MultiProductSystem]
+ repr(ps)
+None
+}}}
+
+This is not recommended. Multi-product API components will play an active role
in customizations at the product level. That will not be possible if they are
disabled.
== Backwards Compatibility #backwards-compatibility
---8--8--8--8--8--8--8--8
--
Page URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003
Apache Bloodhound https://issues.apache.org/bloodhound/
The Apache Bloodhound (incubating) issue tracker
This is an automated message. Someone added your email address to be
notified of changes on 'Proposals/BEP-0003' page.
If it was not you, please report to .
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis
Diff URL:
https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=13
Revision 13
Comment: [BEP-0003] Feature : Import data from other issue tracker systems
Changes:
---8--8--8--8--8--8--8--8
Index: Proposals/BEP-0003
=
--- Proposals/BEP-0003 (version: 12)
+++ Proposals/BEP-0003 (version: 13)
@@ -189,7 +189,6 @@
Components, milestone, version, priority, defaults, custom fields should be
configurable per product.
-
{{{
#!div class=well
@@ -243,6 +242,18 @@
=== Per product repository #vcs
Each product can have different repository (and type) assigned.
+
+=== Data migration #import-export
+
+The final solution will be prepared to import data from other issue tracker
systems and still provide a similar user experience. Important examples to
consider are :
+
+ - Exisiting ''Trac'' and ''Bloodhound'' instances without multi-product
support
+ - [http://www.atlassian.com/en/software/jira/overview JIRA]
+ - [http://www.bugzilla.org/ Bugzilla]
+ - [http://scarab.tigris.org/ Scarab]
+ - [http://www.redmine.org Redmine]
+ - ''Sourceforce.net'' and other instances of
[http://incubator.apache.org/projects/allura.html Allura]
+ - [https://www.assembla.com/features/bug-tracking Assembla]
== Rejected ideas #rejected
---8--8--8--8--8--8--8--8
--
Page URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003
Apache Bloodhound https://issues.apache.org/bloodhound/
The Apache Bloodhound (incubating) issue tracker
This is an automated message. Someone added your email address to be
notified of changes on 'Proposals/BEP-0003' page.
If it was not you, please report to .
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis
Diff URL:
https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=14
Revision 14
Comment: [BEP-003] Sample product URL mappings TODO: Detailed request
dispatching
Changes:
---8--8--8--8--8--8--8--8
Index: Proposals/BEP-0003
=
--- Proposals/BEP-0003 (version: 13)
+++ Proposals/BEP-0003 (version: 14)
@@ -211,15 +211,116 @@
=== Product resources namespaces #url-mapping
-Product and resource ID should form a two dimensional namespace. The mapping
should be flexible enough to support the following scenarios .
-
- - '''Product path namespace''' : '''TODO'''
- - '''Product sub domain''' : '''TODO'''
- - '''Product sub domain + path namespace''' : '''TODO'''
+Product and resource ID should form a two dimensional namespace. The mapping
should be flexible enough to support the scenarios mentioned below. Other
deployments may still be possible but are beyond the scope of this
specification. However , in all cases every requests sent to any path under
product base URL will be handled by the request handlers and filters activated
in the target product environment.
+
+ - [=#deploy-domain] '''Product sub domain''' : The base URL of products
+will be at sibling sub-domains. A well-known
+example is edgewall.org (i.e. bitten.edgewall.org ,
+genshi.edgewall.org , trac.edgewall.org ).
+The global environment may be accessible at one
+such sub-domain, at top level domain, or
+somewhere else.
+
+{{{
+#!div class=well
+
+{{{
+#!span class=label label-info
+
+ Implementation notes
+}}}
+
+'''TODO'''
+
+}}}
+
+ - [=#deploy-sibling-paths] '''Product path namespace''' : Each product is
+accessible at sibling paths on the same domain.
+The global environment will be available either at
+one such path or somewhere else.
+
+{{{
+#!div class=well
+
+{{{
+#!span class=label label-info
+
+ Implementation notes
+}}}
+
+This case is very similar to the [./MultienvParentDir reference
multi-environment setup] .
+
+'''TODO'''
+
+}}}
+
+ - [=#deploy-global-env-embed] '''Embedded product path namespace''' : Each
+product is accessible at sibling paths inside
+the URL space of the global environment.
+
+{{{
+#!div class=well
+
+{{{
+#!span class=label label-info
+
+ Implementation notes
+}}}
+Even if this case is very similar to the [./MultienvParentDir reference
multi-environment setup] a better match will be another setup based on
[trac:wiki:TracWsgiPlugin]. The main difference with respect to
[#deploy-sibling-paths sibling paths] deployment is that the global environment
plays an active role dispatching the requests addressed to an specific product
by forwarding them to the corresponding product environment.
+
+'''TODO'''
+
+}}}
+
+ - [=#deploy-domain-path] '''Product sub domain + path namespace''' :
+In this case product prefix will be
+matched against URL sub domain whereas
+''Bloodhound'' will be accessed at a given path
+inside of it. This case is frequently offered by
+hosting providers like forges deploying multiple
+web applications for projects . In general
+product base URL will look like
+`http://product prefix.domain.tld/path/to/bloodhound` .
+
+{{{
+#!div class=well
+
+{{{
+#!span class=label label-info
+
+ Implementation notes
+}}}
+
+'''TODO'''
+
+}}}
+
+ - [=#deploy-domain-path] '''Arbitrary product path namespace''' :
+Sometimes hosting providers like forges do not
+support sub-domains for products. Hence
+product prefix is included in URL.
+In general, product base URLs will look like this
+`http://domain.tld/path/to/product prefix/path/to/bloodhound` .
+One such hypothetical example would be
+`http://sourceforge.net/p/product prefix/bloodhound` .
+
+
+{{{
+#!div class=well
+
+{{{
+#!span class=label label-info
+
+ Implementation notes
+}}}
+
+'''TODO'''
+
+}}}
'''FIXME''' also be addressable through the product URL namespace, namely
/ticket/product prefix/local ticket id.
-In a multi-product configuration product resources should not be accessed
using current global URL scheme (i.e.
/path/to/bloodhound/environment/realm/id). '''TODO''' why ?
+In a multi-product configuration product resources should not be accessed
using current global URL scheme (i.e.
/path/to/bloodhound/environment/realm/id). Since [#permissions products
will have their own permissions schema] then requests handled by components in
the context of the top-level environment will perform neither the right
permissions checks nor even use appropriate settings , and so on ... The same
will happen for resources moved between products . In general such requests
should be redirected to a URL under the namespace of resource's product.
Tickets #tickets-namespace
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis Diff URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=16 Revision 16 Comment: [BEP-0003] Oops ! TH InterTrac prefix not available . Using !TracHacks InterWiki prefix instead ... :-/ Changes: ---8--8--8--8--8--8--8--8 Index: Proposals/BEP-0003 = --- Proposals/BEP-0003 (version: 15) +++ Proposals/BEP-0003 (version: 16) @@ -266,7 +266,7 @@ Implementation notes }}} -Even if this case is very similar to the [./MultienvParentDir reference multi-environment setup] a better match will be another setup based on [th:wiki:TracWsgiPlugin]. The main difference with respect to [#deploy-sibling-paths sibling paths] deployment is that the global environment plays an active role dispatching the requests addressed to an specific product by forwarding them to the corresponding product environment. +Even if this case is very similar to the [./MultienvParentDir reference multi-environment setup] a better match will be another setup based on [TracHacks:TracWsgiPlugin]. The main difference with respect to [#deploy-sibling-paths sibling paths] deployment is that the global environment plays an active role dispatching the requests addressed to an specific product by forwarding them to the corresponding product environment. '''TODO''' @@ -297,7 +297,7 @@ - [=#deploy-domain-path] '''Arbitrary product path namespace''' : Sometimes hosting providers like forges do not -support sub-domains for products. Hence +support product sub-domains . Hence product prefix is included in URL. In general, product base URLs will look like this `http://domain.tld/path/to/product prefix/path/to/bloodhound` . ---8--8--8--8--8--8--8--8 -- Page URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003 Apache Bloodhound https://issues.apache.org/bloodhound/ The Apache Bloodhound (incubating) issue tracker This is an automated message. Someone added your email address to be notified of changes on 'Proposals/BEP-0003' page. If it was not you, please report to .
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis
Diff URL:
https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=8
Revision 8
Comment: [BEP-0003] Product-specific settings (refs #115) and corollaries
mentioned by jure in [/wiki/Proposals/BEP-0003?version=5 version 5]
Changes:
---8--8--8--8--8--8--8--8
Index: Proposals/BEP-0003
=
--- Proposals/BEP-0003 (version: 7)
+++ Proposals/BEP-0003 (version: 8)
@@ -36,7 +36,7 @@
The key design mechanism is known as ''product environments'' . Their main
goal is to provide components (both in core and those defined by plugins) with
a lightweight virtual representation of an isolated environment inside the
''global'' environment when dealing with requests addressed to a resource owned
by a product. The following figure illustrates how they work.
-[[Image(Product_environments.png)]]
+[[Image(Product_envs_small.png)]]
If you notice similarities with the
[attachment:wiki:Proposals/BEP-0003/MultienvParentDir:Multienv_small.png
reference multi-environment setup] it is an intentional design decision.
@@ -82,12 +82,12 @@
None
}}}
-''Product environments'' will implement both `trac.core.ComponentManager` and
`trac.core.Component` APIs by inheriting most of the properties of the global
`trac.env.Environment`, so they will act as wrappers. As a consequence
instances will have its own components cache, which means that every active
component class will only have a single instance for every product environment.
+''Product environments'' will implement both `trac.core.ComponentManager` and
`trac.core.Component` APIs. As a consequence instances will have its own
components cache, which means that every active component class will only have
a single instance for every product environment. They will inherit most of the
properties of the global `trac.env.Environment` by acting as wrappers often
forwarding method calls to be handled by the parent global environment.
The following list explains how product environments will adapt existing
environment API while still being compatible with it.
- - '''[=#product-env-conf] conf''' will contain an
-instance of `trac.conf.Configuration` (or equivalent) setup in
+ - '''[=#product-env-config] config''' will contain an
+instance of `trac.config.Configuration` (or equivalent) setup in
such a way that it reads product-specific
settings from a file located at path
`./conf/product_product prefix.ini` relative
@@ -108,17 +108,94 @@
The following is a list of proposed features for multi product support in
''Bloodhound''. Goals related to compatibility are considered in
[#backwards-compatibility Backwards compatibility] below. In each case you'll
find notes explaining how candidate implementation will solve related issues.
-=== Per product ticket workflow #workflow
+=== Product components ecosystem #components
+
+All the functionalities installed in the global environment (e.g. blogs,
pastebins) should be available for products as well. Nonetheless they should be
enabled/disabled on a per product basis.
+
+{{{
+#!div class=well
+{{{
+#!span class=label label-info
+
+Implementation notes
+}}}
+Product environments are meant to implement `trac.core.ComponentManager` API
and inherit global plugins installations by design. Hence every component class
will have a singleton instance for each product (besides the one for the global
environment). Components are enabled/disabled via `[components]` section in
configuration file. The fact that each product will have a [#config separate
configuration file] also means that there will be one such section to
enable/disable each one on a per product basis.
+
+This situation is quite similar to what happens nowadays in multi-environment
installations.
+
+}}}
+
+=== Product-specific settings #config
+
+Component settings should be configurable per product. For practical reasons
if there is no explicit option assignment set for a particular product then it
should inherit option value set for the global environment.
+
+{{{
+#!div class=well
+
+{{{
+#!span class=label label-info
+
+ Implementation notes
+}}}
+Product-specific settings will be implemented in #115 .
+
+`trac.conf.Configuration` instance in [#product-env-config config attribute]
of product environments will read settings from `product-product prefix.ini`
file and will be configured to inherit settings in environments' `trac.ini`
file.
+
+Even if the proposal only suggests ''ini files'' to store product-specific
configuration it is also possible to think of using other configuration
repositories (e.g. database, [http://hadoop.apache.org/hdfs/ HDFS], remote data
repositories). It is a feasible enhancement though details have been omitted.
+}}}
+
+The following requirements are a corollary , considering that such
customizations are
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis
Diff URL:
https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=11
Revision 11
Comment: [BEP-0003] Product logo as another special case of product-specific
settings
Changes:
---8--8--8--8--8--8--8--8
Index: Proposals/BEP-0003
=
--- Proposals/BEP-0003 (version: 10)
+++ Proposals/BEP-0003 (version: 11)
@@ -77,7 +77,8 @@
{{{
#!py
- ps = product.api.MultiProductSystem(product_env)
+ from multiproduct.api import MultiProductSystem
+ ps = product_env[MultiProductSystem]
repr(ps)
None
}}}
@@ -110,7 +111,7 @@
=== Product components ecosystem #components
-All the functionalities installed in the global environment (e.g. blogs,
pastebins) should be available for products as well. Nonetheless they should be
enabled/disabled on a per product basis.
+All the functionalities installed in the global environment (e.g. blogs,
pastebins) should be available for products as well. They may be
enabled/disabled on a per product basis.
{{{
#!div class=well
@@ -119,7 +120,7 @@
Implementation notes
}}}
-Product environments are meant to implement `trac.core.ComponentManager` API
and inherit global plugins installations by design. Hence every component class
will have a singleton instance for each product (besides the one for the global
environment). Components are enabled/disabled via `[components]` section in
configuration file. The fact that each product will have a [#config separate
configuration file] also means that there will be one such section to
enable/disable each one on a per product basis.
+Product environments are meant to implement `trac.core.ComponentManager` API
and inherit global plugins installations by design. Hence every component class
will have a singleton instance for each product (besides the one for the global
environment). Components are enabled/disabled via `[components]` section in
configuration file. The fact that each product will have a [#config separate
configuration file] also means that there will be one such section to
enable/disable each class on a per product basis.
This situation is quite similar to what happens nowadays in multi-environment
installations.
@@ -145,6 +146,21 @@
}}}
The following requirements are a corollary , considering that such
customizations are performed in the configuration file.
+
+ Product logo #logo
+
+On accessing resources owned by a product its logo and description will be
shown.
+
+{{{
+#!div class=well
+
+{{{
+#!span class=label label-info
+
+ Implementation notes
+}}}
+Edit `[header-logo]` section in `product-product prefix.ini` file.
+}}}
Per product ticket workflow #workflow
@@ -241,7 +257,7 @@
== Rejected ideas #rejected
-Many interesting ideas have been proposed but not all could make their way
into final specification because of conceptual, practical or other reasons.
Below you'll find the most relevant instances together with brief comments
explaining the decision , and maybe links to relevant messages in
[http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/
bloodhound-dev mailing list archive] .
+Many interesting ideas have been proposed but not all could make their way
into final specification because of conceptual, practical or other reasons.
Below you'll find the most relevant instances together with brief comments
explaining the decision as well as links to relevant messages in
[http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/
bloodhound-dev mailing list archive] .
'''TODO''' : nothing rejected so far.
---8--8--8--8--8--8--8--8
--
Page URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003
Apache Bloodhound https://issues.apache.org/bloodhound/
The Apache Bloodhound (incubating) issue tracker
This is an automated message. Someone added your email address to be
notified of changes on 'Proposals/BEP-0003' page.
If it was not you, please report to .
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis Diff URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=6 Revision 6 Comment: [BEP-0003] Moving goals and features to Rationale section , where they belong Changes: ---8--8--8--8--8--8--8--8 Index: Proposals/BEP-0003 = --- Proposals/BEP-0003 (version: 5) +++ Proposals/BEP-0003 (version: 6) @@ -20,7 +20,7 @@ The evolution on the field of issue tracking systems leads to many requests to support multiple products in a single environment. This document is meant to gather community consensus on the implementation of this feature . Besides it is a starting point to envision the impact on the underlying components architecture and the corresponding development strategies to get everything done. Ultimately it will explore compatibility considerations for existing plugins and suggest recommended upgrade paths so that hacks authors will take advantage of this feature . -[[Image(Multiproduct.png, width=900)]] +[[Image(Multiproduct.png)]] == Motivation == @@ -30,45 +30,65 @@ == Proposal #proposal -The following is a list of proposed features for multi product support in Bloodhound. +'''TODO''' -=== Product/ticket namespaces -Product and ticket ID should form a two dimensional namespace, tickets would in addition to current URL scheme also be addressable through the product URL namespace, namely /ticket/product/id. Each product would have a separate numberspace for product ticket IDs. +== Rationale #rationale -=== Tickets moveable between products +The following is a list of proposed features for multi product support in ''Bloodhound''. Goals related to compatibility are considered in [#backwards-compatibility Backwards compatibility] below. In each case you'll find notes explaining how candidate implementation will solve related issues. + +=== Product resources namespaces #url-mapping + +Product and resource ID should form a two dimensional namespace. The mapping + +Each resource would in addition to current URL scheme also be addressable through the product URL namespace, namely /ticket/product prefix/local ticket id. + + Tickets #tickets-namespace + +Each product would have a separate number sequence for product ticket IDs. + +=== Resources moveable between products #migration-resource + Tickets should be moveable between products, old ticket product IDs (and URLs) should be remembered, making the same ticket accessible through old products namespaces (URLs). -=== Per product search +=== Per product search #search + By default, search is global. Search and queries should allow search queries to be limited to specific product. -=== Per product ticket workflow +=== Per product ticket workflow #workflow + Depending on the product, different ticket workflows should be supported. === Inter product ticket relations + It should be possible to link tickets from different products. === Per product notifications + Notifications should be configurable per product. === Per product ticket field configuration + Components, milestone, version, priority, defaults, custom fields should be configurable per product. -=== Product roles +=== Per product permission scheme #permissions + +Permission scheme is defined by assigning permissions (from a predefined permission list) to specific users or groups. Permission scheme is assigned to a product. + + Product roles #roles + Support for per product user groups. Roles can be used to configure notifications and permissions per product. -=== Per product permission scheme -Permission scheme is defined by assigning permissions (from a predefined permission list) to specific users or groups. Permission scheme is assigned to a product. +=== Per product repository #vcs -=== Per product repository Each product can have different repository (and type) assigned. -== Rationale #rationale +== Rejected ideas #rejected -'''TODO''' +Many interesting ideas have been proposed but not all could make their way into final specification because of conceptual, practical or other reasons. Below you'll find the most relevant instances together with brief comments explaining the decision , and maybe links to relevant messages in [http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/ bloodhound-dev mailing list archive] . == Backwards Compatibility #backwards-compatibility -'''TODO''' +The solution has to be compatible with single product solution whenever possible in order to make possible smooth upgrade paths from previous installations. This is particularly important for plugins to work out-of-the-box under the new circumstances or at least to make easier the upgrade development process for hack authors. == Reference Implementation #reference-implementation
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis
Diff URL:
https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=7
Revision 7
Comment: [BEP-0003] Towards an introduction to product environments (not
finished)
Changes:
---8--8--8--8--8--8--8--8
Index: Proposals/BEP-0003
=
--- Proposals/BEP-0003 (version: 6)
+++ Proposals/BEP-0003 (version: 7)
@@ -24,27 +24,127 @@
== Motivation ==
-Nowadays it is possible to manage multiple projects by creating multiple
environments. As a consequence data is scattered across multiple databases and
maintenance tasks turn out to be more difficult. Since a long time users have
expressed the need for managing multiple ''projects'' in an easy way . In the
case of a family of related products it is usually important to have a unified
view on the development activity as well as the ability to share common
resources among them. Under those circumstances it is convenient to manage
multiple products within a single ''Trac'' environment.
+Nowadays it is possible to manage multiple projects by creating multiple
environments. One notable example is [./MultienvParentDir the multi-environment
setup] considered as a reference for this specification. As a consequence data
is scattered across multiple databases and maintenance tasks turn out to be
more difficult. Since a long time users have expressed the need for managing
multiple ''projects'' in an easy way . In the case of a family of related
products it is usually important to have a unified view on the development
activity as well as the ability to share common resources among them. Under
those circumstances it is convenient to manage multiple products within a
single ''Trac'' environment.
The term ''project'' is very generic and may be confusing considering the
context. Therefore in this specification the word ''product'' is used instead .
== Proposal #proposal
-'''TODO'''
+In a few words the current proposal tries to reproduce a well-known
[./MultienvParentDir multi-environment setup] inside a single enviroment. In
this section you'll find the most important details necessary to implement
multi-product support. In order to understand the reasons that make this is a
valid and reliable specification, please see [#rationale Rationale] below. In
order and know more about similar alternatives rejected along the way, please
consult [#rejected Rejected ideas] below.
+
+=== Product environments #product-envs
+
+The key design mechanism is known as ''product environments'' . Their main
goal is to provide components (both in core and those defined by plugins) with
a lightweight virtual representation of an isolated environment inside the
''global'' environment when dealing with requests addressed to a resource owned
by a product. The following figure illustrates how they work.
+
+[[Image(Product_environments.png)]]
+
+If you notice similarities with the
[attachment:wiki:Proposals/BEP-0003/MultienvParentDir:Multienv_small.png
reference multi-environment setup] it is an intentional design decision.
+
+=== Product extensions to the trac.env.Environment API #product-env-api
+
+There is no need to create ''product environments'' explicitly via [TracAdmin
trac-admin] commands. Provided that the target product exists in the database,
they will be instantiated like shown in the following code snippet. The
instance of `trac.env.Environment` representing the global environment will be
accessed via `parent_env` attribute. The target product will be available in
`product` attribute.
+
+{{{
+#!py
+
+ env
+trac.env.Environment object at 0x7faacb1e9490
+ from multiproduct.env import ProductEnvironment
+ product_env = ProductEnvironment(env, product_prefix)
+ product_env.parent_env
+trac.env.Environment object at 0x7faacb1e9490
+ product_env.product
+multiproduct.model.Product object at 0x35566d0
+
+}}}
+
+Product environments will not be recursive , which means that the following
statement will fail
+
+{{{
+#!py
+
+ new_product_env = ProductEnvironment(product_env, product_prefix)
+Traceback (most recent call last):
+ File stdin, line 1, in module
+TypeError: Initializer must be called with
+trac.env.Environment instance as first argument
+(got multiproduct.env.ProductEnvironment instance instead)
+
+}}}
+
+Instantiating a component involved in multi-product architecture will always
return `None`, just like if it was disabled e.g.
+
+{{{
+#!py
+
+ ps = product.api.MultiProductSystem(product_env)
+ repr(ps)
+None
+}}}
+
+''Product environments'' will implement both `trac.core.ComponentManager` and
`trac.core.Component` APIs by inheriting most of the properties of the global
`trac.env.Environment`, so they will act as wrappers. As a consequence
instances will have its own components cache, which means that every active
component class will only have a single
[Apache Bloodhound] Proposals/BEP-0003 modified
Page Proposals/BEP-0003 was changed by olemis Diff URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diffversion=2 Revision 2 Comment: BEP-0003 : Mind map containing initial topics that need to be discussed about multi-product architecture ... more to be added soon ... Changes: ---8--8--8--8--8--8--8--8 Index: Proposals/BEP-0003 = --- Proposals/BEP-0003 (version: 1) +++ Proposals/BEP-0003 (version: 2) @@ -18,7 +18,9 @@ == Abstract #abstract -The evolution on the field of issue tracking systems leads to many request for supporting multiple products in a single environment. This document is meant to gather community consensus on the implementation of this feature . Besides it is a starting point to envision the impact on the underlying components architecture and the corresponding development strategies to get everything done. Ultimately it will explore compatibility considerations for existing plugins and suggest recommended upgrade paths so that hacks authors will take advantage of this feature . +[[Image(Multiproduct.png, width=600, align=right)]] + +The evolution on the field of issue tracking systems leads to many requests to support multiple products in a single environment. This document is meant to gather community consensus on the implementation of this feature . Besides it is a starting point to envision the impact on the underlying components architecture and the corresponding development strategies to get everything done. Ultimately it will explore compatibility considerations for existing plugins and suggest recommended upgrade paths so that hacks authors will take advantage of this feature . == Motivation == @@ -53,6 +55,8 @@ Source code management is powered by [http://subversion.apache.org/ Apache™ Subversion]. +The [attachment:Multiproduct.mm mind map] has been created with [http://www.mindjet.com/android Mindjet for Android] mobile client. On ''PC'' and ''Mac'' systems you can view its contents using [http://freemind.sourceforge.net/ FreeMind] desktop client. + == References #references 1. Multi-project support (trac:ticket:130) ---8--8--8--8--8--8--8--8 -- Page URL: https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003 Apache Bloodhound https://issues.apache.org/bloodhound/ The Apache Bloodhound (incubating) issue tracker This is an automated message. Someone added your email address to be notified of changes on 'Proposals/BEP-0003' page. If it was not you, please report to .
