Update org.jeromq:jeromq:0.2.0 to org.zeromq:jeromq:0.3.4
fix long frames in ZMTP 1.0

Summary:
If the size is 255 that means that the real size is in the next 8 bytes
as a long. Problem is previously didn't check if the buffer has 8 more
bytes to read. This returns -1 which signals that the length isn't yet
readable and will cause parseZMTP1Header to return false. This will
cause parseMessage to resetReaderIndex back to the mark and to wait for
more bytes.
Merge pull request #15 from beckerdo/master

Update org.jeromq:jeromq:0.2.0 to org.zeromq:jeromq:0.3.4
add test to demonstrate issue

Summary:
These test show how to handle an incomplete header that doesn't yet have
the long size. This is handled already for 2.0 header parsing
check for at least one readable byte for length

Summary:
Restores the functionality changed in
d1e1b530a317450a827e6fe283f0927f25c7cab8

Tests to show the behavior expected
Merge pull request #17 from SupermanScott/long-frame-size

vacation brain, indeed. After writing some more tests, your fixes with returning -1 indeed resolves all the issues I've been able to reproduce. Merging.
Regression tests of the ZMTP/1.0 fragmentation issues reported in PR17
[maven-release-plugin] prepare release v0.2.1
[maven-release-plugin] prepare for next development iteration