I'm trying to use a third party commercial JS library in my angular-meteor project
The vendor just informed me, that they only support angular version 1.3.11
Is there a way to install urigu:angular-meteor with this specific version of angular?
According to the meteor documentation you can set a version using #= so it should be like that:
meteor add angularjs:angular#=1.3.11
However, doing so you might have versions conflict like that:
>meteor add angularjs:angular#=1.3.11
=> Errors while adding packages:
While selecting package versions:
error: Potentially incompatible change required to top-level dependency: urigo:angular 0.6.8, was 0.8.4.
Constraints on package "urigo:angular":
To allow potentially incompatible changes to top-level dependencies, you must pass --allow-incompatible-update on the command line.
So you have here few alternatives:
Downgrade urigo:angular: I think this is not a good option, there might be major changes since the package is pretty new.
Convince the vendor to "take the risk"
Since angular is much more mature that angular-meteor and 1.3.11 to 1.3.15 should not have breaking changes, this option have a clear advantage.
If you do wish to use the first option, add --allow-incompatible-update to the command line.
Related
I want to change one of my library to the latest version. where to find the version of the dependency in play.
In general, you can see a list of Play's direct dependencies by checking the project/Dependencies.scala file in the source code for that version of Play. For version 2.4.3, that file is here: https://github.com/playframework/playframework/blob/2.4.3/framework/project/Dependencies.scala
In the specific case of Jackson, the group ID and module structure changed between Jackson 1.x and 2.x. Play 2.4.3 is using Jackson 2.5.4. If your project depends on Jackson 1.8.5, this dependency isn't coming from Play, but from some other source.
You can use the sbt-dependency-graph plugin to view the full tree of transitive dependencies and see where it is introduced.
To update to a newer version, you can add a direct dependency to your build.sbt with the desired version:
libraryDependencies += "org.codehaus.jackson" % "jackson-mapper-asl" % "1.9.13"
This will override the version requested by other libraries; by default, sbt will use the greatest version requested.
However, there are a few things to keep in mind:
Jackson is composed of several sub-modules. If you are using several of these in the same project, including transitively, it's a good idea to use the same version of all of them. This might require adding additional dependencies to your project to keep them all in sync.
When upgrading dependencies in your application that are also used by other libraries it depends on, you'll need to consider backward compatibility. Jackson is not always fully backward compatible between minor versions, so if you update to a newer version of Jackson than what your libraries were designed to use, you might encounter problems at runtime.
Using both Jackson 1.x and 2.x in the same project is possible, since they have different group IDs and Java package names, but it may be confusing and error prone. If you can, it would be better to standardise on the Jackson version that is used by the Play Framework version you choose.
I've been working to get NuGet versioning squared away in my ASP Core project and have come across some odd behaviors and would like to ask why they decided to do it this way.
1) Choose the lowest version in a range.
ex: [1.0.0, 2.0.0) Does not mean choose the most recentversion in 1.X.X but choose the lowest version, basically always 1.0.0 and never update.
2) Setting the specific version chooses a different version
ex: "1.0.0" will really select "1.0.X".
This one really concerns me. I want to make sure that when I tag code, using a specific version, all future builds will always use the same version. With this implementation, builds are not guaranteed to be reproducible!
I'm coming from using Maven and NPM and am trying to keep an open mind to other ways of doing versioning, but these two baffle me.
Please help me understand why they would do this, basically backwards from other package manager solutions.
You can use a floating version if you want the most recent version, ex 1.0.*.
I think you're incorrect here. If 1.0.0 is requested, it'll install 1.0.0 if 1.0.0 is available on the NuGet server. If it's not found on the server, it'll install the next closest version found, 1.0.1.
This is pretty well documented at
http://docs.nuget.org/consume/ProjectJson-Dependency#dependency-resolution-in-nuget-v3-/-project.json
I recently downloaded a new symfony2 package for websockets and included it into my composer file,
when I called
php composer.phar update
It automatically updated my Symfony version and I was wondering if updating Symfony2 will break the website in the long run, since part of my source code could become obsolete (deprecated)
Yes, if composer downloads a version of a dependency that's not backward compatible with the version that you used to develop your website, things might/will break.
However, you can limit the possibility by defining good rules in your composer.json.
First of all, it might be good to learn about semantic versioning if you haven't heard of it already. Many projects are following the rules of semantic versioning, which basically state that if a project/library has changed in a way that is not compatible with earlier versions, it's main version number should be incremented. For instance, if 1.5.x had a certain feature, and an update is made where that feature is changed or no longer available, the new version number should be 2.0.x instead of 1.6.x.
Knowing this, you can use Composer's tilde operator (~) to define useful version constraints. For instance, to add the dependency to symfony's files, you can add the following requirement to your composer.json:
"symfony/symfony": "~2.3"
which is equivalent to:
"symfony/symfony": ">=2.3,<3.0"
or, in plain English: 'give me a version of symfony/symfony, at least version 2.3 or higher, but lower than 3.0'. If Symfony follows semantic versioning correctly, no backward incompatible changes should be made in any 2.x versions (and, if any backward incompatible changes are made, they should come with version 3.0), so you should be fine.
This actually depends on how your composer.json is configured. If your dependencies use SemVer, and you are referencing them in your composer.json only allowing patch version changes (like "package-name": "1.1.x"), then everything should usually be fine.
Also, note that you can pass a package name as a parameter to the composer update command, e.g. php composer.phar update <vendor/dependency-name>. This will tell Composer to only check if there are updates available to <dependency-name> package, given your current composer.json version constraints.
If you want to check that nothing is broken after an update and you're not keeping the update scope as narrow as I specified, then something could break. The best way to detect and avoid this is by testing.
You should read about composer.lock file. This will make sure that Composer will not update any version of the repository and only what you specify in the lock file
I have an sbt project in which the build is normally invoked via package-tar. If a developer types package, it's very likely that they actually meant package-tar instead.
However, package-tar depends on package. How can I prevent or deter or warn when a developer seems to be making this mistake - since I can't actually disable the package task because it's necessary?
I considered integrating actual deployment into the build, but this is not compatible with our current deployment process.
Instead of making package-tar a separate task, how about just redefining package to do what you want? The new behavior can invoke the old behavior.
http://www.scala-sbt.org/0.13.0/docs/Detailed-Topics/Artifacts.html has examples of customizing what package does. The material on addArtifact looks relevant.
I have a an sbt multiproject (sbt 0.11.3) where one of the sub-projects is a PlayProject using play sbt-plugin 2.0.1) and another is my application logic. My application needs to use 0.4.1 version of com.typesafe.Config but I believe the play plugin seems to embed an older version 0.2.1 which causes a conflict when I perform a dist (create a jar) where one of the new methods does not exist in 0.2.1.
I want to know if there is a way I can exclude the old version and only have the new one. I have tired many methods without success (excludes, filtration[If I did that properly at all], etc..)
Thanks in advance to the wizard who either can tell me explicitly how to make this happen, or the chap that tells me it isn't going to happen and why.
Answer:
There was not a good way. The only way was to open the jar remove the config classes in akka and repackage. This was not going to work for us, so I used the older version of the config.