<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 08/20/2012 12:39 PM, Max Rydahl
      Andersen wrote:<br>
    </div>
    <blockquote
      cite="mid:38CE12D3-6657-43A7-9199-1AFFA133DEF4@redhat.com"
      type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">Ah ok, I wasn't aware why that was happening. I guess it would be
'higher' because of the build date in the qualifier, right?

</pre>
        </blockquote>
        <pre wrap="">That's it, but more generally, it happens be qualifier is higher, not only date.
</pre>
      </blockquote>
      <pre wrap="">
yes, but for us it is the date; which is our fault and another reason why we should not have date be the significant decider.</pre>
    </blockquote>
    Having date in qualifier makes it very readable and user-friendly.
    It's quite useful.<br>
    <br>
    <br>
    <blockquote
      cite="mid:38CE12D3-6657-43A7-9199-1AFFA133DEF4@redhat.com"
      type="cite">
      <pre wrap="">I believe eclipse.org does this by doing releases like 3.2.0, 3.2.100, 3.2.200 ...giving room for 99 "custom" version builds.</pre>
    </blockquote>
    Only platform does that. I'm not aware of any other project using
    this versioning AFAIK.<br>
    <br>
    <blockquote
      cite="mid:38CE12D3-6657-43A7-9199-1AFFA133DEF4@redhat.com"
      type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">How about
if I force the date to be lower than the your build from the update
site? That way, if one downloads from the eclipse marketplace, or
somewhere else, then that would be used instead of the Fedora
installed version. Am I right in thinking that?

</pre>
        </blockquote>
        <pre wrap="">Qualifier pattern for us is v&lt;...&gt;. If you want your build pattern to be lower, don't deal with dates. You can change simply qualifier to something like: f&lt;...&gt; or fedora-v&lt;...&gt;. Since 'f' &lt; 'v' our bundles will be preferred by p2 and OSGi independently of the date on so on. I like the fedora-v&lt;...&gt; since it answers this issue and a previous one at the same time.
Be aware that you are dealing with conventions here. You should strongly document them and get other people working on them aware of them. It's easy to have someone changing this pattern for a "better" one without knowing such rules and then breaking it.
</pre>
      </blockquote>
      <pre wrap="">
This doesn't really solve it does it ? not unless all jboss.org updatesites are removed from p2 since when the user does Help &gt; Update it will bump everything.</pre>
    </blockquote>
    So we want to prevent updates of JBT plugins from inside Eclipse
    when installed with Fedora? I did not understand it that way.<br>
    IF we want to block install of JBT ww probably can't rely on p2 as
    it. p2 compares version, we can't prevent it to update from
    3.3.0.fedora-v2012 to 3.4.0.v2012... If we need to block this
    behavior, we'll probably need to hack p2 to prevent from any
    installation of org.jboss* IUs.<br>
    <br>
    <blockquote
      cite="mid:38CE12D3-6657-43A7-9199-1AFFA133DEF4@redhat.com"
      type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">Another aspect is what to do with our JBoss Central feature - which also relies on eclipse p2 to install additional features.
</pre>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap="">Did you change the JBoss Central feature to rely on yum instead of p2?
If yes, that's a different feature, and it modified bundles and features probably requires a new name.
If no, then it means there is nothing to worry about. It will be installed and will refer to our sites, and will work as always.
</pre>
      </blockquote>
      <pre wrap="">
No it won't if the bundles done in fedora doesn't have the same API (i.e. hibernatetools not bundling hibernate 3.5 for example)

It will *seem* to work, but funky sideeffects will eventually happen the more differences there are.
</pre>
    </blockquote>
    Yet another use-case I didn't have in mind. This Fedora integration
    is a real puzzle. Is there a document that sums up the installation
    scenario to be allowed/forbidden when using Fedora JBT package?<br>
    <div class="moz-signature">-- <br>
      Mickael Istria<br>
      Eclipse developer at <a href="http://www.jboss.org/tools">JBoss,
        by Red Hat</a><br>
      <a href="http://mickaelistria.wordpress.com">My blog</a> - <a
        href="http://twitter.com/mickaelistria">My Tweets</a></div>
  </body>
</html>