I'm using OpenAPI Generator to create a c++ pistache server stub.
Let's takes the next example:
I generate first stub version
Writing some code for several endpoint functions.
New YAML file comes in and i have to regenerate the whole stub.
How do I include(in an automatically manner) the function bodies from the first generated stub to the new generated one ?
Related
I want to generate c# asp.net core razor pages with many projects: Application, Domain, Infrastructure, Core etc.
I would like to know if Telosys is extensible to allow a custom console program to be called with arguments: , so this program can do some code merges in order to preserve possible additions/changes to the code a developer did since the previous code generation?
C# can have some directives called #region to partition the code and these will be "regenerate only regions" and outside these regions the developer can put his own code. We need to preserver his code.
C# Partial classes and methods can also help.
I want to have capability to merge newly re-generated code (e.g. entity class - I can add some properties or change some property name, type, annotations, tags etc.) into previously generated entity class. This could be done by creating #region .... #endregion where the code can be regenerated into and all the code that is outside these regions should be preserved. See: efg.loresoft.com/en/latest/regeneration So I would like to know if there would be a way to temporarily generate files in a TMPGEN folder and allow some "merge program to run" that will mege new code with previously generated code (with some code added by the developer) previously determining if merge is needed (compare hashes)
This is the code from EntityFrameworkCore.Generator tool that merges existing regions https://github.com/loresoft/EntityFrameworkCore.Generator..EntityFrameworkCore.Generator.Core/Templates/CodeTemplateBase.cs has the protected virtual method:
void MergeOutput(string fullPath, string outputContent) show that fullPath is an existing file and outputContent is the result of parsing the template (new content). RegionParser uses these namespaces: Microsoft.CodeAnalysis.CSharp; and Microsoft.CodeAnalysis.CSharp.Syntax;
so I need to user c# console application to user this preserver region code.
Thanks,
Rad
Yes, Telosys is extensible by using specific Java classes loaded in the template context with $loader
See : Is it possible in a Telosys template to call a function created specifically?
So, you just have to create a Java class to launch any Shell command
For example, see : How to get java getRuntime().exec() to run a command-line program with arguments?
I'm trying to create a custom annotation processor that generates code at compilation time (as hibernate-jpamodelgen does). I've looked in the web, and I find custom annotation processors that works with maven, but do nothing when added to the Annotation Processing > Factory Path option. How could I create a processor compatible in this way? I have not found a tutorial that works.
My idea is to, for example, annotate an entity to generate automatically a base DTO, a base mapper, etc that can be extended to use in the final code.
Thank you all
OK, Already found out the problem. The tutorial I hda found out dint't specified that, in order to the compiler to be able to apply the annotation processor, there must be a META-INF/services/javax.annotation.processing.Processor file that contains the qualified class name of the processor (or processors).
I created the file pointing to my processor class, generated the jar and added it to Annotation Processing > Factory Path and all worked correctly.
Just be careful to keep the order of the processors correctly (for example, hibernate model generator claims the classes, so no more generation will be made after it), and change the jar file name each time you want to replace the library (it seems eclipse keeps a cache). These two things have given me a good headache.
Thanks all
I use a xtext generated DSL in my project. I now want to generate some files with a wizard. I can currently create these files just by adding some strings to the file. But initially i wanted to create a Model Object of the DSL and add the new generated file to the resource set. I can't find a way accessing this without the StandaloneSetup of the DSL.
I'm now unsure if the use of the StandaloneSetup inside the Editor is the correct way, since it seems there should be a better way to access the already build up resource set used by the xtext framework to manage the already known files/sources. If i use the StandaloneSetup shouldn't there be 2 Injectors which could get really bad?
you can use the resource service provider registry to obtain the injector
http://koehnlein.blogspot.de/2012/11/xtext-tip-how-do-i-get-guice-injector.html
URI fakeOrRealUri = ...;
IResourceServiceProvider.Registry.INSTANCE.getResourceServiceProvider(fakeOrRealUri).get()
When I write a test in FitNesse I usually write several tables in wiki format first and then write the fixture code afterwards. I do that by executing the test in the wiki server and then create the fixture classes with names I copied from the error messages out of the failed execution of the test page.
This is an annoying process and could be done by an automatic stub generator, that creates the fixture classes with appropriate class names and method names.
Is there already such a generator available?
Not as far as I know. It sounds like you are using Fit, correct?
It sounds like an interesting feature, maybe you can create one as a plugin?
I want to build a simple 'rake' style command line tool that will allow me to define tasks in scala (that can optionally take additional command line arguments) that will be automatically loaded and accessible through a single main() method, to provide a single point of entry and minimize generating lots of wrapper scripts.
An example of what I'm looking for is Jersey, which will automatically load all annotated classes in a specified package and create REST endpoints. What's the right way to do this in scala? Basically, I just want to end up with a collection of instances of every class in a
package with a given annotation (which all have a Task trait or are a subclass of Trait, etc.)