- Konstantin
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
