I completely agree that I am more likely to be successful running the Maven
plugin from Ant than running Javadoc with the swagger-doclet from Anti.
To wit, so far the latter has had some problems, particularly in the area
of classpath, which I think would be avoided with the Maven plugin which,
as you say, seems a more mature/active effort.
Thanks again,
Dave
On Friday, June 23, 2017 at 3:34:51 PM UTC-4, Ron wrote:
>
> Hi David,
>
>
>
> The short answer is – yes, you can do all that.
>
>
>
> The longer version is slightly more complicated.
>
> I’m not familiar with swagger-doclet – not with its quality, maintenance
> level, or even what version of the spec it produces (which is critical).
>
> The use of Ant does pose challenges, however, as far as I know, you *can*
> run maven plugins from an Ant build.
>
> Given the maturity of the tools, I really think that would be the best
> approach for you to explore.
>
>
>
>
>
>
>
> *From: *<[email protected] <javascript:>> on behalf of David
> Blickstein <[email protected] <javascript:>>
> *Reply-To: *"[email protected] <javascript:>" <
> [email protected] <javascript:>>
> *Date: *Friday, 23 June 2017 at 11:21
> *To: *Swagger <[email protected] <javascript:>>
> *Subject: *Re: Generate Swagger specification from Java source code
>
>
>
> Ron,
>
>
>
> Again thanks. Let me explain what I'm doing and what my immediate and
> subsequent goals are.
>
>
>
> We have a fairly large collection of APIs and endpoints in JAX-RS.
> These are all in one fairly large and somewhat monolithic project. The
> project, having been around for awhile, uses Ant (without Ivy) rather than
> Maven.
>
>
>
> We are trying to produce a number of client SDKs that provider wrappers
> for the REST services. As we don't know what platforms our
> partners/customers will ask for, we are hoping to use swagger-codegen to
> "easy" the generation of such wrappers for any new platforms we have to
> support.
>
> My immediate goals are:
>
> - Generate a Swagger Specification from the code
> - Use Swagger Codegen to generate skeletal wrapper templates for one
> or two platforms
> - Merely "have something to show" in the way of API documentation.
> At this point, it need NOT have much detail other than what is available
> via the JAX-RS annotations.
>
> A key point here is that this first stage is merely a "demonstration" or
> POC. Another key point is that we want to minimize the "pain" of having
> to manually update many client SDKs (and documentation) whenever the core
> REST API is changed.
>
>
>
> Now the longterm goals are:
>
> - Fully annotates the endpoints (beyond merely what JAX-RS provides)
> with Swagger annotations
> - Generate a Swagger Specification from that as part of the build
> - And generate from that:
>
>
> - Those same skelete templates (perhaps for multiple client platforms)
> - Excellent API documentation
>
>
> - And my hope is that we would not have to check what most of what
> Swagger-codegen generates but have additional code that connects the
> wrappers to the actual API servers. Having reviewed what
> Swagger-codegen
> generates for Java, I see that the code is generated in a way such that
> the
> templates and their implementations can be done in separate files (the
> former generated by the built, the latter checked into source control)
>
> Question: Does this strike you as a feasible approach
>
>
> The challenges I seem to be facing stem from the fact that I want to
> generate a specification file a) as part of the build and b) in a non-Maven
> project and thus I can't use the Maven plugin. That's why I'm trying to
> use swagger-doclet.
>
>
>
> I'm greatly appreciative of your efforts to help me.
>
> dave
>
>
>
>
>
> --
> 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 [email protected] <javascript:>.
> For more options, visit https://groups.google.com/d/optout.
>
>
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
