Noticed that there is a 2.0 version of the Spring IO Platform available as a snapshot. I am looking to understand what might be driving the major version number change. Can someone with better insight into the changes share the themes here (or point to somewhere where this is better documented)?
Look at the "Upgrading" section of the documentation: http://docs.spring.io/platform/docs/2.0.0.BUILD-SNAPSHOT/reference/htmlsingle/#upgrading-removal
Some dependencies were removed, which leads to a major version, since it's a breaking change.
Related
I'm working with a Grails application version 2.2.4 and I need a procedure for upgrade to latest version (I hope it can be possible). I have thought as a first step to follow the indications of the official site, but that let me to upgrade to version 3.
I'd like to know if anyone already did it or have experience about that. How long take it?, the process and the main problems.
Many thanks in advance.
I think you need to follow both upgrade instructions. the one for 3.x and the 4.x.
start with the 3.x and them move to the 4.x changes.
Another approach I think may be better is to start an empty 4.x application and then start moving you code there. also check first that all the plugins that you are you sing have 3+ version.
The effort required to upgrade can change massively depending on multiple factors, including the size of the project, the quality of the original code, were plugins used and if so have they been updated or will the functionality need replacing, were deprecated taglibs used, e.g remoteFunction etc. etc.
There is not a great deal of difference between 3.x and 4.x so it makes sense to upgrade to 4.x.
Tackle it in stages from the basis of a new project, attempting to rebuild the project between stages.
Reestablish configuration, you don't have to use application.yaml (the default in 4.x) so can create an application.groovy with the same parameters as per your old project.
Move over domain objects but use a new database URL, compare the schema's between the old db and new db to ensure the database is the same. Unless you don't rely on GORM to recreate/update the schema.
Move over any other source and command objects ensuring the project will build. You may need to modify buildconfig at this stage to bring in dependencies and plugins.
Move over services, ensure all compiles and make sure transactions are behaving as intending.
Move over controllers ensuring any tests run successfully.
Move over the views.
Hopefully if the project is still building at this stage, you can run it!
We are evaluating reactor library for using it in our project. Our project was backed by spring context. So we needed a tool to build event-driven application which has the spring support.
Also our main area of focus was on ability to composing sequence of asynchronous events (Streams & Promises). In certain other use cases we might be in need of publisher/subscriber model or running long running processes asynchronously.
As I was evaluating, I noticed some of the following the latest released reactor-spring version is v1.1.3 with dependency on reactor-v1.1.3 which we could use.
But I also noticed the there’s reactor-v.2.0.0 (under development) which had quite a bit of changes especially in the area of Streams and Promises.
Please suggest me if it is a good idea for going with reactor-v1.1.3 with spring support or should we wait for reactor-v2.0 if we have to use more of Streams and Promises.
If we go ahead with reactor-v1.1.3.RELEASE how much code changes might be needed to get ourselves upgraded to v2.0.0.
I also wanted to check if we have any branch of ‘reactor samples’ for reactor-v1.1.3/v1.1.4. As of now I could see only one master branch available which has been updated to use reactor-v2.0.
Do we have the reactor API for latest release v1.1.4. Currently the API (https://reactor.github.io/docs/api/) points to Reactor 1.1.0 Release.
Where can I find the reactor-core-2.0.0 codebase? I am finding difficult to locate.
As I am new to this library, please feel free to correct me if any of my mentioned points/questions were incorrect. Thanks.
If you're starting new development, definitely go with Reactor 2.0. It's mainly the substantial improvements in the Stream and Promise APIs which resulted in having to bump the major version number. Differences in the rest of the codebase are pretty minimal. Converting between 1.1 code and 2.0 code requires some package renaming and a few tweaks here and there (like eliminating the use of the Deferred object in Stream 1.1).
The other major change that justifies a major point release bump is the implementation of the Reactive Streams specification. It's out of the scope of this question to discuss it further but it is an important part of Reactor moving forward. Being able to natively integrate with Akka Streams, Ratpack, RxJava, and other libraries that already (or will shortly) implement Reactive Streams is a huge benefit to Reactor 2.0.
The reactive-streams branch contains the code for Reactor 2.0. M1 is coming shortly and we'll start the process of updating the samples, though as you've noticed, some components like Spring support have already had to be bumped to Reactor 2.0 since they're relied on in some major almost-production applications.
Let's suppose I have a project called myLib-1.1.0. This project has a dependency on lib-dependency-1.2.3.
If there's a new version for this dependency and I need to use it, should I change my project version as well? No other modifications are made to myLib.
At the same time myLib is a dependency for various other projects. My main concern is the impact of a small change in a dependency might have upstream.
Yes. In maven, released versions are immutable. If you release 1.1.0 with a dependency to lib-dependency-1.2.3 then that's it.
If you change to depend on lib-dependency-1.2.4 then that's a new version. You should not redeploy 1.1.0 since some people might have already pulled that (supposedly immutable) 1.1.0.
So that means you need a different version, even if it's a just a new qualifier (myLib-1.1.0-RC-2 for example, but better just 1.1.1)
Maven doesn't recheck remote repos for release versions once it has it in the local repo, so if someone has 1.1.0 already locally, they will not get the new, fixed 1.1.0.
And about your rippling problem. Upstream projects should depend on the lowest acceptable released version. i.e. if the upstream project itself is ok with myLib-1.1.0 because it doesn't need (indirectly) lib-dependency-1.2.4 then it should stay with 1.1.0
Any code change that potentially affects the behavior should be given a new version number, in other words: anything that's not an absolute trivial change should be given a new version number. A changed dependency would definitely qualify for that because, unless you do a thorough code inspection of the dependency, you have no reason to assume that they only made absolute trivial changes.
Changes are often advertised as "small" (similar to being absolutely trivial as I call it above), but they hardly ever are. They may be negligible in someone's use case, but not in someone else's use case. I've even seen circumstances where there were only changes to Javadocs in a project that would break things down the line. (You could argue about how smart it is for someone to depend that strongly on Javadoc, but that's besides the point, isn't it?)
That is not to say that you can't accumulate changes and release a bunch of them as a single release. While accumulating, your project is in flux, and should have a ...-SNAPSHOT version. There should be no two versions of myLib-1.1.0 (without the -SNAPSHOT) that have even the least little change.
The fact that you're re-releasing your project also makes explicit the fact that regression testing and such should be redone to validate that it's still working with the changes in its dependency.
I've been trying to build the 3.2.2 and 3.2.3 tags of WSO2 Carbon from here using Maven 2:
https://wso2.org/repos/wso2/tags/carbon/3.2.2
https://wso2.org/repos/wso2/tags/carbon/3.2.3
However, the Maven pom.xml files throughout the directory trees beneath these tags still refer to version 3.2.0 in both cases - am I missing something obvious please?
When I try and analyse the results of both the builds using our in-house tool I get identical results in the two cases (and indeed results that are identical to those for 3.2.0), which makes me think I may be building 3.2.0 repeatedly by accident.
3.2.2 and 3.2.3 are point releases and typically involves bug fixes/optimizations that do not introduce new features to the 3.2.0 release. If a particular component do not have any fixes/changes, the version still be the older version, no new version is introduced. This is how the versions are handled.
You're not missing anything. It seems they did screw up. Maybe that was their intention, but then it doesn't make any sense at all (at least for me).
I am trying to justify an upgrade of Grails from 1.0 to 1.3 and am wondering if I can add speed to the benefits. Does anyone have any empirical data on the subject?
It depends on a lot of things of course, and you haven't shared many details of your application. If you're using 1.0.3 or earlier, the default was to eagerly load collections and this bug was fixed in 1.0.4, so upgrading to 1.3 will certainly be faster when working with collections that you expect to be lazy-loaded. There have also been significant performance increases in GSP rendering in 1.1, 1.2, and 1.3. In addition GSPs are now precompiled when building a war file, so deployed applications use a lot less permgen.
Groovy has also gotten a lot faster from the 1.5.x that was used in 1.0 to the 1.7.8 that's used in 1.3.7.
There are other non-performance-related reasons to upgrade too. These include access to newer features that didn't exist in 1.0, plugins that won't work in older versions, and better IDE support.
That's a big jump and I don't for sure how much performance benefit you will see but it's certainty a lot. However, you should consider other advantages for the upgrade -- bug fixes, new features, easier gorm query, able to use latest plugins, etc.
FYI: We did upgrade from 1.* to 1.3, and it's requires some code change. Not a lot but take it as opportunity to clean and cut down on code count.