When you use maven, ivy2, or sbt to manage your package dependencies, there are plenty of techniques to let you see which packages versions depend on other package versions and to see which ones evict others.
For example, one useful tool to view existing dependencies when using sbt and scala is sbt-dependency-graph
But when you are looking to upgrade to newer packages, how can you find a combination that will work?
Are there tools to search for those combinations?
Are there systematic and, hopefully, efficient manual ways to search?
When using sbt and scala, this gets even harder because the compiler version is often part of the package identifier.
Please let us know your tips for moving to new newer package versions.
I'll admit that I'm not sure if it ensures all the versions are compatible but sbt-updates will tell you which dot, minor, and major version upgrades are available for your dependencies.
Related
According to a recent JFrog Xray scan, our application (.NET 5) has a "critical" vulnerability due to a dependency on a specific version of Microsoft.NETCore.Platforms. There is a newer version of the package with the vulnerability resolved that I want my project to use instead. The problem I'm having is that this is not a package that we've explicitly added to the project, but rather a dependency that some other packages have, so simply adding the newer version of the package to the project isn't enough to remove the dependency entirely; I can still see references to the "bad" version appearing in project.assets.json. Upgrading to the latest version of the top-level packages has helped, but has still left some references to the "bad" version of Microsoft.NETCore.Platforms via dependencies of dependencies of dependencies.
E.g, we're using the very latest version of Microsoft.ApplicationInsights, but this has a dependency on System.Diagnostics.PerformanceCounter, which has a dependency on the "bad" Microsoft.NETCore.Platforms.
TLDR; I want to be able to tell my project "If you have a dependency on this package anywhere in your dependency tree, don't use version X, use version Y instead", but I'm not sure if there exists a way to do this.
You can't change what version of a library your dependencies use because that could easily introduce breaking changes. This is the modern version of DLL hell.
The answer is to update the library that has the old dependency. If it's open source, you can do this yourself and use your forked version with the updated dependencies. If you don't have access to the source then you will have to contact the developer and tell them about the vulnerability.
If the developer is Microsoft, godspeed.
I wonder how to version plugins.
There are plenty ways of versioning a software products but they're all 1-dimensional.
Are there best practices for 2-dimensional versioning which indicates both compatibility to the main application and compatibility to the plugin API?
Eclipse for example proposed a versioning scheme for which every plugin uses semantic versioning. Additionally there's a rule to distinguish between development streams by increasing the service number by 100. This ends in versions like that:
Plugin version v1.0.8 for Eclipse v3.1
Plugin version v1.0.108 for Eclipse v3.2
This seems a bit fishy to me. Are there better ways?
Why do you need to show the information about main application version in version of plugin? Does it help users to choose a suitable one?
I prefer put this information in a plugin name. For example, plugin-eclipse31-1.0.8 and plugin-eclipse32-1.0.8. You can put branch name (eclipse31 or eclipse32 in examples) in plugin version, to make things easier.
I'm suffering from the version conflict on Eclipse.
I want to use the following two plugins in one Eclipse instance.
org.abc.plugin1a
has a dependency on org.eclipse.plugin1b_1.0.0
(works well only with version 1.0.0, not work with the newer version!)
impossible to be maintained because of a certain reason
org.eclipse.plugin2a
has a dependency on org.eclipse.plugin1b_2.0.0 (or newer)
Actually org.abc.plugin1a was developed experimentally by an ex-employee, not by me. The source codes are available but too complicated.
I found there are huge differences between org.eclipse.plugin1b_1.0.0 and 2.0.0.
So it is almost impossible for me to update org.abc.plugin1a to work with org.eclipse.plugin1b_2.0.0
Is there any answer to solve my problem?
Specify both the minimum and maximum version of the plugin in the Require-Bundle:
Require-Bundle: org.eclipse.plugin1b_1.0.0;bundle-version="[1.0.0,1.0.0]"
This will not work if plugin org.eclipse.plugin1b is marked as a singleton since in that case Eclipse will only load one version of the plugin.
I just finished the awesome Coursera Scala course and am eager to continue learning more about Scala by exploring some existing open source projects. I've hit a snag while trying to get some of them running locally, though.
I come from a background in Ruby, where we use tools such as rvm or rbenv to manage multiple Ruby interpreters/versions on one system. What is the approach that Scala users take for working with projects that use different versions of Scala/SBT?
I suspect that I'm missing something big since this doesn't seem to be a popular issue.
Please note that I'm pretty new to the world of Java and the JVM in general.
I suggest you take a look at paulp's excellent sbt-extras script. This will enable you to pick which version of sbt you want to use on a per-project basis, and sbt will allow you to pick which version(s) of Scala you want on a per-project basis.
I always use the latest sbt from Homebrew (OS X) and then control the Scala version and libraries from within the build.sbt.
More recently (Dec. 2016), you can try and check out sdkman.io, The Software Development Kit Manager.
It is a tool for managing parallel versions of multiple Software Development Kits on most Unix based systems. It provides a convenient Command Line Interface (CLI) and API for installing, switching, removing and listing Candidates.
It installs Software Development Kits for the JVM such as Java, Groovy, Scala, Kotlin and Ceylon. Activator, Ant, Gradle, Grails, Maven, SBT, Spring Boot, Vert.x and many others also supported.
I've recently learned that the import section from feature.xml is legacy, and the actual dependency work is delegated to the p2 engine, which uses the information from the plugin manifest.
I am not sure though if p2 is available for all recent versions of Eclipse, or in all Eclipse-based products, so I'm not sure if it is safe to remove the import section from feature.xml.
Under what circumstances is it safe to remove the import section from feature.xml? Assume that we are taking into consideration Eclipse 3.4 or newer.
P2 was introduced in Eclipse 3.4 release. It had quite a few issues in that release, so a way was given to revert your Eclipse install to using the legacy Update Manager. Starting with 3.5 release, p2 is quite stable and is a definite improvement over the old Update Manager. I am not certain if it is possible to revert to the Update Manager in 3.5 or higher release. I certainly haven't heard of anyone doing this.
P2 is present in all Eclipse packages starting with 3.4 release.
I wouldn't categorize feature import as a deprecated feature. You would still want to use it to pull in plugins when you don't have direct OSGi dependency on them.
Consider the case where you are building an extension to JDT. Say you only depend on JDT core api (no UI extensions). If you only rely on OSGi dependencies, when your plugin is installed, p2 will dutifully install JDT core bundle, but not the UI bundle. Perfectly fine from OSGi perspective, but probably not what you intended.
I recommend sticking with feature import to describe your high level dependencies to make sure that they are installed in full. Relying only on OSGi dependencies works best for free-floating bundles that aren't part of something bigger that should be installed as a unit.