[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=12604500#comment-12604500 ] 

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

So are you suggesting that parent pom should have this instead of being set to true?

                <!-- Latest JBT work-in-progress component builds (CI builds), not yet pushed to the above nightly update site -->
                <profile>
                        <id>jbosstools-nightly-staging-composite</id>
                        <activation>
                                <activeByDefault>{color:red}false{color}</activeByDefault>
                        </activation>
                        <repositories>
                                <repository>
                                        <id>jbosstools-nightly-staging-composite</id>
                                        <url>${jbosstools-nightly-staging-composite}</url>
                                        <layout>p2</layout>
                                        <snapshots>
                                                <enabled>true</enabled>
                                        </snapshots>
                                        <releases>
                                                <enabled>true</enabled>
                                        </releases>
                                </repository>
                        </repositories>
                </profile>


> 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