[
https://issues.jboss.org/browse/JBIDE-18837?page=com.atlassian.jira.plugi...
]
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/jboss...
[2]
jboss.discovery.site.url|jbosstools|4.2.1.CR1=http://download.jboss.org/j...
[3]
jboss.discovery.site.url|jbosstools|4.2.0.Final=http://download.jboss.org...
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/jboss...
[2]
jboss.discovery.site.url|jbosstools|4.2.1.CR1=http://download.jboss.org/j...
[3]
jboss.discovery.site.url|jbosstools|4.2.0.Final=http://download.jboss.org...
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)