Generator-jhipster: Swagger UI not accessible in prod profile even though swagger is enabled

[PierreBesson]

Overview of the issue

In prod profile, it is now possible to enable swagger with jhister.swagger.enabled: true. However Swagger UI cannot be accessed.

Currently, in prod profile with swagger enabled, it is lacking both the "API" link in the admin interface and the UI in itself.

Motivation for or Use Case

Enable access to API docs in prod profile. It would be especially nice to have for the gateway as it could then be used as an API Portal.

[gmarziou]

+1 This is due to the ENV constant in angular part, I guess it would be easier to do it when #3368 is fixed.
This way the UI would know dynamically what are the active profiles on server.

[PierreBesson]

OK, let's wait for PR 3368, then go on with this.

[deepu105]

@PierreBesson https://github.com/jhipster/generator-jhipster/pull/3474 is merged, I have added logic to hide swagger url in menu when no-swagger profile is enabled, but for this ticket some more work would be required

[PierreBesson]

Thanks @deepu105, I will work on this next week. This is important for me as I can use this in demos. Also it will be great to show the API screen when deploying to docker swarm or kubernetes (as the docker image is build only in prod profile).

[PierreBesson]

I've got it to work on a sample project.

The main issue is that currently swagger-ui is not added to the war. So my solution is to copy bower_components/swagger-ui/dist files in target/www/swagger-ui by adding this gulp subtask to the assets:prod task:

gulp.task('swagger-ui', function () {
    return es.merge(
        gulp.src([config.bower + 'swagger-ui/dist/**','!' + config.bower + 'swagger-ui/dist/index.html'])
            .pipe(gulp.dest(config.dist + 'swagger-ui/')),
        gulp.src(config.app + 'swagger-ui/prod/index.html')
            .pipe(gulp.dest(config.dist + 'swagger-ui/'))
    )
});

This is adding around 1 MB of swagger-ui assets to the war.

