This is a very annoying and unhelpful bower error. "using 1.2.6 which resolved to 1.2.6"? What?...
I'm sure this is causing some issues with my code but I'm not sure why Bower is doing this.
Please note that,
angled-horizon, angular-animate#1.2.6, angular-cookies#1.2.6, angular-mocks#1.2.6, angular-resource#1.2.6, angular-route#1.2.6, angular-sanitize#1.2.6, angular-scenario#1.2.6 depends on angular#1.2.6 which resolved to angular#1.2.6
angular-bootstrap#0.10.0 depends on angular#>=1 which resolved to angular#1.2.16
angular-ui-utils#0.1.1 depends on angular#>= 1.0.2 which resolved to angular#1.2.16
angular-strap#2.0.1 depends on angular#~1.2.10 which resolved to angular#1.2.16
Resort to using angular#1.2.6 which resolved to angular#1.2.6
Code incompatibilities may occur.
The problem is that packages listed on the first line have in their bower.json's written "angular#1.2.6". Meaning they want this and only this version. Though the angular-strap package wants at least version 1.2.10, but accepts patches of it so v1.2.16 would be downloaded.
Bower decided to go with the lower dependency (represented by the string "angular#1.2.6" taken from the bower.json), that is to download v1.2.6 of Angular (shortened to "angular#1.2.6"). That should clarify the error message.
It would make sense to assume that the authors of the packages had a reason to require at least v1.2.10. My advice is to update packages from the first line if possible. If not, consider a pull request or downgrade the angular-strap package.
Related
In our .NET 6 apis we are using Simple Injector for dependency injection. With the latest version of Simple Injector, we observed that Snyk found five high-priority vulnerabilities and two medium vulnerabilities in
SimpleInjector.Integration.AspNetCore.Mvc v5.4.0. You can see one of them in the image below. All of them are probably caused by dependencies to an older version of the .NET Framework/runtime. Is it possible to provide a solution for these issues in the near future?
Is it possible to provide a solution for these issues in the near future?
If you look closely at the threat analysis, you'll notice that the issue not lies with the SimpleInjector.Integration.AspNetCore.Mvc package itself, but with the dependencies the package points at. It is, therefore, not an issue for the Simple Injector packages to fix, as all package authors would constantly have to upgrade their packages when there is a security flaw found in their dependency chain. The NuGet infrastructure is actually designed for these scenarios as a package lists its dependencies with the minimum compatible version. It's up to the application developer to select the most suitable version of those dependencies.
The solution is, therefore, straightforward: You, as an application developer should check whether the vulnerability affects your application, and if so (or when in doubt), act by updating the vulnerable dependencies in your application. If the vulnerable package isn't explicitly installed in your application, you should do so, and install a version that is not vulnerable.
Concretely, in your case the vulnerability lies in System.Net.Http, which means you should probably explicitly install that package in your application and upgrade to at least version 4.3.4, as this is the version that fixed the problem.
I know most projects have minimum versions defined in bower.json for a lot of libraries.
Something I don't understand is that would this be risky that if something updates and have break-changes or bugs, it will affect your application without you knowing it? What is the design thinking behind this?
Thanks!
We have just faced that exact issue on a project I am on, and the solution was to change our bower.json file to target fixed versions.
Specifically, we were targeting angularjs ^1.4.8. In AngularJS v1.6,
$location now uses '!' as the default hash-prefix for hash-bang URLs,
instead of the empty string
For better or for worse (mostly for worse) we had some hard-coded urls in a different application that pointed to this project that broke once bower automatically installed AngularJS 1.6 as part of our automated build process.
The solution was to simply lock down our versions rather than relying on the latest bug fix (i.e prefixing version numbers with ~) or minor build (i.e. prefixing version numbers with ^).
I think the reason that package managers like bower and npm default to dynamic versions is that they rely on semantic versioning, and in theory you should only encounter breaking changes when the major version number changes. Semver uses a major, minor, bugfix pattern. When the bugfix value is incremented it indicates that one or more backwards-compatible bugs have been resolved. When the minor version is incremented it indicates that new backwards-compatible functionality has been added. When the major version is incremented it indicates that new, breaking changes have been introduced.
The problem with this is that firstly, it relies on the package developer to respect the semver rules when they make changes to their packages, and secondly, even when semver is respected it can still lead to problems (as in the example I provided above).
Once upon a time I published my library "ScrollMagic" for bower.
For lack of knowledge and proper reading (shame on me) I did not adhere to the "lowercase only" naming convention.
With version 2.0.0 i changed that and now it's all lowercase.
How do I go about fixing that?
Removing "ScrollMagic" is likely to cause problems with people who already set it as a dependency.
But I can't publish as "scrollmagic" because it says the package already exists.
What do I do?
So I upgraded to 1.4 for a project I am contributing to (in development/testing branch of course) and ran into some problems and thus we want to use Dart 1.3.6 again. However, I cannot find this.
Does anyone know where I could download it?
I have seen and starred https://code.google.com/p/dart/issues/detail?id=18323
as I was putting this question together, but of course seems like there is no more movement there just yet.
I think I pretty much ran into similar issues to what corgath described in comments on this question... looking for the right version in those "archives" where the "latest" is not really the latest anymore.
Update
There is now a nice page to select and download specific Dart versions https://www.dartlang.org/tools/download-archive/
Since a while there are also deb packages available which can be installed using
sudo apt-get install dart=1.7.0-dev.0.1.*
see https://www.dartlang.org/tools/debian.html for more details.
Original
You can download from
http://gsdview.appspot.com/dart-archive/channels/stable/release/
The list only contains the build number but each folder contains a file VERSION that contains detailed version information for this build.
dev channel releases can be found here
http://gsdview.appspot.com/dart-archive/channels/dev/release/
there are also unsigned raw builds (bleeding edge) but it is not recommended to use them.
http://gsdview.appspot.com/dart-archive/channels/be/raw/release/
I've just inherited an application written in Grails (version 1.0.3) and would like to upgrade it to the newest release (version 1.3.5).
I can't seem to find a reference that enumerates the differences between the two versions. I know there is the "grails upgrade" command - but is this the best option given the large differences in versions.
I have a similar question that I asked today as well for upgrading the version of Groovy, and the sntactical differences to be aware of (between version 1.3.5 and 1.7.5) - but I thought it may be best to separate the two questions to focus on each.
Many thanks,
~Aki
Things have changed quite a bit since 1.0.3, and unfortunately grails upgrade isn't going to do much for you.
Two significant changes that come to mind are that there was a bug in 1.0.3 and previous where 1-many and many-to-many collections (hasMany/belongsTo) were supposed to be lazy-loaded but weren't. This was fixed in 1.0.4 and several users found that they were relying on the behavior and saw issues. Most people didn't, and just saw a significant performance boost. So watch out for lazy loading exceptions.
Another thing that changed is that plugins are no longer in the root of the project in the 'plugins' folder but are now stored under your $HOME/.grails folder. If you've checked the plugins into source control (and especially if you've made any changes) then you can revert to 1.0.x behavior by adding a property to BuildConfig.groovy (a new file that was introduced in 1.1):
grails.project.plugins.dir = 'plugins'
I described my process for upgrading plugins and apps here: How to install Grails plugin from source code? - it's about a plugin project but the same goes for app upgrades.
The log4j configuration changed from one that's properties-based to a DSL. This means that if you leep your config settings from Config.groovy the log4j behavior will be the default, so you'll need to convert that.
Another change that isn't required but should be considered is that Ivy jar file resolution from Maven repos is now preferred over putting jar files in the lib directory. You can still put them in the lib dir, but it's more DRY to have Ivy download them once.
You'll probably also find that some of the plugins you have don't work in 1.3, so there might be some migration work there.
There are two recent books that cover Grails 1.2/1.3, "Grails: A Quick-Start Guide": http://www.amazon.com/dp/1934356468/ and "Getting Started with Grails, 2nd ed": http://www.infoq.com/minibooks/grails-getting-started - you should probably check those out since they're the most current Grails books.
Overall it shouldn't be that bad, as long as you don't try to upgrade in-place. Use the approach I described in the other post I referenced, i.e. create empty apps and diff files to see what changed (basically a 3-way diff).
The newest release is 1.3.6 (as of Dec 15). You can get a list of changes from the Release Notes of each release. Also, the upgrading from previous versions link the documentation is a good source of changes.