After upgrading Sonar to a newer version (5.6.1), we had our Public Api Documentation measure crash down to 40%
Looking on Sonar website, I found that there is a configuration key that define if the Getters & Setters are counted in the documentated Api : "sonar.squid.analyse.property.accessors"
http://docs.sonarqube.org/display/SONARQUBE50/Metrics+-+Public+API
But I cannot find where to check or update it from the Sonar Interface.
So if anyone can shed some light ?
First, the documentation you reference is the archived docs for an old version, 5.0, and not necessarily relevant to the version you're using.
Second, I'll bet that when you upgraded the platform, you upgraded the Java plugin too. 5.6.1 shipped with Java Plugin version 3.13.1, but you appear to be using version 4.0 or beyond. It was in 4.0 that the plugin stopped paying attention to accessors and removed the sonar.squid.analyse.property.accessors property: SONARJAVA-398
So yes, when it stopped paying attention to accessors, that would have changed your Undocumented API numbers.
Ok after bothering the sonar people through Jira and google group, they have aknowledged the issue and created a ticket.
https://jira.sonarsource.com/browse/SONARJAVA-1857
Have to wait 4.3 of the java plugin though.
Related
I'm running an old version of appengine-api-1.0-sdk (1.9.54) and want to upgrade to a newer version (1.9.90), but I can't find any list of changes from one version to the next. I would have expected a release note or something in the download, but it just points me to a general Java page for Appengine: https://cloud.google.com/appengine/docs/java/release-notes. This doesn't tell me what has changed from one version of the SDK to the next.
Thanks
Tim
You can use BigQuery to select different points between 2 versions
https://console.cloud.google.com/bigquery?p=bigquery-public-data&d=google_cloud_release_notes&t=release_notes&page=table&_ga=2.107183563.811335336.1632571946-1193389554.1631929347
Currently I am using Exoplayer library with version 2.3.1. I want to include Exoplayer version 2.7.0 in same project. How can we do that without conflict?
I tried to include 2.7.1 and 2.3.1 so it's taking updated version by default.
"I tried to include 2.7.1 and 2.3.1 so it's taking updated version by default."
I would suggest just trying to change your app's dependency on Exoplayer 2.3.1 to 2.7.0.
If you don't get compilation / build errors ... and your code works, then you have answered your question.
If you get compilation errors, examine them carefully, look at the Exoplayer javadocs and release notes, and figure out what changes you need to make your code to use the newer APIs.
If updating your code proves intractable (i.e. too much work), you may well be stuck. However, it shouldn't be. It is unlikely that the authors of the library would produce new releases that are so incompatible that upgrading is intractable ... for a skilled engineer. What is more, the Exoplayer site says:
"Unlike the MediaPlayer API, ExoPlayer is easy to customize and extend, and can be updated through Play Store application updates."
(emphasis added) so they clearly intend upgrading to be simple.
Getting an application to use two separate versions of some library at the same time is unlikely to work. And it is unlikely that you want your application to have two distinct media player UIs ...
When using different Google Java SDKs, you include the right version which is defined by, for instance, v2-rev292-1.21.0 for the latest BigQuery library version. I suppose the syntax is something like this : version-revision-some other version, but I can't seem to be able to find an explanation for the relationship between the three parts. This is problematic when you need to upgrade versions and finding out that updates give compilation errors without changing (what I thought) was a minor version.
Can somebody explain precisely the Google SDK versioning nomenclature? In particular, what does the second version mean?
I've read the HornetQ FAQ, but I can't find anything related.
I'm using HornetQ 2.2.5, it contains a bug (yeah, just one ;). According to this post https://community.jboss.org/message/624958?tstart=2 it's been fixed from 2.2.7.Final onward.
On the main download page, http://www.jboss.org/hornetq/downloads the latest version available is 2.2.5.Final. I'm not scared of compiling a newer version myself, but can I consider it stable?
I'd say yes since it's a minor release update, but I'd like some other opinions. Thanks.
This answer uses the 2.3.X branch as an example. Let's skip looking at their Downloads page, and go straight to the artifacts:
http://mvnrepository.com/artifact/org.hornetq/hornetq-pom
You can see that 2.3.X went through Alpha, Beta and CR stages, to finally reach 2.3.0.Final, the Community release. This is what most people in the open source world would end up using, and what you will find available for easy download.
It's also the last version the non-paying customers are intended to use (in the typical JBoss release cycle - see e.g. the JBoss AS/EAP FAQ). Now, from a commerical perspective, 2.3.0.Final would be considered Alpha again. An analogy from the JBoss AS/EAP FAQ which probably applies here too: "The first EAP stage Alpha is of equivalent, or better, quality to a community Final release [...] we don't recommend using it in production" (probably an overly harsh judgement, but anyway.)
After 2.3.0.Final, they fix more bugs (2.3.1.Final, 2.3.2.Final, ...) until they get to a commercial production release (which they bundle into their other commercial products). So, you should be using the latest .Final that you can for production (for the 2.3.X branch, it was 2.3.13.Final).
Do you have to pay for 2.3.13.Final? From what I can tell, you don't. (HornetQ is also not available commercially AFAICT, except when bundled into other products.)
How do you get 2.3.13.Final? You probably won't find a nicely packaged RPM or even zip file. Instead, you will need to get the JARs from public Maven repos (or build from source).
Do you need a postgrad degree in JBoss Versioning and Product Naming to use their products? Perhaps :) - I don't have one, so apologies in advance if I have failed to comprehend the enormous complexity of the beast. But I do wish the HornetQ developers would make it easy to get a stable release of their product, and know that this is what one is using. It's a good product (perhaps the most fully featured of the lot), with an excellent manual, but a snap judgement of the download page and FAQ may make some people look at competing projects instead.
Well, after some more research, I can say yes, it is stable.
In particular, JBoss EAP 5.1.2 package includes HornetQ version 2.2.10.GA.
I wonder why there is no direct link on the HornetQ download page.
Since upgrading to Eclipse 3.7, the Eclipse PDE plugin wants me to specify an 'API Baseline' for all my Eclipse Plugin projects.
However there seems to be no documentation which actually explains what 'API Baseline' stands for here, and what is it used for.
Could somebody please explain?
API Baseline are intended to help you maintain plugins that others can use. The API Tools help you create compatible API versions. Follow the link that Sumit Singh posted to get an explanation on how to use them.
The Problem:
You create your plugin and release version 1 to the public.
Millions of people will use your plugin and create their own code that depends on the API of your plugin.
You release version 2 to the public. By mistake you change the API of your plugin.
Millions of people update to the new version and have to adapt their code. Thousands of programs fail. People are sad.
The Solution:
You create your plugin, annotate its API and release version 1 to the public.
Millions of people will use your plugin and create their own code that depends on the API of your plugin.
You declare version 1 of your plugin to be the API-Baseline that your code changes are automatically compared against. Any break in the API is presented to you before you release your plugin or run your tests. You release version 2 without any API changes.
Millions of people can update your plugin in their application, because the new plugin release is binary compatible to the previous one.
You declare version 2 of your plugin ....
Summary
If you develop a plugin just for your personal use and are not interested to maintain a compatible API, you can follow the advices to disable the warnings.
When you develop plugins for a community, e. g. the eclipse plugins themselves, it is essential that you keep API incompatibilities to a minimum. Then you will follow the advice and set the baseline to 4.2 when you develop for 4.3. The API tools will help you make 4.3 an enjoyment for all current 4.2 users.
Please note, that the API Tools are for the developers of the plugins that will be used by others. They are not addressed at the users of those plugins.
From the PDE API Tools User Guide:
An API baseline defines the state you want to compare your development workspace bundles against for the purposes of binary compatibility, bundle version numbers, and #since tags. For example, if you are developing bundles for Eclipse 3.4, you will use Eclipse 3.3 as your baseline.