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.
Related
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.
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'm maintaining a parent pom for my team which will provide the latest compatible version of various maven plugins per the JDK that the project uses. Sometimes if a project utilizes an older version of Java (like 1.5) maven will fail due to a plugin requiring a newer version. Is there a way to get a map of a given plugin and see what the minimum java version is for said plugin? I was thinking there was some sort of report or something that would show me that, but I'm not seeing anything.
What about: https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-prerequisites.html Apart from that on every plugin page you can find the goals page which contains the information you need. One more thing if you are using not the most uptodate versions all older versions pages are available where you can look at which version which JDK versions uses. It shouldn't be problem to write some kind of script to programmatically extract the information of the older plugins. The above site contains the informations of the uptodate plugins.
Apart from that plugin version selection basead on JDK version is not a good idea. The plugins have only a minimum version for JDK they need to run with. Apart from that they run on all versions (already on JDK 9 with one exception)...Furthermore plugins might require a minimum Maven version to run with which is either Maven 2.2.1 or Maven 3.0+ which shouldn't a problem.
You should define your plugins versions simply based on problems you might have but i would recommend to keep uptodate with your plugins.
If you need running you build with JDK 6 for example, but you use Maven 3.3.X which needs JDK 7 to run you can achieve this by using toolchain to handle this situation.
In theory this shouldn't be an issue. Maven will use the Java version you run it with, so the plugin's dependency will be satisfied, independent of the project's language level. Just make sure your devs are using a current version.
Example: running Maven with Java 8 will satisfy the dependency of a Plugin that requires Java 8, independent of the project's source and target level.
(With dependencies it's more complicated, I am afraid, but since you are not actually coding against your plugins, you should be fine)
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.