[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] testing internationalization with pseudo translation pack
|
Thank you for this clarification.
I have set "site.retain.unpacked=true" in the Buckminster properties for my builds.
On Thu, May 5, 2011 at 8:34 AM, David M Williams
<david_williams@xxxxxxxxxx> wrote:
Yes, regular jars and packed jars should be both be kept for Indigo. While admittedly buried in the Release Requirements Document [1], the current statement is as follows:
Provide p2 repository. Projects must provide their own project p2 repository for their own project and updates. In addition, they must provide their archives and metadata in a specified format and method to allow at least parts of their repository to be aggregated and mirrored to a common repository. The current process may be modified throughout the year, if improvements can be made. Clarification on 03/31/2010: Note that a project's repositories must contain original (conditioned) jars, and pack.gz files (where original jar means the jar produced by the build, but which has been conditioned for pack200). [emphasis added] Clarification on 11/08/2010: feature "includes" must be strict, that is "include" an exact version of that other feature. This is required so installs and builds can be repeatable independent of the exact day of the install or the exact repos enabled. This is the way things are, and have been for years, and this statement is just making it explicit. While there may, in the future, be new mechanisms that allow some "line up collection" to be specified, it will be something new, not the feature "includes" element.
Thanks
[1] http://eclipse.org/indigo/planning/EclipseSimultaneousRelease.php
![Inactive hide details for Nicolas Bros ---05/05/2011 02:15:01 AM---Hi, The MoDisco build does nothing special to remove the unp]()
Nicolas Bros ---05/05/2011 02:15:01 AM---Hi, The MoDisco build does nothing special to remove the unpacked jars. But
Date: 05/05/2011 02:15 AM
Subject: Re: [cross-project-issues-dev] testing internationalization with pseudo translation pack
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
Hi,
The MoDisco build does nothing special to remove the unpacked jars. But MoDisco is built with Buckminster, which doesn't retain unpacked jars by default.
See :
Bug 304958 - Exclude original jar files when using pack200
http://www.eclipse.org/forums/index.php?t=rview&goto=519253&th=164010
Packed jars are actually a requirement for the simultaneous release.
And I thought the consensus was that unpacked jars shouldn't be kept, in order to avoid doubling disk space requirements for mirrors.
But then I found:
Bug 307804 - Reconsider removing jars from Helios common repository
So, can you confirm that unpacked jars should be kept for Indigo?
On Thu, May 5, 2011 at 1:54 AM, David M Williams <david_williams@xxxxxxxxxx> wrote:
Technically speaking, projects are supposed to contribute both the *.jar form, and the *.jar.pack.gz form. But, some do try and be creative and get rid of the *.jar form, since they are basically equivalent (when produced correctly) ... so, offhand, I'd guess Modisco is just one of those creative projects that is trying to buck the system. (But ... not sure, I'm sure Modisco team will say if there's a mistake, or you need to look elsewhere.)
In other words, it wouldn't hurt if Babel could handle the case where pack.gz files existed but not the corresponding .jar file ... but best if Modisco and others contributed both forms in their repos, IMHO.
To create a jar file from a pack.gz file is pretty easy ... basically calling something like
$JAVA_HOME/jre/bin/unpack200 "${basicname}".jar.pack.gz "${basicname}".jar
It's conceptually like a super zip, and corresponding super unzip, but ends up with just the zipped jar ... and you need to tell it what to name the resulting jar. To read more about Pack200, see http://wiki.eclipse.org/Pack200 and the references at the end of that article.
The hard part would be to (automatically) figure out when you need to do it, and when not. (That is, if not obvious, I'd be pretty inefficient use of resources, just to blindly always do it for every *.jar.pack.gz file, even if the jar file already existed).
HTH
![Inactive hide details for Kit Lo---05/04/2011 06:00:48 PM---I investigated and found that the source plugins from Modisco's upd]()
Kit Lo---05/04/2011 06:00:48 PM---I investigated and found that the source plugins from Modisco's update site were normally jar'd and
From: Kit Lo/Raleigh/IBM@IBMUS
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date: 05/04/2011 06:00 PM
Subject: Re: [cross-project-issues-dev] testing internationalization with pseudo translation pack
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
I investigated and found that the source plugins from Modisco's update site were normally jar'd and Babel recognized them and generated pseudo translation language packs for them.
However, Modisco's binary plugins were jar'd as *.jar.pack.gz. Babel didn't recognized them and didn't generated pseudo translation language packs for them.
Anyone knows if the *.jar.pack.gz jars are normal and supported?
Kit Lo
IBM Eclipse SDK Globalization Technical Lead
Eclipse Babel Project Lead
![Inactive hide details for fgiquel---05/04/2011 06:08:36 AM---Hi Kit, thanks for these Babel Pseudo Translations Packs.]()
fgiquel---05/04/2011 06:08:36 AM---Hi Kit, thanks for these Babel Pseudo Translations Packs.
Hi Kit,
thanks for these Babel Pseudo Translations Packs.
I am trying to test the mdt.modisco pack.
I am not familiar with Babel translation packs. Is is normal that this pack contains fragments for source plugins and not for binary plugins (e.g. there is one fragment "org.eclipse.gmt.modisco.infra.browser.uicore.source.nl_en_AA" but there is no fragment "org.eclipse.gmt.modisco.infra.browser.uicore.nl_en_AA") ?
Fabien Giquel.
Babel Pseudo Translations for those projects who have defined their map files or update sites for Indigo in Babel are now available at:
http://build.eclipse.org/technology/babel/babel_language_packs/I20110503-0400/indigo.php#en_AA
Regards,
Kit Lo
IBM Eclipse SDK Globalization Technical Lead
Eclipse Babel Project Lead
![Inactive hide details for Nicolas Bros ---05/03/2011 02:08:06 AM---Ok thanks. I was looking for pseudo translation language pac]()
Nicolas Bros ---05/03/2011 02:08:06 AM---Ok thanks. I was looking for pseudo translation language packs for both EMF Facet (modeling.emft.emf
Ok thanks. I was looking for pseudo translation language packs for both EMF Facet (modeling.emft.emf-facet) and MoDisco (modeling.mdt.modisco).
2011/5/3 Kit Lo <kitlo@xxxxxxxxxx>
I'm working on setting up the Babel builds for Indigo now. Once I confirmed that we have a good build, I will reply to this mailing list.
Nicolas, may I ask the name of your project so that I can make sure the pseudo translation language packs are ready?
Regards,
Kit Lo
IBM Eclipse SDK Globalization Technical Lead
Eclipse Babel Project Lead
![Inactive hide details for Nicolas Bros ---2011/05/02 上午 04:28:10---Hi, One item in the checklist for the simultaneous relea]()
Nicolas Bros ---2011/05/02 上午 04:28:10---Hi, One item in the checklist for the simultaneous release (on the portal), is :
Hi,
One item in the checklist for the simultaneous release (on the portal), is :
The project should use the Babel Pseudo Translation Test to verify their translatability.
From the information I could gather, that means downloading a pseudo translation pack from Babel, and checking every view, dialog, etc. to see if the strings are still in English, or are replaced by a pseudo-translation code.
So, we filled in the information on babel.eclipse.org to register our projects, and waited for Babel to produce the translation packs.
But looking in:
http://build.eclipse.org/technology/babel/babel_language_packs/
I can only see translation packs for Helios.
How are we supposed to check translatability of Indigo projects?
--
Nicolas Bros
R&D
tel: 06 75 09 19 88
nbros@xxxxxxxxxxxxxxxx
nbros.mia@xxxxxxxxx
Mia-Software, 410 clos de la Courtine
93160 Noisy-le-Grand
http://www.mia-software.com
.: model driven agility :.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Nicolas Bros
R&D
tel: 06 75 09 19 88
nbros@xxxxxxxxxxxxxxxx
nbros.mia@xxxxxxxxx
Mia-Software, 410 clos de la Courtine
93160 Noisy-le-Grand
http://www.mia-software.com
.: model driven agility :._______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Nicolas Bros
R&D
tel: 06 75 09 19 88
nbros@xxxxxxxxxxxxxxxx
nbros.mia@xxxxxxxxx
Mia-Software, 410 clos de la Courtine
93160 Noisy-le-Grand
http://www.mia-software.com
.: model driven agility :.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Nicolas Bros
R&D
tel: 06 75 09 19 88
nbros@xxxxxxxxxxxxxxxxnbros.mia@xxxxxxxxx
Mia-Software, 410 clos de la Courtine
93160 Noisy-le-Grand
http://www.mia-software.com.: model driven agility :.
