Bug 822344 - comment in the end resulting in maven failing to push po/pot file to server
comment in the end resulting in maven failing to push po/pot file to server
Status: CLOSED CURRENTRELEASE
Product: Zanata
Classification: Community
Component: Component-Maven (Show other bugs)
1.6-SNAPSHOT
Unspecified Unspecified
low Severity medium
: ---
: 1.6.1
Assigned To: Carlos Munoz
Ding-Yi Chen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-17 02:29 EDT by Joyce Chang
Modified: 2013-03-03 22:19 EST (History)
4 users (show)

See Also:
Fixed In Version: 1.7-SNAPSHOT (20120626-0025)
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-03 01:27:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joyce Chang 2012-05-17 02:29:01 EDT
Description of problem:
A comment on the bottom of entry in the po file will result in failing to push po to server.Both python and maven client have this issue. Po files should be able to be pushed to server regardless wherever comments go


Version-Release number of selected component (if applicable):
1.6.0-alpha-3-SNAPSHOT

How reproducible:
always

Steps to Reproduce:

1.put a comment in the end of a entry in a po file 

ex:
  msgid " source text"
  msgstr " translation text "
  # a comment in the end resulting in failure to push po 

2. push this po file using mvn zanata:push -Dzanata.pushTrans

  
Actual results:
po being pushed to server 

Expected results:
[ERROR] Failed to execute goal org.zanata:zanata-maven-plugin:1.6.0-alpha-3-SNAPSHOT:push (default-cli) on project null: Zanata mojo exception: unexpected token: <eof> -> [Help 1]
Comment 1 Joyce Chang 2012-05-17 02:32:43 EDT
additional info.
same issue happens when pushing pot
Comment 2 Joyce Chang 2012-05-17 02:44:12 EDT
Actually, pot is still able to be pushed to server, with a comment in the end of an entry. sorry~~
Comment 3 Runa Bhattacharjee 2012-05-17 02:53:42 EDT
Some .po files contain obsolete entries (often due to a merge with an updated .pot or .po) as comments towards the end of the file, for instance http://l10n.gnome.org/POT/gdm.master/gdm.master.bn_IN.po .
Comment 4 Joyce Chang 2012-05-17 20:33:03 EDT
(In reply to comment #2)

i managed to reproduce the bug precisely, i realized whether po or pot, a comment in the end of the file will result in failing to be pushed to server like what Runa said.So, it did happened to pot as well, when pushing it, with a comment in the end
Comment 5 Carlos Munoz 2012-06-05 00:36:07 EDT
Changed the tennera dependency to use the latest PO parser (0.7-SNAPSHOT) which does a couple of new things:
1. Does not fail when comments are present at the end.
2. Does not fail when encountering lines of the form: #~| msgid "Message Id"

Unit tested against the file linked in Comment 3

See (Tennera):
https://github.com/zanata/tennera/commit/a8b28d12c8d9e1b47ecba0169052fa3a3fd207c8
Comment 6 Ding-Yi Chen 2012-06-27 00:36:50 EDT
VERIFIED with 
Zanata version 1.7-SNAPSHOT (20120626-0025) and 
Zanata version 1.6.1-SNAPSHOT (20120626-0001).
Comment 7 Sean Flanigan 2012-06-27 00:51:29 EDT
Are those client versions or server versions?
Comment 8 Ding-Yi Chen 2012-06-27 03:10:01 EDT
Server version. Is there any convenient way to tell exactly the client version, including the build number? What I currently get is something like:
client API version is 1.6.0-alpha-2
which is not always very helpful.
Comment 9 Sean Flanigan 2012-06-27 03:45:51 EDT
No, only the Maven log messages like this one:
  [INFO] org.zanata:zanata-maven-plugin:1.6.0-alpha-3-SNAPSHOT
which unfortunately doesn't include a timestamp.  But if you make sure to test with the latest snapshot, that shouldn't be a big problem, as long as you include your own timestamp.

Looking at the MANIFEST.MF inside the jar file, we are including a field SCM-Changeset which is the git commit ID.  We just need to add some code to pull it out at runtime, and put it in a log message.

We have another field in the manifest: Implementation-Build: 20120622-1259.  We could include that in the log too.

You might like to submit an RFE for the client to output the above information.

Note You need to log in before you can comment on or make changes to this bug.