[
https://issues.jboss.org/browse/JBIDE-18820?page=com.atlassian.jira.plugi...
]
Mickael Istria commented on JBIDE-18820:
----------------------------------------
A) they use the APIs, not directly the values in ide-config.properties. APIs would remain
in Foundation, not the configuration itself. The configuration is only necessary at
test/run time. For tests, we could use a Mock. For runtime, then it would mean that anyone
installing a component which requires properties would need to also install a
propertyProvider (aka branding plugin), that might be an optional dependency on the
feature.
We could also think about leveraging more abstract dependency definition, as permitted by
OSGi, and use Provide/Require-Capability. The Foundation bundles would require the
necessary capability, and mock, JBoss Tools and JBDS providers here would provide it, so
p2 would get one according to what's available.
define how to handle ide.properties and avoid parent pom to always
change
-------------------------------------------------------------------------
Key: JBIDE-18820
URL:
https://issues.jboss.org/browse/JBIDE-18820
Project: Tools (JBoss Tools)
Issue Type: Task
Components: build
Reporter: Max Rydahl Andersen
As illustrated in JBIDE-18806 our current setup of how ide.properties and project
versioning are not working or at least we seem to not get it updated right.
Current workaround applied is that parent pom now again defines the global version even
though this is not reliable at all since not all plugins will be rebuilt. (see JBIDE-13452
for earlier attempts on this)
Opening this jira to make sure we walkthrough and write down which values should be in
ide.properties and what level (4.2.0.CR1, 4.2.0 or 4.2. etc), when they get updated
(hopefully rarely) and how to avoid parent pom from always having to respin because of a
maintanence release.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)