brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graeme-Miller <...@git.apache.org>
Subject [GitHub] brooklyn-server issue #623: BundleMaker copy fix
Date Fri, 07 Apr 2017 12:50:15 GMT
Github user Graeme-Miller commented on the issue:

    https://github.com/apache/brooklyn-server/pull/623
  
    Can you provide steps to re-produce
    @m4rkmckenna quickest way to replicate is to use the brooklyn cli from here: https://github.com/apache/brooklyn-client/pull/44.
Using that CLI, zip up a folder and send it to a standard brooklyn.
    
    Even though go creates the zip correctly, brooklyn is unable to copy it due to a mismatch
between the amount of compressed bytes the zipfile created by go is reporting, and the zipfile
created by java is reporting. This is likely due a difference between the algorithms go and
java use.
    --------------
    
    does this happen for every uploaded zip
    No, as long as the same algorithm and compression level is used this should not happen.
I have yet to be able to recreate this with anything other than the zip created by go (which
leads me to believe google are using a different, smarter algorithm)
    
    



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message