Making a "bundle" for a new generator

[sste...@gmail.com]

So...

I want to develop a new generator.

I'd like to have it be a stand-alone bundle like:

/mySuperBundle
  README.md
  .gitignore
  /template
    file1.md.mustache
    file2.txt.mustache
  /generator
    mySuperBundle.java

and so forth with tests etc. 

 

I'm an experienced programmer but have exactly zero experience setting up or integrating with a Java project (on purpose; same reason I know nothing about setting up Windows).

This would seem a much better way of organizing new generators rather than having them have to be monolithically compiled into the main project.

So...is this even possible?  Anyone want to help me get this set up or, if it's been done before, a pointer to some clues?   

Thanks,

ssteinerX

[Tony Tam]

Yes look in the readme for instructions for making a new module

--
You received this message because you are subscribed to the Google Groups "Swagger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swagger-swaggers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sste...@gmail.com]

Thanks, Tony.  

I have looked at that.  

From what I can gather from reading a bunch of the generators, the usual methodology involves lots of code and very little in the way of convention.  

For example, every file in the template has to be explicitly referenced in the Java file instead of iterating over a template directory.  Also, the Java code has to specify the name of each output file to be generated rather than relying on a convention such as using filename.extension.mustache to generate filename.extension from the Mustache template file automatically.

This could lead to the elimination of almost all the Java code in each generator as well as the ability to extend them easily which is virtually impossible now without modifying the Java code (e.g. to add a new template file).

Has there been any work that you know of to reduce the amount of code by adopting a standard set of conventions for writing new generators?

If it were done properly, the generators could be as simple as a set of template files in a standard layout, with a tiny bit of configuration to make it go.  Very much a meta-swagger specification where very little configuration could drive the whole thing.

Thanks again,

ssteinerX

To unsubscribe from this group and stop receiving emails from it, send an email to swagger-swaggersocket+unsub...@googlegroups.com.

[tony tam]

Hi, I do agree the structure is a bit complicated.  The challenge is that we support many different languages and targets, each with their own idiosyncrasies.  It’s really impossible to have a standard structure.  For example, the output filenames vary in structure depending on the contents of the data.

That said, there’s many places to improve this, and maybe you have an idea that hasn’t been tried yet.  So please share what you’re thinking in more detail.

To unsubscribe from this group and stop receiving emails from it, send an email to swagger-swaggers...@googlegroups.com.

[sste...@gmail.com]

Hi, can you possibly point me at the worst current case you can think of off the top of your head i.e. where output varies depending on data?  The simple case is really straightforward; I'm working with the flaskConnexion at the moment.  

Regardless of the edge cases, it seems to me that an awful lot of the boilerplate could be replaced with a very small handful of utility functions accepting lists (defaults for the language, from the configuration file, or, worst case, declared in the code).

The trigger issue for me, is that I want to change some of the non-standard conventions used in the flaskConnexion template and I can't even rename a file without having to clone (bleh!) the Java code and template files and build an entirely new module.  

This is not optimal for many reasons I won't insult you by enumerating.

Thanks,

ssteinerX

[lang...@yahoo.com]

--------------------------------------------
On Sun, 1/29/17, sste...@gmail.com <sste...@gmail.com> wrote:

Subject: Re: Making a "bundle" for a new generator
To: "Swagger" <swagger-sw...@googlegroups.com>
Date: Sunday, January 29, 2017, 5:12 PM

from it, send an email to swagger-swaggers...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

ermania fascista spre concesii l-a determinat pe regele Caro al II sa

[lang...@yahoo.com]

--------------------------------------------

On Sun, 1/29/17, lange.kay via Swagger <swagger-sw...@googlegroups.com> wrote:

Subject: Re: Making a "bundle" for a new generator

To: swagger-sw...@googlegroups.com
Date: Sunday, January 29, 2017, 7:20 PM

https://groups.google.com/d/optout.egimul liberalse incadreaza intre anii 1861-1867. in Transilvania el a determinat o puternica efervescenta politica. Cerinta fundamentala era asigurarea egalitatii politice a natiunii romane cu celelalte natiuni din provincie. Urmand unor memorii catre imparat in ianuarie 1861 s-a reunit la Sibiu o Conferinta a miscarii nationale romanesti care a solicitat anularea legilor defavorabile natiunii romane.

[calde...@yahoo.com]

--------------------------------------------
On Sun, 1/29/17, lange.kay via Swagger <swagger-sw...@googlegroups.com> wrote:

Subject: Re: Making a "bundle" for a new generator
To: swagger-sw...@googlegroups.com

Date: Sunday, January 29, 2017, 10:39 PM

https://groups.google.com/d/optout.qitatu si rascoale antifiscale octombrie noiembrie 190CJ

[lang...@yahoo.com]

--------------------------------------------

On Mon, 1/30/17, caldercarey via Swagger <swagger-sw...@googlegroups.com> wrote:

Subject: Re: Making a "bundle" for a new generator
To: swagger-sw...@googlegroups.com

Date: Monday, January 30, 2017, 3:04 AM

https://groups.google.com/d/optout.Recensamant general al populatiei din Principate. - Rascoala taraneasca in Moldova mai-oct. - Adoptarea Regulamentelor Organice in Moldova si in tara Romaneasca un. - Epidemie de holera in Principate.18317 febr. - Trupele tariste patrund in Polonia. - Razboi intre Imperiul Otoman si Egipt. 21-24 nov. - Revolta tesatorilor din Lyon.

[tony tam]

OK I would say that the toughest ones are C++ and golang, and the myriad of java server frameworks.  They all change folder structures, class structures, and most of the grouping of all operations depending on logic in the structure, rather than a template structure.

To unsubscribe from this group and stop receiving emails from it, send an email to swagger-swaggers...@googlegroups.com.

[sste...@gmail.com]

So...Golang doesn't seem to do anything tricky, CppRestClientCodegen either.  

I think a huge part of what gives me the itchies about this is that most of the code is just repetitious boilerplate that doesn't really do much.  

It's populating data structures with code in a tedious way with e.g. keyword lists being duplicated between modules and spelled out in lines of code like:

typeMapping.put("map", "map");

typeMapping.put("array", "array");

and so on for line after line after line when a simple mapping would be much easier to read, more efficient, and should be shared among generators for the same language.

I understand how these things grow, and it's a pretty amazing body of work, but God is it in serious need of a refactor now that the problem is much better understood and a large number of frameworks have been tackled.

Unfortunately, I've hit the "tool is more work than the work" point on my current project  and have to go back, much as it pains me, to writing the code by hand as it will be faster, and I can deal with edge cases as they come up rather than trying to shoehorn what I need into the current Swagger model.

Thanks for your time, wish I could work on this but deadlines loom and this is a larger job than I can take on in my "spare time" for "fun."

Thanks,

ssteinerX

You received this message because you are subscribed to a topic in the Google Groups "Swagger" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/swagger-swaggersocket/R74obsz-FEg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to swagger-swaggers...@googlegroups.com.