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
|
