Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#956: Switch to java-s2i image, fixed console and s2i build #1254

Merged
merged 1 commit into from
Jun 3, 2016
Merged

#956: Switch to java-s2i image, fixed console and s2i build #1254

merged 1 commit into from
Jun 3, 2016

Conversation

nicolaferraro
Copy link
Member

I think it's time to use the java-s2i image for the spring-boot quickstart.

This patch fixes the issue with the visualization of the jolokia console (#956).

I also fixed the template.json file for s2i. According to openshift/origin#3487, tags are not allowed in the "dockerImageRepository" element.
I removed the tag indication and verified that the correct tag is still used (it is referenced in the BuildConfig section).

@fusesource-ci
Copy link
Contributor

Can one of the admins verify this patch?

@rhuss
Copy link
Contributor

rhuss commented Jun 3, 2016

thanks ;-)

Have you tested whether hawt-app works with spring-boot ? Last time I had issues running it a spring-boot application within an s2i build because of the different ways jars are handled (flat vs. embedded).

In fact for the s2i case I wonder whether we shouldn't have an option without hawt-app for wildfly-swarm and spring-boot applications which do their own packaging. Either as third s2i image or even one without s2i.

@fusesource-ci fusesource-ci merged commit ff16c43 into fabric8io:master Jun 3, 2016
@nicolaferraro
Copy link
Member Author

Yes, it works, at least with the camel-quickstart..

The resulting image has a hawt-app style structure, with all dependent jars in the lib directory. Not the natural structure for a spring-boot application.

I agree, we should provide a specific option for one-jar applications like this one. I'll think about that.

@rhuss
Copy link
Contributor

rhuss commented Jun 3, 2016

@nicolaferraro ah, cool. I'll will try it myself, too, to be sure.

But even then, its not sure whether that we head to s2i in the future because we are more targetting to docker builds with a binary build source for the OpenShift case.

However, the base images should be consistent.

@jimmidyson
Copy link
Contributor

So is this PR supposed to be merged? Should this be reverted until the discussion above is decided?

@rawlingsj
Copy link
Contributor

Interesting - it looks like the CI job merged it automatically.

@rhuss
Copy link
Contributor

rhuss commented Jun 3, 2016

Have you tested ....

Maybe because of this in the comment ?

@rhuss
Copy link
Contributor

rhuss commented Jun 3, 2016

Wonder how strict the CI regexps are ?

@jimmidyson
Copy link
Contributor

Whoever set up the build was very kind: trigger phrase regexp of .*...

@jimmidyson
Copy link
Contributor

Have correctly configured now. Do you want to revert this PR? Will mean we have to resubmit it again for discussion before merging.

@nicolaferraro
Copy link
Member Author

It sounded strange to me too.. So PRs were accepted, no matter what you said :)

I just submitted the change as I've seen many other quickstarts referring to the java-s2i image. I though the old issues with product vs. upstream were solved in favor of s2i... I'll revert it for now

@jimmidyson
Copy link
Contributor

Thanks @nicolaferraro - should just be able to click revert button (I can do if you can't - not sure of required permissions).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants