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 ...
Related
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.
I'm on the process of release a play app to production. So far most of my experience has been with java projects, using maven with maven-release-plugin, for version incrementing, creating a version tag in git, etc.
How to handle releases and version changes with play framework?
I found a few mentions about sbt-release, but haven't found a complete tutorial or a sample project.
Depends on you requirements, in my experience I haven't had much need to do the whole build-test-commit-tag-release-commit dance, but then I have used it in continuous-delivery-like circumstances. Just making sure that there is something marking what VCS-revision a certain binary is (for example using sbt-buildinfo) and then using plays dist has been enough.
If you really need it the sbt-release plugin has got a pretty detailed documentation. I would try with that to begin with.
I just want to know if the application is going to be developed in Java, is it better to go for Play 1.x.x or 2.x.x?
and How long the version 1.x.x will be supported? Is it an active fork?
Thanks
Start with Play 2+ reason is simple, Play 1.x is NO longer officially developed by Zenexity. It's only in maintenance mode now.
A fork has appeared a couple of months ago : Yalp Framework.
Basically 1.x.x is still around because it is really different from 2.x.x
converting Play1 projects to Play2 is almost recoding everything so Play has to keep on supporting Play1 to keep the "customers" that are already doing production with 1.x.x
If you are starting a project now, be it Java or Scala, I advise to get Play 2.1.x since it has the latest and most awesome features. And it also works with the latest versions of scala (which I am aware is not relevent to your question).
TLDR : 1.x.x is outdated but still supported because a lot of people are still using in production since it is not easy to port a 1.x project to 2.x
First I think you should read What are the major differences between Play Framework 1.0 and 2.0?.
2.x is in active development, how ever if you have trouble you must read the core-code which is scala and you must handle with SBT, which is more Scala Build Tool than Simple Build Tool.
For play 1.x there is a fork yalp, but it's in the beginning and will break with the old api, but it's plain java.
If you need some of the features of play2.x (responsive web in meaning of a server which has a good responsiveness nothing to do with webdesign.) I think play with scala is the best choice. If you have a simple application, play1.x does everything you need.
So check the tutorials to get a feeling.
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.
I am just learning about android app development and have created my first app which is a relatively simple app with a link to a gallery of images and some text pages. I created this using the 1.5 platform as it seemed sensible to make it backwards compatible. I've been testing it on 3.0 and it comes up tiny on the screen and I have since learnt I need to use supports-screens and other related commands to allow variable screen support which from what i read is only available in 1.6 and above. As a result I need to change the app platform to 1.6 or above and my questions are as follows:
1) Am I able to just go to project properties and change the platform version tickbox to a newer one (in this case 1.6)? As I tried this with the project but the supports-screens tag still gives an error (which it doesn't when I create a brand new project)?
2) What version should I be creating it in these days for ideal backwards compatibility but able to use most desirable features? I understand 1.6 includes a lot of the newer functionality but according to http://developer.android.com/resources/dashboard/platform-versions.html only about 4% of people are using less than 2.1 so is it better to just code using 2.1 (assuming I want to target mobiles and tablets)?
Thanks so much for your help as ever,
Dave
Take a look at this. It explains how you can go about changing your AndroidManifest.xml to specify which version of the SDK to use. You may also need to update default.properties to point the target to the proper api value.
This really depends on what you want to do. If you require something from 2.1 or 3.0, then I think you need to go with that. But if you can get by using just 1.6 and still have all the functionality that you need/want, then I would definitely recommend using 1.6.