[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [babel-dev] Build process, p2 metadata
|
On 05/29/2009 04:54 AM, Denis Roy wrote:
Gabe O'Brien wrote:
I am also very interested in the steps to deploy the language packs as
I am starting to look into this very issue for the EPP team. Would it
be possible to develop a common deploy script (I know this is out side
of the scope of Babel)?
I'm not sure I understand 'deploy the language packs' .. You mean just
unzipping them in the dropins folder?
As I mentioned in the newsgroup, I've had the best results by unzipping
the plugins into dropins and throwing the features away. And the more I
think about it, the more I think it may be the only approach which can
work for Babel when it comes to dropins.
Babel has always had features which aggregated plugin fragments, but in
any given system, some of the fragments' hosts are not present. Of
course, it doesn't really matter if you have some extra, unneeded
translations. But you can't express this loose dependency with the
metadata inside features and plugins. Before P2/Ganymede, this just led
to error messages in the log, but with P2, the dependency checking
became stricter. Which led to bugs such as
https://bugs.eclipse.org/bugs/show_bug.cgi?id=256430
When using a P2 update site, you can modify the additional P2 metadata
to relax the dependencies and make them optional (as in the above bug).
This seems to work pretty well. But as far as I know, this option
can't be used with dropins, unless it is possible to put P2 metadata
into dropins.(?)
In any case, putting just the fragment plugins into dropins seems to
have the desired effect - Eclipse uses the fragments it can, and ignores
those it can't. The features aren't really needed; I think their main
benefit is to group plugins together in the Update Manager UI (or in the
command-line P2 installer).
I think it would make sense to remove all features from the zipped
langpacks. And maybe provide one more zip, which contains all the
features, and the metadata: site.xml, content.jar and artifacts.jar.
That way, anyone who wants to can construct a local update site.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
