On 17/03/14 06:27, Wang, Shiliu wrote:
Max, Thanks for your comments.
Agree with you on using the same archiving tools for all archives.
OK, great :)
For your second comment, it's more about the inner structure of
xwalk_app_template, right?
Yes, I think so, though the principle it true of many things, I suppose.
I'm not familiar with apk-generator, will it be eventually part of crosswalk
release?
I hope so, but I'm not privy to the thinking of the decision makers :)
It is part of crosswalk in some sense already, as is grunt-crosswalk -
at least it is implied because it is part of the github 'organisation' :
<https://github.com/crosswalk-project/crosswalk-apk-generator>
<https://github.com/crosswalk-project/grunt-crosswalk>
I understand there has been some interest voiced at recent conferences
for these tools, so perhaps it will be made more obvious.
It is true that it has been developed independently, by Elliot and
myself, since we have been convinced that people other than just us
would want it and we have had trouble convinced others :)
Or it's an independent tool which automatically upgrade the xwalk archive it
will be using? If it's the second case, I think it's necessary to think about
if there need some protocol between xwalk output and apk-generator.
No, I don't think that describes its purpose (though there is a download
tool included). The tools are basically node/javascript alternatives to
the make_apk.py python-based tool and integrate much more seamlessly
with the node and grunt development environments oft used by html5
application developers (ourselves included). We haven't attempted to
match the functionality as such, but rather add features that we see as
necessary.
In any case, I suspect crosswalk-apk-generator will be just one such
tool that depends on the crosswalk application template download and so
the problem I describe could be mitigated by having a single file
describing where the important bits are (in json, of course ;)). I
suppose it is possible that the make_apk.py (and the other python
scripts) could also make use of such a file(?).
However, at the end of the day, it's not a huge deal for us since our
development cycle is quite light-weight and quick, and
crosswalk-apk-generator has a test suite to give confidence when making
changes; it'd just make things easier, that's all :)
Max.
Thanks,
Shiliu.
From: Crosswalk-dev [mailto:crosswalk-dev-boun...@lists.crosswalk-project.org]
On Behalf Of Balestrieri, Francesco
Sent: Friday, March 14, 2014 6:45 PM
To: Waterman, Max; crosswalk-dev@lists.crosswalk-project.org
Subject: Re: [Crosswalk-dev] Proposal on how to organize our download binaries
for public users
? I question the use of multiple archiving tools - ie why some things are
.tar.gz and some are .zip?
Agree with Max, it seems odd.
From: Crosswalk-dev [mailto:crosswalk-dev-boun...@lists.crosswalk-project.org]
On Behalf Of Max Waterman
Sent: Friday, March 14, 2014 12:03 PM
To:
crosswalk-dev@lists.crosswalk-project.org<mailto:crosswalk-dev@lists.crosswalk-project.org>
Subject: Re: [Crosswalk-dev] Proposal on how to organize our download binaries
for public users
A couple of thoughts :
1) I question the use of multiple archiving tools - ie why some things are
.tar.gz and some are .zip? IMO, it would be better to use just a single tool
for this so that only one is required on users' systems and only one is needed
for tools that automatically download/unpack the archive. In my experience (not
crosswalk specifically), zip has caused many different problems. I'm not sure
why, but I suppose because it has so many different options/compression
methods. Perhaps it's possible to only use the basic compression methods or
some other way of ensuring the downloads are compatible with old zip
libs/utilities.
2) We (crosswalk-apk-generator) were recently 'hit' by a change in name of one
of the components that are included in the template download. In this case, it
was simple to fix, but I wonder if there might be a better way - Elliot
suggested that each download contains a file (manifest.json?) that lists the
paths to each component that are needed so that they can be changed/moved and
tools can continue to work. Perhaps such a thing could be considered.
I suppose I might have not fully understood Elliot's suggestion, but I like
that things would work without changes or with minimal changes, and that tools
don't require intimate knowledge of the internal structure of the archive,
instead just looking for a single file in the root.
Thanks,
Max.
On 14/03/14 05:49, Yu, Zhiqiang wrote:
The only nitpick I have is about the "xwalk_app_template" name, it's too
"implementation dependent"...
Agree w/ Francesco.. :)
Thanks,
Zhiqiang
" Simplicity is Beauty..."
From: Balestrieri, Francesco
Sent: Friday, March 14, 2014 1:47 PM
To: Wang, Shiliu; Kubo Da Costa, Raphael; Hu, Ningxin; Zhu, Yongsheng
Cc: Yu, Zhiqiang;
Crosswalk-dev@lists.crosswalk-project.org<mailto:Crosswalk-dev@lists.crosswalk-project.org>
Subject: RE: Proposal on how to organize our download binaries for public users
Shiliu: Totally agree with you. With the new structure.
If a developer wants to directly develop based on Crosswalk, he needs to
1. Download xwalk_app_template.tar.gz directly.
2. Unzip the tarball
3. Cd xwalk_app_template
4. Create manifest if he wants to.
5. Run make_apk.py according to wiki
6. Publish the generated apk.
Thanks. The only nitpick I have is about the "xwalk_app_template" name, it's too
"implementation dependent". If this is the only package a developer needs to create
Crosswalk apps, it should just be named Crosswalk (or crosswalk-tool or something
self-explanatory like that. But just "crosswalk" would be best).
Francesco
From: Wang, Shiliu
Sent: Friday, March 14, 2014 7:37 AM
To: Balestrieri, Francesco; Kubo Da Costa, Raphael; Hu, Ningxin; Zhu, Yongsheng
Cc: Yu, Zhiqiang;
Crosswalk-dev@lists.crosswalk-project.org<mailto:Crosswalk-dev@lists.crosswalk-project.org>
Subject: RE: Proposal on how to organize our download binaries for public users
Hi, Francesco
Thanks for the comments. See my answer below.
- somewhere else we are discussing the need for a single tool/package
for both ARM and IA. So eventually would the ARM and x86 folders merge into one?
Shiliu: For xwalk_app_template, yes. But for cordova.tar.gz and other apks,
arm and x86 will still be separated.
- I didn't understand the purpose of "Canary1", "Canary2" etc
Shiliu: "Canary1" and "Canary2" are just short for different versions. I was
just using 1,2,3 to replace real version number like 5.34.99.0. Sorry for the confusing.
- In my opinion we should bake Cordova support in the main crosswalk
archive as well
Shiliu: yes, that's cordova.tar.gz. for. You might take the first two colored
structures as my proposal, they are the current status. My proposal is the last
one. I should use some different color, sorry for the misleading.
Android/
Canary/
Canary1/
Xwalk_app_tempalte.tar.gz
X86/
Cordova.tar.gz
Xwalk.zip (including runtimelib and helloworld)
Xwalk_tests.zip (including tests apk and shell
apk)
arm/
Cordova.tar.gz
Xwalk.zip (including runtimelib and helloworld)
Xwalk_tests.zip (including tests apk and shell
apk)
Canary2/
Similar to canary1
Beta/
Similar to Canary
What I think we should aim for is that a developer who wants to use Crosswalk
needs to follow something like these steps:
- download and unzip package
- if needed, give one install command
- cd to their web or Cordova app
- if needed, create a manifest
- run package script
- Publish to app store
Shiliu: Totally agree with you. With the new structure.
If a developer wants to directly develop based on Crosswalk, he needs to
1. Download xwalk_app_template.tar.gz directly.
2. Unzip the tarball
3. Cd xwalk_app_template
4. Create manifest if he wants to.
5. Run make_apk.py according to wiki
6. Publish the generated apk.
Exactly like what you suggest. :)
If he wants to adopt cordova container, steps are probably the same, just he
needs to download different package for arm/x86.
The main idea is to host each tool separately instead of merge them in a super
large zip. The pros is to have less download size for end user and less steps
to extract the super zip.
Thanks,
Shiliu.
From: Balestrieri, Francesco
Sent: Friday, March 14, 2014 1:09 PM
To: Wang, Shiliu; Kubo Da Costa, Raphael; Hu, Ningxin; Zhu, Yongsheng
Cc: Yu, Zhiqiang;
Crosswalk-dev@lists.crosswalk-project.org<mailto:Crosswalk-dev@lists.crosswalk-project.org>
Subject: RE: Proposal on how to organize our download binaries for public users
Hi,
a few comments:
- somewhere else we are discussing the need for a single tool/package
for both ARM and IA. So eventually would the ARM and x86 folders merge into one?
- I didn't understand the purpose of "Canary1", "Canary2" etc
- In my opinion we should bake Cordova support in the main crosswalk
archive as well
What I think we should aim for is that a developer who wants to use Crosswalk
needs to follow something like these steps:
- download and unzip package
- if needed, give one install command
- cd to their web or Cordova app
- if needed, create a manifest
- run package script
- Publish to app store
From: Wang, Shiliu
Sent: Friday, March 14, 2014 4:45 AM
To: Balestrieri, Francesco; Kubo Da Costa, Raphael; Hu, Ningxin; Zhu, Yongsheng
Cc: Yu, Zhiqiang;
Crosswalk-dev@lists.crosswalk-project.org<mailto:Crosswalk-dev@lists.crosswalk-project.org>
Subject: Proposal on how to organize our download binaries for public users
Hi, All
Per https://crosswalk-project.org/jira/browse/XWALK-898 ,
https://crosswalk-project.org/jira/browse/XWALK-1013,
https://crosswalk-project.org/jira/browse/XWALK-670 .
They are all about the requirement for the binaries we deliver to public.
Currently our binaries are organized like
Android_arm/
Canary/
Canary1.zip
Canary2.zip
Beta/
Beta1.zip
Android_x86/
Canary/
Canary1.zip
Beta/
Beta1.zip
And within the zip it will be:
Crosswalk-version-arch.zip/
Apks/
Bunch of apks.
Xwalk_app_template.tar.gz
Xwalk_core_library.tar.gz
From the Jira issues, the requirement is to:
1. Provide cordova.tar.gz for download, which is basically
crosswalk_cordova_android code + xwalk_core_library.tar.gz .
2. Provide one xwalk_app_template.tar.gz for both x86 and arm.
Based on following facts:
1. Xwalk_app_template.tar.gz is enough for web developer to use xwalk.
2. Cordova.tar.gz is also functional independent itself.
I propose to organize our release to public following way
Android/
Canary/
Canary1/
Xwalk_app_tempalte.tar.gz
X86/
Cordova.tar.gz
Xwalk.zip (including runtimelib and helloworld)
Xwalk_debug.zip (including tests apk and shell
apk)
arm/
Cordova.tar.gz
Xwalk.zip (including runtimelib and helloworld)
Xwalk_debug.zip (including tests apk and shell
apk)
Canary2/
Similar to canary1
Beta/
Similar to Canary
The gaps from current status will be
1. Generate cordova.tar.gz
2. Generate one xwalk_app_template.tar.gz including both archs native
libraries.
3. Reorganize the folder structure.
Thanks,
Shiliu.
_______________________________________________
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org<mailto:Crosswalk-dev@lists.crosswalk-project.org>
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
