Andrew Marinchuk created DELTASPIKE-1417:
--------------------------------------------
Summary: ProjectStage inheritance
Key: DELTASPIKE-1417
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1417
Project: DeltaSpike
Issue Type: Wish
Security Level: public (Regular issues)
Components: Core
Reporter: Andrew Marinchuk
Currently ProjectStage is single typesafe param which allow to divide single
configuration (including bean visibility) to several configurations. But each
configuration should be described separately. For each configuration property
we have to choose from two options:
* use the same value for all project stages
* put the separate configuration line for each project stage with non-default
value (the value could be specified single time thanks to ability to refer
another line, but)
Moreover, when there is a need to use projectstage in the {{@Exclude}}
annotation, adding the new projectstage leads to potential modifications of all
classes annotated with {{@Exclude}}.
Default project stages are bandled with marker interface
org.apache.deltaspike.core.api.projectstage.TestStage attached to the testing
projectstages, but it's not used anywhere. The idea is to use marker interfaces
to define additional "virtual" projectstages. Such interfaces have not used as
org.apache.deltaspike.ProjectStage value, but it could be used in configuration
or with {{@Exclude}} annotations, i.e.:
{code}#dev stage server
db.server.hostname.Development=dev-host.dom
#server for all test stages
db.server.hostname.TestStage=test-host.dom
#server for integration tests - projectstage name has priority, so it overrides
value for TestStage
db.server.hostname.IntegrationTest=itg-test-host.dom{code}
This feature is very usable for custom projectstages because enough additional
interfaces could be provided.
The only problem is conflicting settings. For example, if we have two marker
interfaces attached to the same projectstage, but some config property has two
different marker-aware values and no projectstage-aware value provided. This
situation is definitely a configuration bug, so the only valid option is to
throw exception on such situation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
