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 ?
Related
I've found out that it is very uncommon to choose a client version that is not the same as the server's version (for example in HBase client - server’s version compatibility).
On the other hand, I've got an answer about Camel compatibility that had been mentioning the Camel-HBase jar that I can find a fit version of the client's jar through downgrading it (for example https://mvnrepository.com/artifact/org.apache.camel/camel-hbase/3.1.0 for an old HBase version). But this answer also said that it is a bad thing to do (Can Apache Camel integrate with an old HBase version?). I wonder what is the solution if there is no such option for me to upgrade the HBase server (since it's not mine). Why choosing a lower Camel component (such as Camel-HBase) version is bad?
It's impossible to work otherwise since it will demand every integrated technology to be the most upgraded.
Sorry, obviously my answer you mention was not clear enough.
You absolutely can use an older Camel version whose dependencies match your specific Hbase-client version need.
But this decision hat some drawbacks:
You cannot upgrade your Camel application (version lock-in)
You cannot use another Camel component in the same application that has a more recent version because mixing Camel component versions (eg. camel-core 3.9.0 and camel-hbase 3.1.0) leads to lots of problems
The consequence of these points is that you probably have to "isolate" your Hbase integration in a Camel application that uses an old, "freezed" Camel version.
"Isolate" because as soon as you want to do something else that needs a newer Camel version, you have to build a new application that communicates with your hbase-integration through an API.
I hope, this answer makes more sense for you.
About your final statement
It's impossible to work otherwise since it will demand every integrated technology to be the most upgraded.
There are a lot of technologies that offer a much wider compatibility. Messaging clients like Kafka or ActiveMQ are wire-compatible with older server versions.
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'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.
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 have got an application which uses Java SE 5 and Hibernate 2.5. I have to upgrade / migrate it to Java 6 and a newer version of Hibernate. What is the best strategy?
Should I directly upgrade to the newest stable release (at the moment: 3.6), or does it make more sense to just upgrade to 3.0?
Is it a lot of effort to do such a migration?
I have no experience with Hibernate yet, but I already used Toplink JPA 1.0 in projects.
Can you give me some hints? Thank you...
Best regards,
Kai Wähner
Depends. If you'll use Java EE, then don't bother with Hibernate versions and focus on JPA 2.0. Hibernate will be just the implementation for the JPA. In case you really need some Hibernate specific feature, then check what's its version based on your AS implementation.
If you are not using Java EE, then I would go with Hibernate 3.6 if I'm planning to deploy my app in some months, or I would use 3.5 if I plan to deploy the app to production sometime next week.
The basic idea is: use the latest GA at the time you put something in production. This way, you ensure that you'll have a "supportable" version for a long time.
It's also worth mentioning that the Community versions are not always supported by the vendor. In this case, you won't get a support contract from Red Hat for Hibernate 3.5 or 3.6. If you need support, then you'll have to chose whatever versions they officially support.
I say go for the latest stable release as it will contain further improvements/bugfixes and give you more benefit overall. There have many changes since 2.5 so the migration will not be trivial, but later on, when you upgrade to subsequent versions, the migration steps will be smaller and easier.
Take a look at the migration guides to help you.
What is the best strategy?
It depends, if you have to maintain a lot of projects. Only do updates if you're working on a project. In other words it it isn't broken don't fix it. If you are still developing and you face problems in libraries then check more current versions which could have the bug already fixed.