]
Denis Golovin commented on JBIDE-9007:
--------------------------------------
IMO, by default for local build i.e.
$cd jbosstools/trunk
$mvn clean install
it should build resolving internal components dependencies from local maven repo.
If something extra is required like resolving it from latest nightly trunk or latest
composite staging site there should be corresponding profiles for them to enable such
behavior.
Why composite update site for component builds
http://download.jboss.org/jbosstools/builds/staging/_composite_/3.3.indigo should not be
used by default for local builds
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBIDE-9007
URL:
https://issues.jboss.org/browse/JBIDE-9007
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: Build/Releng
Affects Versions: 3.3.0.M2
Reporter: Denis Golovin
Assignee: Nick Boldt
Priority: Blocker
Fix For: 3.3.0.M2
[1]
http://download.jboss.org/jbosstools/builds/staging/_composite_/3.3.indigo/
should not be used by default in local builds like
mvn clean install
[2] OSGI Java doc says about version.compareTo() method:
"A version is considered to be <b>less than </b> another version if its
major component is less than the other version's major component, or the
major components are equal and its minor component is less than the other
version's minor component, or the major and minor components are equal
and its micro component is less than the other version's micro component,
or the major, minor and micro components are equal and it's qualifier
component is less than the other version's qualifier component (using
<code>String.compareTo</code>"
It means for developers in concord, which has 3 hours difference with hudson host on east
coast, that sometimes component built locally considered as having older version and
component from composite repo [1] mentioned above picked up instead.
For example, I added new method "test()" in class from common.core plugin,
built it and then wrote test for this new method in test plugin. In my case, when I
compile my test, it fails with compilation error: "The method test() is undefined for
...". It happens because update site [1] contains common component built by hudson 12
minutes ago and its qualifier is "v20110525-1854-H267-M2". At the same time I
have my locally built component in my local maven repo with qualifier
"v20110525-1606-M2".
According [2] when major, minor and micro versions are equal all depends on qualifier
string comparation. Which basically means for my case
System.out.println("v20110525-1606-M2".compareTo("v20110525-1854-H267-M2"));
which returns -2 and that's why version from [1] is picked up instead one in my local
maven repo, which I just built.
At the same time it worked when I tried to verify that with cdi component on different
desktop. It worked, because last published build on [1] for cdi has qualifier
"v20110524-2226-H289-M2", which is less then my local one
"v20110525-1646-M2", because
System.out.println("v20110525-1646-M2".compareTo("v20110524-2226-H289-M2"));
returns 1.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: