Use Base64 implementation from JDK

[GoogleCodeExporter]

Snakeyaml currently uses Base64Coder class downloaded probably from 
www.source-code.biz. JDK has its own Base64 implementation since 1.3 and I 
think that there is no need to use separate implementation (potentially 
unmaintained). Please consider replacing Base64Coder with JDK implementation.

Thanks

Original issue reported on code.google.com by srb.mic...@gmail.com on 22 Apr 2013 at 9:09

Attachments:

• use-base64-from-jdk.patch

[GoogleCodeExporter]

Oops, I have just noticed that some tests are failing with my patch. I will fix 
it.

Original comment by srb.mic...@gmail.com on 22 Apr 2013 at 12:38

[GoogleCodeExporter]

Ok, JDK implementation silently skips invalid base64 characters (which is 
correct), but YAML specification says that the characters other than the base64 
alphabet are considered error. In this case, you can't easily switch to JDK 
implementation.

However, this base64 implementation which is bundled in snakeyaml project makes 
packaging snakeyaml for various linux distributions kinda difficult. Bundling 
libraries in packages is usually not allowed.

I have another proposal. What about adding dependency on Maven artifact 
biz.source_code:base64coder:2010-12-19 to the pom.xml? You will get the same 
base64 implementation, but in form of external dependency. What do you guys 
think?

Thanks

Original comment by srb.mic...@gmail.com on 24 Apr 2013 at 12:12

Attachments:

• base64coder-as-an-external-dependency.patch

[GoogleCodeExporter]

SnakeYAML does NOT bundle any libraries. Please consider the whole source as 
one package. There is no conflict with anything. If the package name is 
confusing, we can move the base64 implementation to another package (although I 
do not understand the problem here)
Any external dependency leads to a version conflict. This is no option.

Original comment by py4fun@gmail.com on 24 Apr 2013 at 5:39

[GoogleCodeExporter]

Hi py4fun,

thanks for your answer. You're right that snakeyaml doesn't bundle any JARs, 
but it contains source code from other projects (base64coder and gdata-java).

https://bugzilla.redhat.com/show_bug.cgi?id=875777

For example base64coder is a separate project used by many applications and 
available in form of JAR. From linux distribution point of view it's better to 
have single package which provides base64coder and all packages can use this 
single instance. If there is a bug, it can be easily fixed in one place for all 
applications.

But I can see your point with external dependencies. Fedora will probably use 
proposed patch, but it would be nice to stay as close to upstream as possible. 
That's why I am trying to propose/find solution here.

Thanks

Original comment by srb.mic...@gmail.com on 25 Apr 2013 at 7:16

[GoogleCodeExporter]

I think this one has been discussed before. (see issue 122)

Original comment by alexande...@gmail.com on 25 Apr 2013 at 8:08

[GoogleCodeExporter]

If a bug is found inside Base64 implementation, it is a bug of SnakeYAML and it 
should be fixed by SnakeYAML. We do not want that SnakeYAML changes its 
behaviour because someone else has changed the packaging inside a Linux 
distribution.
Please note that we do not have a link to any external resource, but we are 
building and packaging everything inside our own JAR. There is no issue here.

Once SnakeYAML begins to include a Thunderbird client for its business, we will 
start to consider to use it as external dependency.

Original comment by py4fun@gmail.com on 25 Apr 2013 at 8:58

• Changed state: WontFix