I am just bumping our 3rd party packages to the latest versions for various vulnerability fixes.
There has been some major changes it seems from awspring 2.4.2 -> 3.0.0.M*, notably quite a few classes have been removed. One of them being ResourceIdResolver.
See - https://github.com/awspring/spring-cloud-aws/pull/252/files
I can't find any release docs advising of the above class removal and no help as to how to refactor your code to get around the fact this class is no more.
I notice that package io.awspring.cloud.messaging is still at 2.4.2 and class QueueMessagingTemplate is referencing io.awspring.cloud.core.env.ResourceIdResolver (which no longer exists in io.awspring.cloud.core 3.0.0.M2.
Is there some compatibility issue here?
Many thanks
I added a single method definition in a interface and I am getting a baseline error with a suggestion asking me for a major version change. I want to ask how does it calculate whether a major or minor change is required? adding one line method declaration shouldn't be a major change, right?
Is there a way to tell it to ignore this particular method declaration?
A new method in an interface means that none of the current implementors are compatible with this version of the interface. Before they become compatible again they will have to implement the new method, thus the version bump is justified. Don't game around it, combine it with more changes or just accept that the bundle version of volatile bundles increases quicker than your version stamp on the fully packaged software.
There's nothing bad to version bumps
I want to know the loss for my w2v model and I upgrade gensim to the latest version, but still can't use the argument compute_loss, am I miss something??
No released version of gensim (through 2.2.0 of June 2017) yet has that feature. It is a work-in-progress in the develop branch, which should appear in a future release.
I am studying how to create plugins, however the plugin I chose is not compatible with version 3.0 of NativeScript, on that I am trying to migrate it to this new version.
At the moment I'm having a hard time finding which class I should use to replace it, how to do it.
NativeScript's documentation at this point is very precarious and leaves much to be desired, or I'm not finding the right place to study.
How do I make the replacement of the Propertymetadata class with its new replacement in NativeScript 3.0?
And what is the right class for such a replacement?
Updating:
I re-read and extended the reading for the following articles, but none of them delves into the functionalities and proper use of such classes and their dependencies and dependents.
https://docs.nativescript.org/plugins/ui-plugin
http://docs.nativescript.org/core-concepts/data-binding
http://docs.nativescript.org/core-concepts/properties
github.com/NativeScript/NativeScript/wiki/…
I'm terribly sorry if this had been asked before, I've tried searching for something that answers my questions but could find none.
The issue is this:
Let's say I have a string that looks like this -> 2017-01-05-04:44:43-06:00 (format being yyyy-MM-dd-hh:mm:ss+/-UTC)
Now my goal is to store it as it is in the Oracle database including the offset (as I understand I need to define the column as TIMESTAMP WITH TIME ZONE).
So how do I go about capturing the timestamp with the offset into a Java date and time object? I'm not looking to convert the times to UTC, I just want to store it as is and persist that into DB.
Please note that we are on Java 6 so I cannot use java.time package, neither can I use Joda Time. So any solution outside of these would be really appreciated.
Thanks.
java.time
See the ThreeTen-Backport project for a back-port of much of the java.time functionality to Java 6 and 7 (java.time is built into Java 8 and later). The API nearly matches so that when you eventually migrate to Java 8 or later, you’ll need do little more than change your import statements.
The Joda-Time project is now in maintenance mode though actively maintained. The sponsors advise moving to the java.time classes.
ISO 8601
Replace that hyphen in the middle of your input string with a T to comply with the standard ISO 8601 formats. These standard formats are used by default in the java.time classes for parsing and generating string representations of date-time values.
OffsetDateTime odt = OffsetDateTime.parse( "2017-01-05T04:44:43-06:00" );
Search Stack Overflow
I'm terribly sorry if this had been asked before
Yes, your questions are all duplicates. Please search Stack Overflow for existing answers to all your issues:
backport of java.time, ThreeTen-Backport
Parsing strings containing an offset-from-UTC, OffsetDateTime class
exchanging date-time data with databases and Oracle in particular, JDBC 4.2 for directly exchanging java.time objects, or else calling new methods added to the old classes for converting to/from java.time to java.sql.Timestamp, or else on pre-Java-8 convert to Timestamp by count-from-epoch numbers.
Learning just how bad the old legacy date-time classes are, and you absolutely should go to the bother of adding the java.time backport library to your project.
Tip: Do not search from within Stack Overflow website. Their search engine is biased towards Questions while you want to search within Answers. Use site:stackoverflow.com in DuckDuckGo, Google, or Bing.
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes.
Where to obtain the java.time classes?
Java SE 8, Java SE 9, Java SE 10, and later
Built-in.
Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android bundle implementations of the java.time classes.
For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.