Or maybe the projects should provide just the jar files and the job of optimizing the repository should be part of the process of assembling the big repository. That keeps things simple and doesn’t require all projects to do this consistently to have a consistent repository.
- Konstantin
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Thomas Hallgren
Sent: Friday, May 06, 2011 2:36 PM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: Re: [cross-project-issues-dev] testing internationalization with pseudo translation pack
I think a relevant question to ask here is *why* should project provide both the .jar.pack.gz and the .jar ? I can only see one reason and that is that the .jar is needed in case there's something wrong with the .jar.pack.gz. Are there other reasons?
If that is the only reason (or even if it is the major reason), then I think the requirement should be turned in side out and instead say that all projects are required to *only* provide the .jar.pack.gz so that any mistakes can be detected and fixed early. Having bad files out there that p2 silently ignores (after a complete download and unpack) doesn't benefit anyone.
Assuming that a consumer uses the p2 API to access a p2 repository, the lack or presence of the .jar should be completely invisible. If Babel isn't using this API and instead attempts to access individual files in the repository, then this should definitely change since it's very likely to lead to other problems further on. A p2 repository should be accessed using the p2 API, not in other ways. The current requirement for maintaining both files becomes obsolete if that simple rule is honored.
Just my 2c.
Thomas Hallgren
On 2011-05-05 01:54, David M Williams 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
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
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
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
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