[
https://issues.jboss.org/browse/JBIDE-18837?page=com.atlassian.jira.plugi...
]
Max Rydahl Andersen edited comment on JBIDE-18837 at 12/1/14 6:00 AM:
----------------------------------------------------------------------
[~nickboldt] we have been linking our test builds to different version of
central/examples/EA through most if not all of our majority test phase thus that comment
is just factually false.
The only time this could actually happen is if a user/QE/dev *Explicitly* goes and install
a *subpart* of jbosstools and go out of his ways to make sure he does not have the latest
update to foundation.
JBT already looks for specific versions. There is no need to introduce -D flags.
It should be sufficient to just have:
jboss.discovery.site.url|jbosstools|4.2=http://download.jboss.org/jbossto...
jboss.discovery.site.url|jbosstools|4.2.1.CR1=http://download.jboss.org/j...
or if you want nightlies to pick up latest development no matter what:
jboss.discovery.site.url|jbosstools|4.2=http://download.jboss.org/jbossto...
jboss.discovery.site.url|jbosstools|4.2.0=http://download.jboss.org/jboss...
This is what we did until now - why is that not considered possible anymore ?
The above stuff of course assumes we actually bump the version correctly but that is what
we found we missed - that is now fixed. None of that requires *forceful* linking from
parent pom to foundation down to the micro level.
was (Author: maxandersen):
[~nickboldt] we have been linking our test builds to different version of
central/examples/EA through most if not all of our majority test phase thus that comment
is just factually false.
The only time this could actually happen is if a user/QE/dev *Explicitly* goes and install
a *subpart* of jbosstools and go out of his ways to make sure he does not have the latest
update to foundation.
JBT already looks for specific versions. There is no need to introduce -D flags.
It should be sufficient to just have:
jboss.discovery.site.url|jbosstools|4.2=http://download.jboss.org/jbossto...
jboss.discovery.site.url|jbosstools|4.2.1.CR1=http://download.jboss.org/j...
or if you want nightlies to pick up latest development no matter what:
jboss.discovery.site.url|jbosstools|4.2=http://download.jboss.org/jbossto...
jboss.discovery.site.url|jbosstools|4.2.0=http://download.jboss.org/jboss...
This is what we did until now - why is that now considered possible anymore ?
The above stuff of course assumes we actually bump the version correctly but that is what
we found we missed - that is now fixed. None of that requires *forceful* linking from
parent pom to foundation down to the micro level.
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)