3:10 a.m.
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>