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".
Related
SQS client raises Aws::SQS::Errors::NonExistentQueue error when queue is not found. But, why
https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/SQS/Errors.html This doc doesn't mention a thing about it. However, I found it here https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_GetQueueUrl.html#API_GetQueueUrl_Errors. But, this is a general api doc, not specific to Ruby.
Is documentation missing, is there a simple way to find what errors are being thrown?
The docs were likely generated with yard however digging through the git repo I was only able to find version 2x tags and no version 3 tagged anywhere. Only thing I could find was this commit which added the feature specs. Somehow it seems this never made it into the yard code in docs. I'm not sure what version 3 is referring to.
My project depends on drools 5.6.0.Final version. As part of that I'm trying to find a uri that I can rely for the drools-spring.xsd file. I'm trying to locate a reliable URI for that file I can reference, so that eclipses doesn't show issues, and so that spring can also intercept the requests and replace with the files in the jar as it sees fit.
I can drill into drools-spring-5.6.0.Final.jar in eclipse and see the xsd files in org.drools.container.spring. I also can see the xsd file here: http://grepcode.com/file_/repository.jboss.org/nexus/content/repositories/releases/org.drools/drools-spring/5.6.0.Final/org/drools/container/spring/drools-spring.xsd/?v=source
Going to drools.org and following their link to github and follow the rename of their group shown in the README file to https://github.com/kiegroup. I've searched this group for the xsd file(s) but have had no luck. e.g. https://github.com/kiegroup/droolsjbpm-integration/find/5.6.0.Final and https://github.com/kiegroup/drools/find/5.6.0.Final
This makes me think that the xsd files
are generated? Can someone confirm this and if so, is there a reliable URI that I can reference for this?
For some reason, the Drools' team doesn't maintain a hosted version of this schema.
Here you have an old post from Mark Proctor explaining it.
As far as I understand, they policy is still the same: do not host any .xsd file.
Hope it helps,
The drools-spring.xsd file location on drools website will give you a 404 error. You can have below two approaches which i could find while searching on the net.
One : Host the file on your local machine
Two : Place the .xsd file in the same directory as the location of the xml file referencing it.
Please refer to the below information . This will give a better understanding of the two methods mentioned above.
I'm currently editing my portal_normal.vm (server/tomcat/webapps/mytheme-theme/templates) testing if I can write on the file and see it on my browser. I tried putting a test comment "<!-- test -->" just to see if I can really write on the file. So I refreshed the file and hope I can see the comment I've added, but there we're none. So I continued refreshing (ctrl+r),\ and viewing the source code for almost an twenty minutes. After a while when I tried viewing it again it reflected in my source code. So I thought it was cached by either Liferay or my browser.
So I tried tweaking the comment adding version on it ("<!-- test v2 -->"), hoping to see changes. I checked it on another browser and the comment didn't update or include my added version. So I think Liferay is responsible for the issue.
this is what my portal-ext.properties contain:
auth.token.check.enabled=false
# Database settings
jdbc.default.jndi.name=jdbc/LiferayPool
#For removing captch
captcha.check.portal.create_account=false
session.enable.phishing.protection=false
default.regular.theme.id=my_site_WAR_my_theme
#Delete cookies while deleting session
session.enable.persistent.cookies=false
#redirecting null problem.
redirect.url.security.mode=mysite.com
journal.template.velocity.restricted.variables=
admin.email.from.name=Market.Travel Team
admin.email.from.address=admin#mysite.com
# Added because of the Error - No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here
hibernate.current_session_context_class=thread
session.enable.url.with.session.id=false
and my portal-developer.properties
theme.css.fast.load=false
theme.images.fast.load=false
javascript.fast.load=true
javascript.log.enabled=true
layout.template.cache.enabled=false
browser.launcher.url=
combo.check.timestamp=true
freemarker.engine.cache.storage=soft:1
freemarker.engine.modification.check.interval=0
openoffice.cache.enabled=false
velocity.engine.resource.manager.cache.enabled=false
com.liferay.portal.servlet.filters.cache.CacheFilter=false
com.liferay.portal.servlet.filters.themepreview.ThemePreviewFilter=true
Addition: When I tried editing the css files I can see the changes fast. Just one reload the the changes appear. I think it is just in my velocity template that take some time or there's something wrong.
Liferay version: Liferay Portal Community Edition 6.0.6 CE
Thank You!
There is really no need to define your own portal-developer.properties. By adding -Dexternal-properties=portal-developer.properties to your JAVA_OPTS in tomcat/bin/setenv.(sh|bat) Liferay will use it's default developer settings, which are almost identical to what you have provided. However, I do not believe this is contributes to (or could resolve) your problem. More details here.
The developer properties do allow you to make live changes to the templates provided you are changing the right file. Due to the default context.xml Liferay provides to the deployed webapps, the webapps are copied/cached in tomcat/temp/{id}-webapp-name. This means if you change the template in webapp/mytheme then it may take tomcat a while to pick up on the change, if it notices the change at all (this will depend on the tomcat configuration). On the other hand, if you make a change in temp/1-mytheme it will show up immediately. Editing the files in the temp folder is probably not ideal, so...
How to fix this: (no specific order)
Prevent Tomcat from using the temp directory for your theme. Create a context.xml file for your theme.
<Context cachingAllowed="false"/>
This file should be placed in the META-INF folder of your
theme. If you are using the Liferay auto-deploy feature the
context.xml file may be clobbered, here, and here. If this
is the case you will need to find a work around that best suits your
needs, such as modifying the context.xml after the theme is deployed.
If you are using the Liferay Plugin-SDK the you can follow the fast plugin development guide for setting up your development environment.
I'd like to get the url to access the tags on a build
we're running TeamCity 6.0.2
so far I can get to the build xml with
http://teamcity/httpAuth/app/rest/buildTypes/id:bt12/builds/number:1.0.0.990
but adding /tags to the end won't give me just the tags xml
I've gone thru the REST documentation but haven't found a combination that worked
The end goal is to PUT tags onto a specific build
UPDATE:
you have to specify the buildType in the bit of the url. here's the one that works
http://teamcity/httpAuth/app/rest/builds/buildType:bt12,number:1.0.0.990/tags
I think you misread the spec. The /tags is only allowed for one specific build and therefor I guess the /tags cannot be used on /buildTypes
Can you try this, assuming the id:bt12 gives you a specific build...
http://teamcity/httpAuth/app/rest/builds/id:bt12/tags/
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.