However I'm not currently satisfied with my current solution of doing another fork of swagger-ui's index.html. The solution would be to write an angular directive that would call swagger-ui directly and stop including swagger-ui in an iframe. This was already discussed (didn't found the relevant thread) and I think we didn't do it because of lack of time...

[jd-carroll]

Shouldn't swagger-ui just be added to the pom?

On Tuesday, May 10, 2016, Pierre Besson [email protected] wrote:

I've got it to work on a sample project.

The main issue is that currently swagger-ui is not added to the war. So my
solution is to copy bower_components/swagger-ui/dist files in
target/www/swagger-ui by adding this gulp subtask to the assets:prod task:

gulp.task('swagger-ui', function () {
return es.merge(
gulp.src([config.bower + 'swagger-ui/dist/**','!' + config.bower + 'swagger-ui/dist/index.html'])
.pipe(gulp.dest(config.dist + 'swagger-ui/')),
gulp.src(config.app + 'swagger-ui/prod/index.html')
.pipe(gulp.dest(config.dist + 'swagger-ui/'))
)
});

This is adding around 1 MB of swagger-ui assets to the war.

However I'm not currently satisfied with my current solution of doing
another fork of swagger-ui's index.html. The solution would be to write an
angular directive that would call swagger-ui directly and stop including
swagger-ui in an iframe. This was already discussed (didn't found the
relevant thread) and I think we didn't do it because of lack of time...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/3402#issuecomment-218164233

[PierreBesson]

@jd-carroll This could be a solution, however, we still need to use our own swagger UI's index.html (with support for different authentication schemes and microservices switching). So we would need to import the swagger ui assets distributed through the webjar which is not an elegant solution. Also webjar is kind of a different approach from what we usually do.

@cbornet do you think this solution would work ?

[jd-carroll]

@PierreBesson Thanks, I was just about to respond that I was way off...

[jdubois]

I prefer the solution with a new Gulp task, as this follows the same philosophy as we already do. Size isn't an issue, if people want to use Swagger they will of course need to have the Swagger UI in their final build.
If that's fine with everybody let's go with this solution -> @PierreBesson if you have tested it and it's already working, I guess the work is nearly done? If you don't have time can I copy/paste your code?

[gmarziou]

One short-term workaround I used was to add 2 web resources to war plugin in pom.xml:

                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-war-plugin</artifactId>
                        <configuration>
                            <warSourceDirectory>target/www/</warSourceDirectory>
                            <packagingExcludes>WEB-INF/lib/tomcat-*.jar</packagingExcludes>
                            <webResources>
                                <resource>
                                    <directory>src/main/webapp</directory>
                                    <includes>
                                        <include>swagger-ui/**</include>
                                        <include>bower_components/swagger-ui/dist/**</include>
                                    </includes>
                                </resource>
                            </webResources>
                        </configuration>
                    </plugin>

[PierreBesson]

@gmarziou I like your solution a lot, because adding swagger-ui to the war could be made optional with the no-swagger profile.

@jdubois I don't have time to do this for now. If someone has the time to do it please go ahead with adding the gulp subtask or @gmarziou's solution. But in the best case what we implement should be coherent with the jhipster.swagger.enabled property and the no-swagger profile. Also some tweaking to @deepu105's code must be done to correctly display/hide the link in the UI.

[PierreBesson]

I have created a branch with initial support for swagger UI in prod. I'm not entirely satisfied with this as I've duplicated our custom swagger-ui/index.html. It needs the jhipster.swagger.enabled property to be set to true.

I'm wondering if the profile should be swagger instead of no-swagger. Because actually in the default config swagger is disabled. Also it would be better if we would just have to watch for the swagger profile in /api/profile-info to know if we need to have the API link in the navbar dropdown. Currently, it is only hidden in no-swagger profile.
@deepu105 Does it make sense ? Were there a specific reason the profile is no-swagger instead of swagger ? I would really enjoy to be able to activate swagger + swagger ui just by setting the swagger profile on a JHipster app.

[deepu105]

If you use profile to activate option you have to pass it always for dev
profile and might be a little inconvenient to people who are used to
JHIPSTER. But now we have a property replacement mechanism to set default
profiles may be we can use that to set this. When I originally implemented
this we didn't have the property replacement mechanism. If you can make the
switch without any side effects i dont have any issues with that.

Thanks & regards,
Deepu
On 24 Jun 2016 01:14, "Pierre Besson" [email protected] wrote:

I have created a branch with initial support for swagger UI in prod. I'm
not entirely satisfied with this as I've duplicated our custom
swagger-ui/index.html. It needs the jhipster.swagger.enabled property to
be set to true.

I'm wondering if the profile should be swagger instead of no-swagger.
Because actually in the default config swagger is disabled. Also it would
be better if we would just have to watch for the swagger profile in
/api/profile-info to know if we need to have the API link in the navbar
dropdown. Currently, it is only hidden in no-swagger profile.
@deepu105 https://github.com/deepu105 Does it make sense ? Were there a
specific reason the profile is no-swagger instead of swagger ? I would
really enjoy to be able to activate swagger + swagger ui just by setting
the swagger profile on a JHipster app.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/3402#issuecomment-228118546,
or mute the thread
https://github.com/notifications/unsubscribe/ABDlFyo4UsTfo80rBxFg7ZGSZaJChtjeks5qOr8OgaJpZM4IIVLu
.

[PierreBesson]

@deepu105, It seems like a great idea. I will try to do this. I don't think it will have side effect because in dev swagger-ui is launched though browsersync and it will be alright as long as jhipster.swagger.enabled is set to true.

[gmarziou]

You could also add extras profiles like the swagger profile in the application-dev.yml using spring.profiles.include property, this way you make sure that our users have only to set dev profile to get swagger.

http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-profiles.html#boot-features-adding-active-profiles

[PierreBesson]

Good news, I made it work !

Thanks for your advice @gmarziou, I was going to set this in the pom.xml and the DefaultProfile conf class. Your idea is much better ! Although it has one disadvantage is that it displays profile in this order:
Running with Spring profile(s) : [swagger, dev]

[deepu105]

That should be ok

Thanks & Regards,
Deepu

On Fri, Jun 24, 2016 at 9:31 PM, Pierre Besson [email protected]
wrote:

Good news, I made it work well !

Thanks for your advice @gmarziou https://github.com/gmarziou, I was
going to set this in the pom.xml and the DefaultProfile conf class. Your
idea is much better ! Although it has one disadvantage is that it displays
profile in this order:
Running with Spring profile(s) : [swagger, dev]

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/3402#issuecomment-228345876,
or mute the thread
https://github.com/notifications/unsubscribe/ABDlFz9CcHZqPWvL2S07j4puW85JtgzGks5qO9wUgaJpZM4IIVLu
.