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.
Related
Java 8 and prior versions have Java Web Start, which auto-updates the application when we change it. Oracle has recommended that users migrate to jlink, as that is the new Oracle technology. So far, this sounds good. This comes with a host of benefits:
Native code on Windows, Mac and Linux
Modularization of the code (although Proguard does this as well)
The use of new, supported technology.
The problem: I can't find the canonical Java solution to auto-update with jlink.
One would think that Java Web Start could continue to be used, especially if one casually reads this document. Notice the fact that Java Web Start continues to be prominently listed. But there's a fly in the ointment: Oracle is deprecating Java Web Start. It's slated for removal in JDK 11. So, what's the official path forward. Failing that, is there a standard way that people proceed?
For the purposes of this question the following are out of scope:
Paying huge amounts of money yearly to someone with an feature-packed enterprise solution. The application to be distributed is already packaged into a single jar that is smaller than 50MB.
Forcing users to run an InstallShield style app to reinstall the new version, and then manually uninstall the old version every time an update is pushed. That's sooo 1990's.
Porting the entire app to be a webapp, rewriting the UI and client side logic to fit in a browser and dealing with all the incompatibilities that entails. The authors of the application worked on GWT and know exactly what web browsers are capable of. Unfortunately, they also know the level of effort required.
Allowing users to continue to run old versions of the application. That, too, is sooo 1980's. Modern apps update quickly, and supporting every version of the application ever released is not tenable. That's what my father's COBOL application had to deal with, and he didn't enjoy it. I'm hoping technology has progressed.
Continuing to use Java Web Start. Until/unless Oracle changes its mind, Java Web Start is a doomed technology.
In May 2019 commented to watch the OpenWebStart project.
Now (October 2019) it is time to give OpenWebStart serious consideration. While not yet feature complete, a alpha beta release of OpenWebStart is now available for download under a "GPL with Classpath exception" license.
The OpenWebStart Technical Details page states:
OpenWebStart is based on Iced-Tea-Web and the JNLP-specification defined in JSR-56. It will implement the most commonly used features of Java Web Start and it will be able to handle any typical JWS-based application. We plan to support all future versions of Java, starting with Java 11. In addition to Java 11, the first release of OpenWebStart will also support Java 8.
The page goes on to state that OpenWebStart will support interactive installers with auto-update, and non-interactive installers. Some JNLP features will be supported, and it will include a replacement for the Java Control Panel. A more comprehensive list of planned features1 and their implementation status is provided in the feature table.
1 - If you have a requirement that is not on their feature list (e.g. jlink support), you could contact the OpenWebStart team, and offer a suitable incentive (e.g. money to pay developers) to implement the feature for you. They also offer commercial versions of the software for paying customers.
Disclaimer: I have no connection with the OpenWebStart project, the company (Karakun) or the project sponsors. This is not a recommendation.
I had a similar problem in a past project. We needed to migrate from Webstart to another technology.
The first approach was to install IcedTea. It is directly bundled with the AdoptOpenJDK Project.
But as far as I understood the problem, Java wasn't meant to be installed on the Client side like this anymore and we didn't want problems with all of our customers.
Our solution was then building an own specific Executable, which connects to the server, ask for enviroment settings from the server side, and then download and extracts the JLink Java. So we could use the old technologies and just wrapped it in an Executable.
Last thing done then was redirecting to the download location of the Executable when calling the jnlp-URL.
Do you use maven?
I've resolved my similar problem with maven (I need to update an EAR).
My main app (the ear package) has a pom.xml with listed the dependencies and repositories.
The dependencies have the <version> tag with a range (documentation) as in this example
<version>[1.0.0,)</version>
That means : get version 1.0.0 or newer of the dependency. (You can put also an upper bound to the version, [1.0.0, 2.0.0) so if you develope a new version, it is not used in old app)
In the repository section I added my personal repository.
Now, in the remote machine I need only to rebuild my ear package with maven : the compiler download the newer version of my jar and put it together.
You need a system to check if there are newer dependencies version and warn the user to update the app and also lock its work (you can't work if you don't update). Maybe you need a little app to make users do the rebuild process easily. It's 1990's but a lot of desktop-app works in this way
PRO
This schema can be used in a lot of different projects.
CONTRO
You need to build the app in the remote machine, so the client must have a JDK and access to your repository (like artifactory);
You must write code in different jars and add them like dependencies in the main archive.
You must change JAR version each time and publish on the repository (this could be a good practice)
I would like to use a Java library (SpringBoot) in latest version (2.0.0.M6), but I prefer to use only releases. So what means this "M6" in the library version? Is it a pre-release?
Thanks!
It is a Milestone release. The version includes some set of functionality that were released as soon as that set of functionality was complete.
In some organizations, this is considered pre-alpha software, where an alpha release is the first phase to start white-box, and possibly black-box or grey-box testing techniques.
Since these milestones have a number associated with it, this is the sixth milestone. What that means is entirely dependent on the project, and its development / release plan.
For spring-boot specifically, they targeted the completion of these issues to state that they had "achieved" 2.0.0, Milestone 6.
https://github.com/spring-projects/spring-boot/milestone/92?closed=1
In any case, this is pre-release software.
From nexus documentation, I can only find osgi related sections in version 2.xx, does osgi support removed in version 3 or it's a builtin feature now?
OBR support is unlikely to come to Nexus Repo 3 any time soon from Sonatype officially, but that shouldn't stop people from doing it themselves.
Here are a few examples of Repo formats implemented in Nexus Repo 3:
https://github.com/sonatype/nexus-repository-r
https://github.com/mpoindexter/nexus-repository-apt
A few more are coming soon, and should provide a good basis for someone who wants to implement OBR.
As for why OBR hasn't been implemented yet, it's mainly due to priorities, we've got a lot of new and old to implement and it's pretty far down the list at the moment.
If anyone has interest in implementing OBR support, feel free to reach out to me and I'll help best I can, that's one of my jobs at Sonatype. You can get in touch with me near real time at: https://gitter.im/sonatype/nexus-developers
There really isn't any need to rely on Nexus plugins in order to get an indexed OSGi repository. In fact I wouldn't recommend it because the version of OBR support in Nexus (in versions of Nexus that support it natively) lags far behind the latest standards.
Instead, use the bnd-indexer-maven-plugin to generate an index for a set of Maven dependencies. The output of this plugin, along with the dependencies themselves, can be deployed to a Nexus repository or any other repository with Maven support.
Nexus 3 support list is here. So no OBR support in Nexus3 yet. Even if the status is "Working on that" it is unlikely it will be there soon.
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.
Folks, I am in the process of releasing a plugin for Solr (under ASF license) that implement different ranking strategies. I have tested it against 3.5 version, it works great, since I started fairly recently on open sourcing it went with latest version of Solr (3.5). But then a request came in to use that plugin for version 1.4. The problem is that Solr API has undergone some significant changes between 1.4 & 3.5.
For instance, SolrQueryResponse was moved from
org.apache.solr.REQUEST.SolrQueryResponse (1.4)
to
org.apache.solr.RESPONSE.SolrQueryResponse (3.5)
I use Git for DVCS, Maven for Build/Project Management, Google Code for project hosting, what would be an ideal strategy to make changes & maintain the code for different versions of underlying Solr/Lucene API. Branch could be way to achieve it, but I am not really convinced.
Would like to know if there is a better way to develop/maintain code for different underlying API versions & distribute them ?