[
https://issues.jboss.org/browse/JBIDE-18820?page=com.atlassian.jira.plugi...
]
Nick Boldt commented on JBIDE-18820:
------------------------------------
What's wrong with having the version of the parent pom == the version of JBoss Tools
recorded in the Base project's Foundation subproject's foundation.core plugin?
* for every milestone/maintenance release of JBT, we need to rebuild Base so it stores the
correct version in jbosstools.version in the org.jboss.tools.foundation.core plugin (even
if NOTHING HAS CHANGED)
* similarly, for every milestone/maintenance release of JBDS, we need to rebuild
jbdevstudio-product so it stores the correct version in devstudio.version in the
com.jboss.devstudio.core.central plugin
* for every change to the parent pom / target platform, projects need to update their root
pom to pull the latest parent pom, in order to get the correct value of BUILD_ALIAS and
ensure they build against the latest target platforms.
Benefits to the solution Fred and I worked out yesterday:
a) no need to change properties by hand; they're inherited from pom versions we
maintain already
b) no need to upversion anything under jbosstools-base/foundation or in
jbosstools-base/foundation/plugins/org.jboss.tools.foundation.core each time we do a
maintenance or milestone release
c) projects simply need to keep grabbing the latest parent pom, which they have to
already: no new process overhead, nothing new to be forgotten.
Single potential side effect:
a) If we decide to release maintenance milestones (eg., a 4.2.1.CR1) - which today we *DO
NOT DO* - then we would need to ensure that the version of org.jboss.tools.foundation.core
is osgi-syntactically larger, because respinning o.j.t.foundation.core 1.1.0.Final with a
newer timestamp is OK if the BUILD_ALIAS is Final in both cases, but NOT OK if we move
from 1.1.0.Final [old timestamp] to 1.1.0.CR1 [newer timestamp]. In that unlikely
scenario, the simple solution is to ensure that o.j.t.foundation.core is moved to version
1.1.1.
---
What this solution does NOT address is how we enforce that an update to any part of JBT
will pull in an updated version of o.j.t.foundation.core, even if a user only chooses to
update a part of the toolset. Therefore Central and Examples need to depend on an explicit
MINIMUM version of o.j.t.foundation.core. See JBIDE-18837 for that issue.
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)