[jbosstools-issues] [JBoss JIRA] (JBIDE-18820) define how to handle ide.properties and avoid parent pom to always change

[Nick Boldt (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-18820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023701#comment-13023701 ] 

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)