I am trying to understand about gradle-wrapper.jar in git version control. I found the purpose of it on this question Purpose of gradle wrapper.jar in my libraries.
As binary files are not good to store in git if they are changing a lot, I assume gradle-wrapper.jar does not change very often, is this correct?
This also lead me to the question when does it change and why, is it when we update gradle version?
Short answer: You never need to upgrade the Gradle wrapper, unless you need a specific bugfix or feature of the wrapper itself (which is fairly rare).
Longer answer: The Gradle wrapper is extremely stable, in a sense.
That doesn't mean that no new versions are released. In fact the Gradle wrapper is released with each Gradle release.
But an ancient Gradle wrapper is usually not a problem, which is even explicitly mentioned in the docs:
Note that running the wrapper task once will update gradle-wrapper.properties only, but leave the wrapper itself in gradle-wrapper.jar untouched. This is usually fine as new versions of Gradle can be run even with ancient wrapper files. If you nevertheless want all the wrapper files to be completely up-to-date, you’ll need to run the wrapper task a second time.
What this means is that the Gradle wrapper is almost universally forward and backwards compatible (you can download a newer or older Gradle version with a given wrapper).
The only times you must upgrade the wrapper is if there is a bugfix or a feature in the wrapper that you absolutely must have.
For example the Gradle 6.0 release had 2 changes to the Gradle wrapper:
Wrapper reports download progress as percentage
Wrapper tries to recover from an invalid Gradle installation
So if you really want that progress update or you frequently suffer from invalid Gradle installations then you might want to upgrade your Gradle Wrapper past that version.
But very often projects can go many, many Gradle upgrade cycles without ever touching the gradle-wrapper.jar.
And that is, of course, by design. The Gradle designers know that storing frequently-changing binary files in a VCS (especially git) is not a good idea, so they have designed the wrapper to be as stable as possible by making it basically just a simple downloader/launcher for the real Gradle code.
Related
For my project I want to use SymJava. The README there requires me to install the Java Operator Overloading support. Since I am using Intellij IDEA (Version 2019.1.2), I tried to follow the directive given. However, I am confused by the second step:
Add javac8-oo-plugin.jar as compile or processor library.
What is meant by "compile or processor library"?
Also a note: I did the first step before. This made Intellij IDEA ask me to restart the IDE. When I did that, a fatal error initializing the plugin occured when re-opening the IDE and my project:
What may be my misunderstanding in the process? I am using Java 15.0.1 here. Is that the problem perhaps, since it says something about using Java 8? I assumed it should work with later versions nevertheless.
Since I need to use this newer Java version, is it impossible for me to use SymJava then? And if so, can you recommend an alternative library similar to this (which is a Java counterpart to SymPy)?
Add javac8-oo-plugin.jar as compile or processor library.
Means that you need to add this jar to the module classpath by adding it as a module library. This will add it to compile classpath and to processor path if you have the Settings (Preferences on macOS) | Build, Execution, Deployment | Compiler | Annotation Processors | | Obtain processors from project classpath option enabled.
a fatal error initializing the plugin occured when re-opening the IDE and my project:
Double check the plugin zip archive file is not corrupted and is compatible with this IDE version. Btw I was unable to download it from github from the README instrucitons. You may need to better contact the repository author about this.
I finally came to the conclusion that SymJava is not suitable for any Java version above Java 8. This is, because SymJava uses the "java-oo" library. Since java-oo only supports Java 8, it's not possible to use SymJava, either.
The current solution is to use a different library, like Symja, which contains similar features while also supporting Java versions later than Java 8.
I have a few components and some projects using them. All the dependency management is done using maven. I'd like jenkins to check if code changes for a component would impact a project even if the project isn't using the newest version of it.
Let's say I have component foo, and projects bar and baz.
project_bar uses component_foo version 1.0.0
project_baz uses component_foo version 1.1.0-SNAPSHOT
While I'm changing component_foo version 2.0.0-SNAPSHOT so it can be used by project_baz I'd like to know if it could break project_bar build.
Being able to ignore a major version change (don't check compatibility if component_foo new version was 2.0.0-SNAPSHOT) would be a bonus but not required.
There is on magical way in Jenkins to do that.
This is something handled by compiling the projects with the new dependecy version. To ensure functionality is not broken you need to have unit tests and preferably possibly system tests for you projects.
Recently I was assigned to a task wherein I have to upgrade the existing standalone java application from Java 1.6 to Java 1.8.
I'm yet to go through the code and I have no idea about this project.
They were using
ANT 1.6.1,
AXIS 1.5.1,
ABINITIO 2.15,
ORACLE 11.1.0.7,
AUTOSYS R11,
Java 1.6.
I got to know that first I need to identify whether the above mentioned Tools/Frameworks are compatible with Java 1.8.
Please suggest what are the other challenges I might encounter while compiling and building the application?
Although Java is supposed to be backward compatible between versions, it's also known that backward compatibility in any language isn't aways as straight forward as the name suggests. Some (most) projects release it's libs versions compiled specifically targeting one or another development kit, to take advantage of new features and enhancements added to the language.
That being said, I believe the smarter way to go would be: first, update the project's JDK and rebuild it targeting the new bytecode's version. There's a chance you'll have to upgrade both Ant and (if that's your IDE of choice) Eclipse (see here why).
Second, you'll have to check for compilation errors, which will most likely lead you to update libraries conditionally to get them fixed. With those solved, you MUST run your app and see if it's running as intended; remember that compilation problems are just the top of the iceberg when the subject are dependencies.
Carefully check the app's logs looking for exceptions of any kind but mainly the ones related to class loading exceptions such as ClassCastException, ClassNotFoundException, NoClassDefFoundException, UnsatisfiedLinkError and others. If any apear, you'll have to pinpoint one by one and search for the specific solution of the specific troublemaker library.
With all that covered, you should have your app running healthily again.
One last hint, if this project of yours is still being developed, it would be a very good practice to keep the tools you use updated to their very last release. Keep also the development tools updated, like build (such as Ant, Maven, Gradle and others), JDK's and IDE's. It way easier to upgrade the pieces as they are release than to handle a mass scale upgrade :)
I have recently started using maven to build my Java application. As Maven downloads the dependent jar(s), is there a chance that the functionality can break when my (unmodified) code is built with a newer version of the jar which maven automatically downloads?
If it can, what is the workaround?
Yes, this can and will happen. Obviously you want to avoid 'code rot' where your code isn't updated to improved, newer, and supported APIs, however sometimes dependencies change their interfaces at inopportune times.
There are several plugins which provide more nuanced control over specific versions you depend upon. I would recommend you minimize your dependency on pinned versions so you regularly benefit from bug fixes and updates to your dependencies.
I found HTMLUnit is useful for me,but the files are too old.
So I use svn co https://htmlunit.svn.sourceforge.net/svnroot/htmlunit htmlunit to check the code,But I don't know how to use them.
Is there somebody can tell me how to compile them?
I see you have very little knowledge of Subversion.
I could link you to lots of verbose documentation, but let's make it quick and easy: what you downloaded is the whole repository, containing lots of redundant code, majorly the three canonical directories branches tags trunk.
In order to obtain usable code, you either download a stable (tag) version or unstable version (trunk). Advantage of trunk over tag is that it mostly contains new features, but tags are generally stable.
Try to get the following URL: https://htmlunit.svn.sourceforge.net/svnroot/htmlunit/tags/HtmlUnit-2.8/, then you could try ant to build (I'm no Java expert, does the package have an ant script?)
You don't need to take the detour of building it from sources yourself. The latest version is 2.8, and it's readily available from the Maven central repository. If you're not using a dependency manager, just grab the jar from here:
http://repo2.maven.org/maven2/net/sourceforge/htmlunit/htmlunit/2.8/
Check out the projects instructions on how to get and build the latest version !
http://htmlunit.sourceforge.net/gettingLatestCode.html.
It seems it ships as a collection of submodules, each with its own build system (some of them maven, some ant).
The latest release dates back to August 2010, doesn't seem to be that old, but if you're aware of improvements you need which are available only in later versions I suggest you look at their CI server, which provides already the artifacts from the latest build.