[jbosstools-issues] [JBoss JIRA] (JBIDE-18837) because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated

[Nick Boldt (JIRA)]

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

Nick Boldt edited comment on JBIDE-18837 at 11/28/14 12:44 AM:
---------------------------------------------------------------

Net result is that during dev phase, we cannot link QE to a different version of Central/Examples/EA than the released version, because users will see their JBT 4.2.1.CR1, 4.2.1.Final, 4.2.2.\*, 4,2.3.\* as all being the same version: 4.2. Therefore when we introduce changes to Central (for example, the upcoming change to m2e-apt 1.1.1) we'll have no way to feed a JBT 4.2.1.CR1a user to a different URL for Central than the one that's live for 4.2.x users. (Actually, we'll be able to go back to using -D flags, which ya'll loved so much.)

Without the ability to cause JBT to look for different versions of Central, we have no need to have three different URLs for JBT 4.2.1.CR1a/CR2/Final [1], 4.2.1.CR1 [2], or 4.2.0.Final [3].

[1] jboss.discovery.site.url|jbosstools|4.2.1=http://download.jboss.org/jbosstools/discovery/nightly/core/4.2.luna/
[2] jboss.discovery.site.url|jbosstools|4.2.1.CR1=http://download.jboss.org/jbosstools/updates/staging/luna
[3] jboss.discovery.site.url|jbosstools|4.2.0.Final=http://download.jboss.org/jbosstools/updates/stable/luna/

Because, if all three think they're simply 4.2.0.Final, then they'll all fall back to [3].


was (Author: nickboldt):
Net result is that during dev phase, we cannot link QE to a different version of Central/Examples/EA than the released version, because users will see their JBT 4.2.1.CR1, 4.2.1.Final, 4.2.2.*, 4,2.3.* as all being the same version: 4.2. Therefore when we introduce changes to Central (for example, the upcoming change to m2e-apt 1.1.1) we'll have no way to feed a JBT 4.2.1.CR1a user to a different URL for Central than the one that's live for 4.2.x users. (Actually, we'll be able to go back to using -D flags, which ya'll loved so much.)

Without the ability to cause JBT to look for different versions of Central, we have no need to have three different URLs for JBT 4.2.1.CR1a/CR2/Final [1], 4.2.1.CR1 [2], or 4.2.0.Final [3].

[1] jboss.discovery.site.url|jbosstools|4.2.1=http://download.jboss.org/jbosstools/discovery/nightly/core/4.2.luna/
[2] jboss.discovery.site.url|jbosstools|4.2.1.CR1=http://download.jboss.org/jbosstools/updates/staging/luna
[3] jboss.discovery.site.url|jbosstools|4.2.0.Final=http://download.jboss.org/jbosstools/updates/stable/luna/

Because, if all three think they're simply 4.2.0.Final, then they'll all fall back to [3].

> because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBIDE-18837
>                 URL: https://issues.jboss.org/browse/JBIDE-18837
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: build, central, common/jst/core, project-examples
>    Affects Versions: 4.2.1.CR1
>            Reporter: Nick Boldt
>             Fix For: 4.3.0.Alpha1
>
>
> When updating from 4.2.0 to 4.2.1, a user might decide to only update Central or Project Examples, and NOT update Foundation.core, which means his Eclipse will still think it's 4.2.0, not 4.2.1, and he might get the wrong version of central/examples.
> Therefore we need manifest-level [4.2.1,) requirements on upstream foundation.core in examples and central, to force this lock-step updating.
> And we need to use the maven enforcer plugin to fail the build if these versions get out of sync.



--
This message was sent by Atlassian JIRA
(v6.3.8#6338)