WISH : Base64coder as an external dependency

[GoogleCodeExporter]

Since there are no functional differencies between the included base64coder and 
the original source taken from biz.source-code, please, reconsider it's usage 
in form of external dependency instead of including it directly in the 
snakyaml's source tree.

Christian d'Heureuse seems to be pretty responsive and cooperation with him 
isn't problematic at all.

I believe there are no major changes planned in the base64coder's interface, 
therefore You don't need to be affraid of functional losses due to the 
base64coder referrencing.

Original issue reported on code.google.com by jcapik%r...@gtempaccount.com on 9 Jun 2011 at 4:20

[GoogleCodeExporter]

Using base64coder as an external dependency is a mega change for SnakeYAML.
Currently SnakeYAML does not have any external runtime dependencies and it 
gives a lot of flexibility. If a dependency is introduced, then what should 
happen if users have the same dependency but they use a different version ? 
They have either to change their version or to ask SnakeYAML to change the 
version. It becomes a version nightmare for those who have to maintain big 
projects.
Since THERE IS ABSOLUTELY NO PROBLEM with the included source it should better 
stay as it is. In case of a bug or security hole it should be considered as a 
failure of the whole package.

Original comment by py4fun@gmail.com on 9 Jun 2011 at 5:06

• Added labels: Type-Task
• Removed labels: Type-Defect

[GoogleCodeExporter]

The fact that SnakeYAML is using a small piece from Google Data API 
(http://code.google.com/p/snakeyaml/source/browse/src/main/java/org/yaml/snakeya
ml/external/com/google/gdata/util/common/base/) should not cause to include the 
whole API (http://code.google.com/apis/gdata/docs/directory.html) as an 
external dependency 

Original comment by py4fun@gmail.com on 9 Jun 2011 at 5:57

[GoogleCodeExporter]

I agree with  py4fun. Why would we have all those dependencies just to use few 
classes. Especially when those needed ones do not require anything else.

Now the size of the SnakeYAML is small enough to be used in applets and 
webstart.

But I understand that for the distribution as part of the system (Fedora I 
suppose) it would be ok to use external dependency which is a part of the 
system already.

If I remember correctly there is maven-patch plugin or something like this. Why 
wouldn't you create redhat profile in snakeyaml pom.xml which will apply needed 
patches to use external dependencies when package is build?

Original comment by alexande...@gmail.com on 10 Jun 2011 at 8:12

[GoogleCodeExporter]

Well. 

We actually patch snakeyaml to use external dependencies at the moment.
We're just affraid of possible future changes of the included parts without 
propagating them to upstream and by making them so incompatible, that it would 
be impossible even for us to propagate them to upstream by ourselves.
Reusability is one of the key targets in all Linux/BSD distributions I know. 
Actually, most of the distributions have a similar policy for regulation of 
bundled (included) stuff. One of the distributions I maintain is targeted to 
low performance systems, where the storage usually suffers a lack of free space 
and where every kilobyte counts. And whilst everything else has a tendency to 
shrink and split to separate functional parts, Java projects often go the 
opposite direction and become so huge, that nobody wants to include/maintain 
them.
Imagine a situation when all projects make a decision to include the 
base64coder instead of referencing it. Then we'll have the same code multiplied 
many times. And even if it is quite small, it still counts. It's a very 
interesting phenomenon. Java people generally don't want to care about changes 
made in other projects, to cooperate with them and modify their own sources 
accordingly. Believe me, this trend of huge monoliths can be observed mainly in 
the Java world and nobody knows why. I don't understand it neither. The only 
thing I can do is to fight for a change in form of wishes like this one.
If this change is not welcome, I'll try to continue with maintaining the local 
patches the best way I could.

Anyway ... thank's a lot for Your official statement.

Best Regards,
Jaromir.

Original comment by jcapik%r...@gtempaccount.com on 10 Jun 2011 at 10:32

[GoogleCodeExporter]

I see your point and agree. It is just that we look at the use of SnakeYAML 
from different perspectives :)
You look from system distribution side, I look from web-based application 
distribution like applets or webstart.
From your side it is of course waste of space, I agree totally. But from my 
side unneeded dependency is waste of space/bandwidth. Since applet/webstart 
deployment is far less sophisticated than package installation in the OSes it 
makes difference.

Maybe when we have time we can introduce profile which will build snakeYAML 
against some external dependencies deploying artifact with specific classifier. 
So those who prefer dependencies can use that specific build.

Sorry if I put words a bit complicated way (it is not) ;)

-alex 

Original comment by alexande...@gmail.com on 10 Jun 2011 at 11:07

[GoogleCodeExporter]

>> Maybe when we have time we can introduce profile which will build snakeYAML
>> against some external dependencies deploying artifact with specific 
classifier.
>> So those who prefer dependencies can use that specific build.

That was exactly one of my not very clear visions how the change could be done 
without having a negative impact on the snakeyaml project. If You find some 
time one day and provide us (and possibly other distribution maintainers) with 
a directly downloadable source-only package (ready for the build against 
external dependencies), we would really highly appreciate that.

Once again, thanks for Your answers, guys!

Have a nice day.

Jaromir.

Original comment by jcapik%r...@gtempaccount.com on 10 Jun 2011 at 12:29

[GoogleCodeExporter]

Original comment by py4fun@gmail.com on 10 Jun 2011 at 1:14

• Changed state: WontFix