I want to upgrade an app which was built with jhipster 4.14.4 to 7.9.2 the latest version right now.
Do you have any ideas how should I proceed ? (the steps to follow)(the best way to do it)
I already read this : https://www.jhipster.tech/upgrading-an-application/ but i am still confused.
I already tried with the automatic upgrade which ended with a lot of conflict to solve. I don't know if i should continue in that direction or change my strategy. Because some other developers told me to create another project with 7.9.2 and copy the old code step by step and then resolve problems.
thanks.
Before asking how to upgrade, the first question to ask is why?
What are the benefits you expect from upgrading JHipster versus upgrading your app manually to make it run under latest versions of Java and Spring Boot and other libs?
Usually when you want to upgrade an application, it's to get support for patching security vulnerabilities or to be able to use more modern libs before starting a major functional evolution.
You can get all these benefits by updating manually your code at a fraction of cost especially when your app is several major versions behind JHipster.
Unless your project is trivial, its value reside in your custom code not in code generated by JHipster.
So, it usually does not make sense to keep a dependency with the code generator, it just adds technical debt when you are unlikely to use it anymore.
In my projects, I usually cut off all dependencies with JHipster after few months, it makes it so much easier to upgrade libs and frameworks.
As an analogy, you would not keep scaffolding after your house is built.
That said, if you still want to do it, there are 2 alternatives:
Using jhipster upgrade
In your case the effort is multiplied by 3 because your app is 3 major versions behind current JHipster.
Each major version introduces its share of breaking changes including dropping some components. So in some rare cases you just couldn't upgrade depending on the options you chose for initial project generation.
So, first step is to review the breaking changes introduced by each major release, see https://www.jhipster.tech/releases/
jhipster upgrade will likely fail if you want to go directly from 4 to 7 so you should probably go from 4 to 5, 5 to 6, 6 to 7. It will take long time and effort and there's a risk that you will fail.
Starting from fresh project and importing custom code
Generating a new app in 7 and then importing your custom business code is probably a better idea.
If you have kept the JDL file used for initial generation then it's easy.
If you don't have this JDL file or app was built by answering questions, you can use jhipster export-jdl.
So now you have the JDL and you can create your app in an empty directory, and generate your app with latest version using jhipster import-jdl.
Then you should start importing custom code into new app.
Whichever way you choose, you must be knowledgeable about the technology stack used by JHipster. So to be clear: giving this task to a junior dev does not make any sense.
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 currently use the Play framework using Java (actually the 1.x series) and by far the best part of using Play, what makes it hugely productive is it's inherent, transparent, comprehensive, quick, seamless 'hot reload' capability. I simply could not return to doing Java development where I don't have this.
I do however have issues with Play in general including, but not limited to, the general lack of emphasis on Java as opposed to Scala development on the platform.
So doing a bit of research on current alternatives (I previously used to do Spring J2EE development) I stumbled across JHipster which on the surface looks promising.
So can people tell me the options of using JHipster with an 'easy' hot reload setup. Are we talking about using JRebel (which is expensive) or are there other alternatives? Is it straightforward to setup and does it work consistency? Anyone who has experience of this, I would be grateful for their comments.
JHipster gives you 2 types of "hot reload" features. They are both free and Open Source, and work consistently. I know lots of people (including me) using them daily.
The Spring Boot devtools allow you to have hot reload of your Java code. This is quite close to what Play! or JRebel provide. It has also been improved by JHipster to include database updates using Liquibase, something that JRebel or Play do not provide.
BrowserSync, which gives you hot reload of your front end (AngularJS) code. This is a very different focus: this means your Web browser gets automatically refreshed when code is changed.
It is the consistent usage of both those "hot reload" features that makes JHipster powerful. I often generate big parts of my application, and I have the database, Java code, and browser all refreshed automatically on-the-fly.
I'm in the same corner than you, looking for something better than play one in the java space, it has not been an easy task, we continue using play 1.4.1.
But going to your question, like you, we finally get to Spring Boot and to JHipster; Mat Raible presentation in Devoxx is very convincing.
For hot reload of Thymeleaf Templates, it's neccesary to add next two lines in application.properties:
spring.thymeleaf.cache=false
spring.thymeleaf.mode=LEGACYHTML5
Hot Reload Java
To have hot reloading in spring boot it's necessary to use the spring loaded project, download it and and let it somewhere in your disk.
To activate spring loaded, at least in Spring Tool Suite (eclipse) you need to add the jar as an agent in section VM Arguments of run configuration:
-Djava.security.egd=file:/dev/./urandom -javaagent:/home/hans/Descargas/springloaded-1.2.5.RELEASE.jar -noverify
It's not as cool as play one, it's necessary to restart the server from time to time, but it works.
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.
We have a web application that is implemented in Java. It uses Maven to install various dependencies such as JavaMail, Gson, and so on.
Unfortunately, deploying and maintaining the project is a nuisance. We need to be aware that any of those dependencies might issue a security update, which means checking regularly for new versions. To make matters worse, we can't see any way that Maven can distinguish security fixes from other new releases. This means that we end up doing needless updates, which is a waste of time and could break something.
The server itself runs Ubuntu, and the situation there is far better. Apt installs urgent updates, but everything else waits until the next Ubuntu release. That's ideal because it gives us a stable but secure platform that we can build on.
Is there any way of making Maven more like Apt, so we can install security fixes but nothing else? If not, I'd be interested to know what strategies other people use for updating deployed web applications.
(We know about the maven-dependency-plugin. This plugin helps, because it can automatically find and update any dependencies which have newer versions. Unfortunately it can't distinguish security updates from normal feature releases, so we end up updating when we don't strictly need to.)
I did come up with a partial solution to this problem, but it doesn't use Maven directly. I implemented a script which scans the NVD database for new security exposures relating to products we are using. Every morning I get any new ones emailed to me, and I can decide whether they justify an update to our web application.
The downside of this approach is that smaller projects don't always issue CVE numbers for their vulnerabilities. We have to restrict ourselves to products that have a significant following, are backed by a large vendor, or have previously demonstrated a willingness to take part in the CVE process.
Context
Basically, I have a library that is used in several applications running on java 6, java 7 and now java 8.
The library also has a dependency on a creepy (yet very useful) third party library (which I won't name) - a library that doesn't care a lot about forward-compatibility. The aforementioned applications also make heavy use of this third party library but are not always able to update to the latest version. I'm used to it, so I have a lot of "if" in my code dealing with silly things.
Problem
Today I stumbled upon an annoying problem: some method in the third party library has a different behavior when running in java 7 and earlier than when running in java 8 and later.
My unit tests were designed to cover this part of my code and would have spotted the bug if they were run with the correct java / library combination.
Question 1
How can I integrate nicely in the maven build lifecycle and run my tests sequentially with java 6, java 7 and java 8? (which implies failing if any test fails with any jvm)
Question 2
Same as above but adding another sequential run with each "supported" version of the third party library ?
(which means, to be clear, that, if I "support" version 6.11, 6.12, 6.13 and 6.14 of this lib with all 3 java versions, I will run 4*3=12 times my unit tests)
i have similar problem. i created a library that should be tested against different versions (all available in maven central) of other library and (but that's less important) jvm.
my conclusions: doing this only in maven will be veeeery cumbersome and hard, if not impossible. you will also have to encode environment/system dependencies into your build tool
as suggested, most integration servers support matrix tests. you can use it also to manually provide every single version (if you know them upfront) of library you need to test against. the library part should be doable much easier in gradle (but still no out-of-the-box support).
regarding number of tests: yes will have to run x * y times. if your code is big think about isolating the part that uses other library and run only this small part x times for each jvm - it will be a bit faster. also you can run those tests in parallel
ps: i'm thinking about writing a gradle plugin or at least a proof-of-concept build. but i don't think it will be soon. but i'm open for other contributors :)