Swagger 2.0 is AWESOME compared to the version Restler RC6 is using. Is there any easy way to continue using the current RC6 branch but swap out the swagger-ui part for version 2.0?
Swagger 2 development is carried out in https://github.com/Luracast/Restler/tree/features/swagger2.0 branch. Merge this with v3 branch to get the desired output
Related
I'm currently developing a (Laravel) package on Gitlab, and i want to automate testing using its CI/CD pipeline.
The problem
I already know ho to set up a pipeline in Gitlab, but what i want to achieve is to automate testing against different versions of the same dependancy, in order to keep checking compatibility with old version and add checking with upcoming new ones.
The case
My Laravel package is not so complex right now and don't use some particular nor specific Laravel features, so i would like to keep it compatible with te more versions of laravel possible: i would trigger different testing stages in my pipeline to run my tests against laravel 5.6, 5.7, 5.8, 6, 7, and 8.
The question
How do i trigger different testing stages using different laravel/framework versions?
When downloading dependancies composer will go for the latest version available if i define it with '^', so which files do i have to edit?
Ok, i've analyzed the problem a bit more, and made some considerations about it.
I'm writing not to properly answer my question, since i hope someone will eventually came up with a better solution/idea, but to just share some toughts with everyone is facing the same problem.
First: since i'm developing a package for Laravel i cannot declare laravel as dependancy for it, production nor develop, it is my laravel project that need to declare my package as a dependancy.
Second: to test my package compatibility with laravel i'm using orchestra/testbench as a dev-dependancy, and as for its documentation every release target a single and precise Laravel version, so if i want to test my package against different Laravel version i need to test it with different orchestra/testbench releases.
Third: the only dependancy my package has is just php 7.3, so i can easily test against this and subsequent version using Gitlab pipeline and creating a job for each php version that use a docker image with the correct php version and the last composer one.
Conclusion
It is not trivial nor straight to test a Laravel package against different Laravel version.
The only idea i came up with, but not tried since i gave it up aj just test php versions (for now) is to make a branch for each Laravel version i want to test with and update its composer.json dev-dependancy with the correct orchestra/testbench release.
Than i can execute php tests on my features branch merge request, and in case of success merge the develop branch on each "laravel branch" and execute on those the laravel compatibility test.
At last, if every laravel branch pass its tests, or at least the ones i decide to keep deevelopment/support active for, i can merge the develop branch on the master.
I'm not goig for it
I decided to avoid all of this since i'm not quite sure on how implement all of this on the pipeline, and i strongly think that it just adds mantainence burden to this project.
So i just keep the php jobs to check against different php versions, this way i just need to copy/paste a job definition in my gitlab-cy.yml file and change the docker image version accordingly to the new php version to test against.
I'm looking for a solution on how to deal with API versions in ANYpoint API manager. At the moment it is possible to create a new version of an API. But it is not possible to distinguish between different OTAP environment. In my situation it could be possible that a test environment has a newer API version than production. Do anyone recognize this issue and how did you solve it?
Currently, there are no environment promotion capabilities per se in Anypoint Platform. Having said that, there are a number of things that you can do that can help in that regard, for example:
- You can export an API from Organization A and import it on Organization B.
- You may define different sub organizations, to reflect your OTAP environment structure.
In general, it is not strictly bad that on QA, Stage or UAT environment, you have a newer API version than in Production, if you plan to implement such version in there.
Just my 2c, Nahuel.
As far as i understand if we want are going to create multiple apis then RAML versioning should be followed. what i do i can share with others.
development raml version= 0.1.0
First major release version=1.0.0
if there is any minor change then we can do 1.0.1
if there is any major contract breaking change then we can use 2.0.0.
Lately I have downloaded and composser installed a magento code migration toolkit from GIT, which can migrates modules in format of Magento 1.x to format of Magento 2.0, It helps in reduce the time consuming for us to typing the php, modules, and other time consuming codes of the Magento 2.0 Module.
However, I have stucked at here, I don't know what this mean...:
Step one: Migrate Magento 1.x module structure to Magento 2.0 structure (bin/migrate.php migrateModuleStructure).
Step two: Migrate Magento 1.x layout.xml Magento 2.0 structure file structure. (bin/migrate.php convertLayout).
Step three: Migrate PHP code (bin/migrate.php convertPhpCode).
Actually what is meant by “migrate” from these steps?
If you feel intersted, you also can download from here.
For Step One in your question,
Step one: Migrate Magento 1.x module structure to Magento 2.0 structure (bin/migrate.php migrateModuleStructure).
it is use to remove the code pools (core, community, local), and also aggregate module files in single directory.
For Step Two
Step two: Migrate Magento 1.x layout.xml Magento 2.0 structure file structure. (bin/migrate.php convertLayout).
it is to breakdown layout files by handles. It also formats out XML files such as block types and block names.
For Step Three in your question,
Step three: Migrate PHP code (bin/migrate.php convertPhpCode).
it is for breaking down the controllers by actions. It also formats the php files.
You may refer to the youtube video below for more understanding:
-Imagine 2016 - Developer Deep Dive: Magento 1.x to Magento 2 Code Migration Tool
The swagger-core documentation describes how to incorporate swagger into the application. Annotations are scanned at runtime.
Instead, I would like to statically generate the swagger API specification at build time. Is this possible using swagger-core?
EDIT: We are building using ant.
swagger-core alone is a runtime library and cannot be used to generate Swagger definitions at build time.
You can use the swagger-maven-plugin which depends on swagger-core to produce such definitions. However, I'd recommend browsing around the branches and using the version that produces Swagger 2.0 definitions to keep up with the latest improvements.
I would like to integrate Castle Windsor into a WCF project and have read that you can hook it up using the WcfIntegration facility but I am unable to find where to download the dll.
Can anyone help?
WCF Facility did not have an official release yet, as there are still few rough edges and issues we want to address before making the release. Your best option now is to either get the source using link provided in the other answer, or to get it from Horn website. The latter option is compiled against trunk version of other projects, so if you want to use released version of Windsor (2.1.1) you have to compile it yourself.
It's in NuGet now with all of the other 3.0 beta stuff.
Install-Package Castle.WcfIntegrationFacility
http://nuget.org/List/Packages/Castle.WcfIntegrationFacility
Update
Just to follow up, The one in nuget is targeted for Windsor 3.0 beta 1. I found out the hard way that some of the other facilities do not yet support 3.0 beta 1. Specifically, if you're using the NHibernate or AutoTx facilities, you need to stick with a WCF factility compiled for Windsor 2. The latest one seems to be the Jul 29 2011 commit from the git repository, available here.
This will have to suffice until the 3.0 versions of the other facilities are updated. It's already being discussed on the castle users group list.
https://svn.castleproject.org/svn/castle/Facilities/Wcf/trunk from http://www.castleproject.org/subversion.html you have to download the source and build it yourself apperently.