Merge gems?

[toretore]

Hi,

I'm the author of Barby [1], a wrapper for multiple barcode symbologies in Ruby. We're currently working on getting proper PDF417 support in place; currently, there's only a vendored Java version available. What I have in mind is to take out the Java bits, merge them with the C version and release this as a separate gem. We have some of it in place already [2], but I think it would be silly if there were two very similar gems for doing PDF417, and it seems you've already done a bit of work on this one..

So here's my question: Would you be open to a PR which merges in some Java bits along with the necessary scaffolding to make it work the same as the C version (AFAIK it's a port). I think it could be done quite cleanly. It would in reality become two gems, but AFAICT RubyGems handles this transparently so that it does not affect the end user, they get the version they're supposed to have. The (existing) wrapper class just requires the "lib" class as usual, which will be either C or Java.

[1] http://github.com/toretore/barby
[2] https://github.com/Keeguon/barby-pdf417

[jamesprior]

Yes, that sounds good! If we can get to one gem which works for people I’d much rather do that than have multiples out there.

On Dec 3, 2013, at 5:49 PM, Tore Darell notifications@github.com wrote:

Hi,

I'm the author of Barby [1], a wrapper for multiple barcode symbologies in Ruby. We're currently working on getting proper PDF417 support in place; currently, there's only a vendored Java version available. What I have in mind is to take out the Java bits, merge them with the C version and release this as a separate gem. We have some of it in place already [2], but I think it would be silly if there were two very similar gems for doing PDF417, and it seems you've already done a bit of work on this one..

So here's my question: Would you be open to a PR which merges in some Java bits along with the necessary scaffolding to make it work the same as the C version (AFAIK it's a port). I think it could be done quite cleanly. It would in reality become two gems, but AFAICT RubyGems handles this transparently so that it does not affect the end user, they get the version they're supposed to have. The (existing) wrapper class just requires the "lib" class as usual, which will be either C or Java.

[1] http://github.com/toretore/barby
[2] https://github.com/Keeguon/barby-pdf417

—
Reply to this email directly or view it on GitHub.

[keeguon]

Hey, I'm the guy who wrote the cross-platform gem that you can see here: https://github.com/Keeguon/barby-pdf417, I used the C library provided here: http://sourceforge.net/projects/pdf417lib/ as you must have as well. I see you did your own C implementation however since Barby was already supporting Java and based most of his code on the Java class I used the same bindings that the Java class in C to build the extension (I know it's not very C/Ruby-like but it simplifies things greatly). Anyway, I'm available to chat about a possible merge of your code into the C Pdf417 implementation of Barby.

[jpaas]

+1 for wanting this to happen! any progress?

[toretore]

I started on it and made good progress, but haven't had time to finish it.
I do plan on finishing it as soon as I find the time.

On Wed, Jun 11, 2014 at 4:15 PM, Julian Paas notifications@github.com
wrote:

+1 for wanting this to happen! any progress?

—
Reply to this email directly or view it on GitHub
#2 (comment).

[irobayna]

+1 any updates?

[bonol]

+1 Any updates?

[keeguon]

@bonol as far as I know you can install both barby and barby-pdf417 gems and require the pdf417 barcode which should load the one from my gem which is compatible with MRI and jRuby. I haven't tested those in a while so if you encounter some issues please let me know.