In previous versions of Quarkus Json logging you where able to set quarkus.log.console.json.fields.timestamp.field-name=appTimestamp
In the current version this doesn't work anymore.
So it ended up being a versioning/documentation thing. The Quarkus code wizard was referencing an older version.
It has been tracked here: https://github.com/quarkiverse/quarkus-logging-json/issues/178 and subsequently fixed.
Related
I am looking for a Sonar Property to attach the quality profile during the build. In previous versions of Sonar there was a property -Dsonar.profile which is deprecated now. Can anyone please help me to get the property to attach the quality profile at runtime.
I am using Sonar version 4.5.7. Any help is highly appreciated.
Thanks,
Sanjiv
It has been marked as deprecated with no replacement.
Quoting page http://docs.sonarqube.org/display/SONARQUBE43/Analysis+Parameters :
Note that only parameters set through the UI are stored in the
database. For example, if you override the sonar.profile parameter via
command line for a specific project, it will not be stored in the
database. Local analyses in Eclipse, for example, would still be run
against the default quality profile.
And the latest version of the same page http://docs.sonarqube.org/display/SONAR/Analysis+Parameters has link to ticket about deprecation that contains other details - https://jira.sonarsource.com/browse/SONAR-5370
In other words - profile should be configured via UI or using web services.
The location of Springockito's mockito.xsd seems to be broken.
We used
xsi:schemaLocation="http://www.mockito.org/spring/mockito https://bitbucket.org/kubek2k/springockito/raw/tip/springockito/src/main/resources/spring/mockito.xsd
But this does not work any longer. Does anyone know of a current URI?
Looks like kubek2k's bitbucket repo is no longer accessible. Luckily someone made a github mirror here.
Given that this repo is no longer accessible, a better / more permanent solution might be to create a local copy of mockito.xsd in your src/main/resources directory, and reference that instead.
For example, create src/main/resources/META-INF/spring/mockito.xsd and change the xsd reference from:
....
http://www.mockito.org/spring/mockito https://bitbucket.org/kubek2k/springockito/raw/tip/springockito/src/main/resources/spring/mockito.xsd">
to
...
http://www.mockito.org/spring/mockito META-INF/spring/mockito.xsd">
update 10-05-2016:
There's also a fork here -- it's based off version 1.0.7 from what I can see (which is more recent than Angellnc's github mirror above).
And another fork here (this one is actually a mirror, but still 1.0.7)
update 10-05-2016 2:
Looks like there a 1.0.9 version also hosted here: https://bitbucket.org/duncan85/springockito/
New repo location
The difference between the version in github (see first answer) and this one is the additional boolean attribute (useStaticMap) on the 'mock' element.
In our case the test were failing because mockito was expecting that boolean value in.
I am also facing the same problem and it works for me by changing xsi:schemaLocation
to
either "https://raw.githubusercontent.com/AngelInc/Springockito/master/src/main/resources/spring/mockito.xsd" or "http://www.mockito.org/spring/mockito.xsd".
Whenever you deploy to cloud code, Parse.com outputs the new release version.
"New release is named v296 (using Parse JavaScript SDK v1.4.2)"
Is there anyway to get this information programatically within cloud code?
I could not find a way to do that without a small trick:
I capture the console everytime I deploy a new version and then I parse the last line to get the version number. With that information, I update a collection in my Parse environment with this version code.
Whenever I need this information in cloud code (or even in the client), I query this collection to get it.
That's not the best way to do it, but it works...
Note: if, for some reason, you could not capture the console after deploy, you can also use "parse logs" and search for a string like "Deployed v296 with triggers:" and do the same after parsing it.
Hope this helps!
I'm reviewing someone's code and I can see that they're using codeigniter. But I'm trying to figure out which version they've used. I've been rooting around in the directory structure to find some information but haven't been successful yet.
Thanks.
Inside the framework, it's defined in 'CI_VERSION'.
Path is system/core/CodeIgniter.php
define('CI_VERSION', '2.1.3');
Simple as this;
echo CI_VERSION;
The constant is globally available and is pre-filled with the release version of the code you have.
Just put the echo in an empty controller and call it in the browser to test it.
I have a Managed Object Context to which I add two different SQLite stores. I use Configurations in the Mananged Object Model to assign certain entities to one store and other entities to the other. The Configurations are called "UserDB" and "MainDB".
Everything works okay until I try to use automatic migration. After creating a new Managed Object Model version, and adding a new attribute to one of the entities in the UserDB Configuration, I get an exception when adding the old version store (for the UserDB related store) to the store coordinator: 'Model does not contain configuration 'UserDB'.' I can find no hits for this error on Google. Anyone out there using multiple stores with Configurations? Anyone have an idea what I might be doing wrong?
The stack looks like this:
objc_exception_throw
-[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:]
-[NSStoreMigrationPolicy sourceModelForStoreAtURL:metadata:error:]
-[NSStoreMigrationPolicy(InternalMethods) _gatherDataAndPerformMigration:]
-[NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:URL:options:error:]
-[MyAppDelegate persistentStoreCoordinator]
This looks like a bug with migration+configurations. I was able to work around the problem by going through the same motions and passing nil for configuration when calling addPersistentStoreWithType. The migration happens, and then I can make a new persistent store coordinator and add the stores again with the proper Configuration string arguments.
This is the second configuration related bug I've run into. Not a well tested feature apparently.
I had the same problem. The fact pattern was identical and the error message the same. It turned out, however, to be the result of my own mistake.
Let's say the old model was Blah.xcdatamodel and the new Blah 2.xcdatamodel. I had started making changes to Blah before realising my mistake and creating Blah 2. I then used my version control system (Git) to revert to the old Blah and then recreated Blah 2. Everything looked right. But I must have done something wrong in the reversion process, because when I thought to double check that Blah.xcdatamodel in my current project folder was really the same as Blah.xcdatamodel in the project folder I used to build the previous version of the app (fortunately I always keep a zipped archive of the project folder for each released version as I don't fully trust version control systems), I found that they were in fact different, albeit that they looked identical in XCode. The file size was different, for instance.
I substituted the old Blah into my current project folder, and lo and behold it all went perfectly, without any need for the workaround described by Ken.
I am not saying that Ken had necessarily made a similar mistake, but if you do encounter this message it is at least worth confirming that the model you are migrating from is REALLY the model that was used to create the data in question.