[jbosstools-dev] Packaging JBoss Tools for Fedora (issue & potential patches)

[Mickael Istria]

Hi Gerard,

On 08/19/2012 07:10 PM, Gerard Ryan wrote
> The current version of the usage plugin differs slightly depending on 
> which version of Fedora, as it gets buit separately for each. Also, 
> I've just noticed that there it's built twice for each, once for i686 
> and once for x86_64 (I'm pretty should it should be done independently 
> of architecture, I'll have to look back and see why it's not). So here 
> are the versions for the current builds of the usage plugin:
> Fedora 17 i686: 1.1.0.v20120803-1433-Final
> Fedora 17 x86_64: 1.1.0.v20120803-1435-Final
> Fedora 18 i686: 1.1.0.v20120813-0307-Final Fedora 18 x86_64: 
> 1.1.0.v20120813-0301-Final
> Fedora 19 (Rawhide) i686: 1.1.0.v20120813-0304-Final
> Fedora 19 (Rawhide) x86_84: 1.1.0.v20120813-0259-Final
> If I change the BUILD_ALIAS variable to Fedora in build/parent/pom.xml 
> would that be better? 
In general, you should choose the BUILD_ALIAS clear enough to quickly 
understand whether a bundle comes from your build or ours. Something 
line v20120813-0301-Fedora would be good for that.

>>> This "rebuild" stuff also makes me wonder how Eclipse p2 is to be used with this version of Eclipse/JBoss Tools ?
>>>
>>> i.e. SOA Tools users would need to use Eclipse p2 - what happens in this case  where JBoss Tools bundles
>>> aren't the real JBoss Tools bundles ?
>>>
>>> It's still possible to install other bundles the usual way from the update sites. In this case, because it sees that the
>>> new bundles require different versions of the already installed bundles, it downloads them also.
>> No it doesn't - p2 works on version ranges so if your package falls within that it will use yours instead of the originals.
p2 is fine, but features are not: When you build a feature, the built 
feature.xml contains fully specified (including qualifier) version of 
bundles to install. So there may be some cases where version for what 
you built differs from the version we ship in feature.xml. That will 
lead to a conflict (in case bundle is a singleton) and may prevent from 
installing a new feature.
However, we made some effort on replacing "includes" by "requirements" 
on features wherever it makes sense. Version ranges work well for 
requirements. The rule is that a feature only includes bundles that are 
built in the same build, stuff coming from external sources (generally 
dependencies) must be "require". So Max's use case should work, but be 
aware we might have forgotten to apply this rule somewhere, and you 
might have some installation conflicts because of 2 features providing 
the same bundle with different qualifiers.

>>> When Eclipse is restarted
>>> and the new bundles are activated, the existing Fedora packaged versions of any stuff that duplicates were downloaded for
>>> always seems to 'win' - it's chosen over the newly downloaded version. This probably isn't what one would expect.
>> well, because the version is *higher* right?
> 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?
That's it, but more generally, it happens be qualifier is higher, not 
only date.

> 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?
Qualifier pattern for us is v<...>. If you want your build pattern to be 
lower, don't deal with dates. You can change simply qualifier to 
something like: f<...> or fedora-v<...>. Since 'f' < 'v' our bundles 
will be preferred by p2 and OSGi independently of the date on so on. I 
like the fedora-v<...> 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.

>>> Another aspect is what to do with our JBoss Central feature - which also relies on eclipse p2 to install additional features.
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.

Cheers,
-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets 
<http://twitter.com/mickaelistria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20120820/617d9c49/attachment.html