You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 15, 2024. It is now read-only.
Firstly, thanks for all the great work on this so far. Just having a sane implementation of GP stuff has been a great reference when compared to the GP docs.
Could we change the access level of "entries" in the CAPFile class, or provide some other method of getting it? We have some other legacy systems that sign our cap files and use a different format than supported (specifically, it uses "meta-inf" in lowercase.., among other silly things).
I come from python land so I'm used to just having access to anything I need, but could we make the implementation a little more flexible here?
I could either
Make the entries type protected so that I can subclass it and implement the DAP component lookup for our specific system there
Make a public getZipFileComponent method that gets any arbitrary component out of the zip, then deal with it there
I'd be happy to implement, submit the PR, and bump the version in GlobalPlatofrm
The text was updated successfully, but these errors were encountered:
Sure, this "library" has not gotten very much design thought, yes.
K, 17. oktoober 2018 kell 05:51 jmrgibson <[email protected]>
kirjutas:
Firstly, thanks for all the great work on this so far. Just having a sane
implementation of GP stuff has been a great reference when compared to the
GP docs.
Could we change the access level of "entries" in the CAPFile class, or
provide some other method of getting it? We have some other legacy systems
that sign our cap files and use a different format than supported
(specifically, it uses "meta-inf" in lowercase.., among other silly things).
I come from python land so I'm used to just having access to anything I
need, but could we make the implementation a little more flexible here?
I could either
1. Make the entries type protected so that I can subclass it and
implement the DAP component lookup for our specific system there
2. Make a public getZipFileComponent method that gets any arbitrary
component out of the zip, then deal with it there
I'd be happy to implement, submit the PR, and bump the version in
GlobalPlatofrm
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#11>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AACztpJRnd-sd9y8S1rHpnxSMOza5YcMks5ulpstgaJpZM4XjB4A>
.
--
Embrace change!
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Firstly, thanks for all the great work on this so far. Just having a sane implementation of GP stuff has been a great reference when compared to the GP docs.
Could we change the access level of "entries" in the CAPFile class, or provide some other method of getting it? We have some other legacy systems that sign our cap files and use a different format than supported (specifically, it uses "meta-inf" in lowercase.., among other silly things).
I come from python land so I'm used to just having access to anything I need, but could we make the implementation a little more flexible here?
I could either
entries
type protected so that I can subclass it and implement the DAP component lookup for our specific system theregetZipFileComponent
method that gets any arbitrary component out of the zip, then deal with it thereI'd be happy to implement, submit the PR, and bump the version in GlobalPlatofrm
The text was updated successfully, but these errors were encountered: