Hi,
So the 3.1 vaadin charts has some refactoring changes - generally not great for a library to do this as it ruins backward compatibility.
Some of these changes involve just case changes - e.g. SubTitle has changed to Subtitle - seems no need to do this!
But…if it’s going to change, the Configuration getter should also be refactored to match it:
Subtitle Configuration.getSubTitle()
This is just one example - there are many others. It’s not very consistent, and it adds time to developers’ work when having to port this across lots of existing chart source just for the sake of case. When these naming inconsistencies are detected down the road, it inevitably means more refactoring in future versions, and even more breaking of backward compatibility…and so it goes on…
Please, please would it be possible for the wonderful folks at Vaadin to adopt a ‘no-changing-of-the-existing-library-interface-once-its-released’ policy that seems to be a forgotten art in the open source world (did I hear someone mutter log4j under their breath?).
Seriously though, I am a huge huge fan of Vaadin and I full advocate the technology you deliver. Just need to steer clear of unversioned lib changes.
Many thanks,
Peter
Hi. Sorry that you have found inconcistencies in the API. We redid a chunk of the API when building Charts 3. There were a bunch of inconsitencies that we fixed and apparently introduced a few new ones on the way. We do in fact have a dont-change-api policy. We strive to only change or remove API in major versions, and 3.0.0 was the was were we had some API cleanup in. API additions we usually do in major and minor versions, like 3.1.0 and 3.2.0. Therefore I’m a bit hesitant to now do changes to the API and for example fix SubTitle for Subtitle as there are already many who have updated to 3 -branch and we want to avoid to break their apps.
Thanks for your feedback.
Jens
Product Manager for Pro Tools
Hi Jens,
Thanks for your reply. Yes, makes sense now that it’s released…
In previous versions, I didn’t find the API that inconsistent, seemed ok.
Now in v3, there are loads of inconsistenices - with itself, and with general java naming conventions (mostly to do with camelCase).
A quick request: could you please add the model jar javadocs + src to the distribution - it would make develpoment in Eclipse a lot easier!
Many thanks,
Peter
Thanks to you, we noticed a problem in our builds. The releases include the sources and javadoc jars for the model package in Maven, but they are not in the downloadable zip that can be found from https://vaadin.com/directory#!addon/vaadin-charts. I guess you are handling dependency management manually? You can download the sources jar from here: http://maven.vaadin.com/vaadin-addons/com/vaadin/addon/vaadin-charts-model/3.1.0-rc1/vaadin-charts-model-3.1.0-rc1-sources.jar
We will fix the issue so that the zip package includes the model sources in future releases. If you were not using the zip from directory, please share how you manage dependencies, so that we can fix those as well if we have missed something.
Thank you.
You are absolutely correct, we handle all dependencies manually (I’ll spare you the Maven reasoning why that is 
Thanks for providing the sources, that’s great. It helps a lot to understand some of the new features in v3. Many thanks for your help!
Peter