I am starting out with Cakephp3 3.8.x, and am wanting to use BootStrap 4. Now, in Github, friendsofcake/Bootstrap-UI, there is master (BS3), develop (BS4) and cake-4-bs-4 branch. I am not wanting to install using git, but rather with composer. However, when you go into packagist, the closest is dev-develop and dev-cake-4-bs-4. I gather these are the equivalent. However, when do you use 2.0.0.-betax, or 3.0.0-betax and what do they relate to?
You can see from the 'requires' panel on packagist.com.
So the branch 3.0.0-beta is for CakePHP 4, whereas 2.0.0-beta6 is for CakePHP 3.
E.g. for the latter the 'requires' panel says:
cakephp/cakephp: ^3.7.0
And no, the develop branch (dev-master on packagist) and cake-4-bs-4 (dev-cake-4-bs-4 on packagist) are not the same. If click on the expand button on packagist.com you will see this other branch at the bottom.
It seems that dev-master is CakePHP 3 and BS 4, whereas dev-cake-4-bs-4 is for CakePHP 4 and BS4.
Related
I am trying to update my app in the windows store with a new version. I am getting the error message in the UI:
This package is superseded by one or more higher-ranked packages.
The version number of the new binary is higher than the existing one. Here is what the version numbers look like in the store UI:
How can I raise the rank of the new version so that the store accepts it? What are the elements to package rank? I searched online for this but could not find the answer.
Thanks.
A day after first having the problem, I submitted a package numbered 2.0.6, which I had tried yesterday, and it went right in.
I tried to delete the original submission as suggested above, before trying submitting 2.0.6, but couldn't find a delete button. Maybe by opening the older one up in the UI I made the UI realize it was older. dunno.
I have created a framework which I want to use in my OS X app. Since updating to Xcode 7 on El Capitan, when I try to command-click on the import statement, Xcode goes to the following view.
How can I get Xcode to display the Swift representation properly?
I've had it happen before, and my solution was to recreate every project file which I don't want to do again.
From my experience there are two possible causes for this issue.
The first one is that your framework can't be located. To fix this you need to go to target's Build Settings and add a path to Framework Search Paths either an absolute:
/Users/{user}/path-to-framework-parent-directory
or relative to project directory:
$(PROJECT_DIR)/path-to-framework-parent-directory
Another possible cause is that the path to your framework contains a space in it. I found that it doesn't matter whether you try to escape it with backslash ../Project\ Name/frameworks or take the whole path in double-quotes "../Project Name/frameworks". The result would be that SourceKit could not load the module.
Note that $(PROJECT_DIR) could expand to a path with a space in it and it would too result in the same error. So it looks like a bug in Xcode/SourceKit (I tried the latest Xcode 7.2-beta3 and the bug is still there).
My repository was on the second hard drive /Voluems/Macintosh HD/Repos. I just renamed the hard drive to HD, so the path looks like /Volumes/HD/Repos and the problem was gone.
Max S. answer pointed me in the right direction, however I was using the 'recursive' option for my framework path.
To get things to work I had to explicitly add a path to directly the framework in question's immediate parent directoy (as oposed to just having a path to one of its higher up directories with the 'recursive' option set).
HTH
I had this problem too and the other solutions didn't work. I finally figured it out in my case:
The target name cannot have a space in it either
To rename it:
Go to your project settings
Expand the target list column on the left if not already there
Click on the relevant target once (or press Enter or Tab when having it selected) and type in the new name without the space
Weirdly, just changing the name of my folder from 'Developer' to 'Development' fixed the issue from me.
Running Product->Clean, Product->Build is what worked for me.
In my case, I have created a framework for my SDK along with podspec for making it cocoa pod.
I had the same problem when i use my SDK and it fixed when I imported Foundation API to the file where I am consuming my SDK
import Foundation
Here is another potential solution - one that worked for me:
After importing the framework I never built for simulator, only for real devices. Swift Modules were not showing up, same error. Then I built for Simulator and it suddenly worked, I could see the Swift Modules.
The reason is that when I make my framework, I have a step that copies the swift modules from the iphonesimulator build to the universal build, but does nothing with the modules from the iphoneos build. So my guess is that this is why it didn't work.
Note: once I selected simulator and built it started working all the time, regardless of the build destination.
How to install polymer iron and paper elements for Polymer 0.9 using bower? Tried using bower to install in a way similar to core-elements but fails. Migration guide doesn't provide any information on upgrading core/iron or paper elements.
bower install Polymer/iron-elements#^0.9.0
bower iron-elements#^0.9.0 not-cached git://github.com/Polymer/iron-elements.git#^0.9.0
bower iron-elements#^0.9.0 resolve git://github.com/Polymer/iron-elements.git#^0.9.0
bower iron-elements#^0.9.0 ECMDERR Failed to execute "git ls-remote --tags --heads git://github.com/Polymer/iron-elements.git", exit code of #128 fatal: remote error: Repository not found.
The new 0.9 elements are here.
You get them with bower this way:
bower install polymerelements/iron-ajax
I don't think there's an entire element collection ready yet, you should probably download every single needed element.
You can find more info about the new elements in the 0.9 release info:
Where did the elements go?
Not all elements have been ported to the
current release, but we’re porting them as fast as we can. You can
find work-in-progress versions of many elements in the PolymerElements
GitHub organization.
The elements are being reorganized into more consistent product lines,
including:
Iron elements. Basic elements that don’t express a visual style. Most
of the old core- elements are being renamed to iron-. Some former
core- elements that implemented material design (such as core-toolbar,
core-menu, core-header-panel) are being migrated to paper-.
Paper elements. Material design elements. All of the old paper-
elements, plus a few of the old core- elements.
Neon elements. Animation elements.
These element sets will be launching with their own site sometime
around the Polymer 1.0 timeframe. The new site will include API docs
for the elements. If you want to get started with the work-in-progress
versions, the individual repos are the best source for information
about the elements right now.
You can also check out the community Road to Polymer project which is
tracking the status of Polymer elements.
Also, you may find some valualble info in the Polymer Blog. Stay tuned!
Thanks Matteo. Adding to Matteo's answer we can install all available ported iron and paper elements for Polymer 0.9.0 using the following bower commands
bower install polymerelements/iron-elements
bower install polymerelements/paper-elements
for any elements installation, first go to element's page:
https://elements.polymer-project.org/
and find the element you want. while inside the element's page, in the left hand side, there is 'Bower Command' section.
just copy that and paste it in your shell/terminal/command prompt.
I had the same error as you reported, and was unable to install any elements using bower as proposed above. However, everything worked after running following command in my project folder:
git config --local url."https://".insteadOf "git://"
Here you may find more details about this solution:
Bower Install error: Unable to connect & exit code of #128
I'm using TortoiseHg 2.3.1 - I want to filter changesets by author, and I can't figure out how, couldn't find any info online either - does this option even exist?
Sixth button in full WorkBench Toolbar: "Fiter Graph". Just enter needed condition (see my comment) in edit-field and press small button "Trigger"enable checkbox "Filter" ("Toggle" invert filter of output, not refilter - my mistake) on the right of the edit-area (screenshot was done with TortoiseHG 2.* interface)
Given:
Building using Hudson/Ant.
Ivy cache timeout is set to 5 min.
Ivy repository contains has Project A version 2.2.2 and Project B version 1.1.1.
Project B relies on Project A.
Events:
API change is made to Project A.
Related changes are made to Project B.
Project A version 2.2.3 is built and published to the repository.
Under 5 minutes later, Project B version 1.1.2 is built.
Project B fails, still pulling in Project A version 2.2.2 from the Ivy Cache.
After 5 minutes, Project B will build correctly, with Project A version 2.2.3
I've looked but don't see an obvious solution (except not caching?). Is there a setting on publish that will update the local cache and the repo? Do you need to explicitly publish to both?
Just speculation: if A and B are built on the same machine, would doing an <ivy:resolve refresh="true"> at the end of A's build refresh the cache? That doesn't help if A and B build on separate machines, of course...
One solution, similar to (but not as bad as) not caching is to decrease the time things live in the cache via setting the following ivy property:
ivy.cache.ttl.default = 30s
Maybe that would fix your problem, for now. Although, it's not much better than not caching.
Off the top of my head, another thing I might try is to turn off caching but then re-implement caching manually by creating a filesystem resolver in your ivy settings file that points to the cache and placing it lower on the chain. That would look something like this:
<ivysettings>
<settings defaultResolver="all-repositories" />
<include file="ivysettings-common.xml" />
<resolvers>
<chain name="all-repositories" returnFirst="true" >
...
<ibiblio name="ibiblio" m2compatible="true" />
<filesystem name="manual-cache">
<ivy pattern="${ivy.default.ivy.user.dir}/cache/${ivy.local.default.ivy.pattern}" />
<artifact pattern="${ivy.default.ivy.user.dir}/cache/${ivy.local.default.artifact.pattern}" />
</filesystem>
...
</chain>
</resolvers>
</ivysettings>
Note: that ivy.default.ivy.user.dir, ivy.local.default.ivy.pattern and ivy.local.default.artifact.pattern are built-in properties that are set by default. I'm referencing them here in this example but I wouldn't need to make any other special effort to set them (they contain proper default values, already).
I hope one of these approaches can address your issue. Those are the only two possible solutions that come to mind, right now.
In the ivy file of project B you need to set the changing attribute to true on the dependency.
<dependency org="org.example" name="A" revision="latest.integration" changing="true" />
See the ivy documentation