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,