[jbosstools-issues] [JBoss JIRA] Commented: (JBIDE-9007) 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

[Nick Boldt (JIRA)]

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

Nick Boldt commented on JBIDE-9007:
-----------------------------------

But what about the usecase where you want to build, say, just the AS component w/o first building the upstream stuff: tests, common, archives, jmx ?

In that case, you either need to:

a) build them locally
b) source from latest nightly trunk site
c) source from latest composite staging trunk site

Given what I've heard from QE about being able to install from the latest bits AND their locally-built bits, I'm not sure the best approach here to support both your usecase and theirs.

See also https://issues.jboss.org/browse/JBIDE-8974

> 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: http://www.atlassian.com/software/jira