We are currently moving some of our inner libraries into a nx monorepo.
Those libraries are publishable.
What can we use to bump our libraries versions?
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'm attempting to utilize the "Project References" feature in Eclipse for an embedded firmware project. I'm using Code Composer Studio 7.0 which is essentially just a wrapper for Eclipse 4.6 with CDT 9.0 and JRE 8. However, from what I can tell the features I'm trying to use are specific to the CDT. The embedded firmware is broken up into several parts with a few libraries, an RTOS platform, and the "core" firmware.
The intention is that the dependencies of a project are automatically built and updated in the proper order whenever a build on the core firmware project is triggered. However, due to some libraries building upon others I'm seeing some weird behavior that i don't quite understand. The dependency graph is shown below.
As you can see, there's a maximum of four levels of dependency. The issue that I'm seeing is that, while I've ordered the references in the order "Properties->C/C++ General->Paths and Symbols->References" as [Platform, PAL, HAL, Features] for the firmware project, the build order doesn't seem to follow that specification. The ordering seems to be semi-random. After a clean sometimes the PAL will build first, other times the Features will. The entire build ultimately fails when this happens due to dependencies not being accessible. Is there an additional step I'm missing to get dependencies to build in the correct order, or are nested dependencies not supported by Eclipse for some reason?
I want to build my CocoaPods libraries into single library (or even multiple will also be OK) in order to:
Freeze pod libraries versions
Reduce build server build time (building libraries takes a lot of time)
Is there a way to build CocoaPods libraries into 1 or several static libraries and link them to my project?
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.
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.