Use the Initializr web site

[Buzzardo]

I removed the curl command to create a project, since it didn't work and since we are now focusing on sending people to the Initializr web site.

[dsyer]

The curl command didn’t work? Why not? I like it. I like that we tell people about it. What didn’t work for you?

[Buzzardo]

The curl command didn’t work? Why not? I like it. I like that we tell people about it. What didn’t work for you?

First, the pipe to tar (| tar ...) part of it doesn't work.

If I strip that off, I still get nothing from curl https://start.spring.io/starter.tgz -d style=web -d name=simple.

If I tinker a bit, I can get curl https://start.spring.io/starter.tgz style=web -o simple.tgz to work, but I can't get it to unpack itself. That takes a separate command.

I talked to Michael about this (came up during our weekly one-on-one). We decided to trim it down to only the web page route. Michael thought that, if we were going to share a shortcut, we should use the value from the Share button in the Initializr. That would be something like https://start.spring.io/#!type=maven-project&language=java&platformVersion=2.2.2.RELEASE&packaging=jar&jvmVersion=1.8&groupId=com.example&artifactId=simple&name=simple&description=Demo%20project%20for%20Spring%20Boot&packageName=com.example.simple&dependencies=web in this case.

I opted for sending people to the Initializr web site, because we're pushing that in our other communications.

[dsyer]

It works for me, and I think you must have a typo in your "tinkering", or a copy-paste error because that one doesn't (there's no -d for the request params). Is it a MacOS thing with tar? What is it that goes wrong for you exactly? I still find the curl | tar option pretty helpful, and it's much shorter than that ugly link.

[Buzzardo]

The paragraph that includes the -d is the one that doesn't work. The next paragraph has the version (with -o) that works for me.

The curl | tar does not unpack the file for me. I have tar installed. I can get a tar file from the site and run a separate tar command to unpack it, but it never works as a piped option.

I don't much mind that. It was the fact that the command produced nothing that bothered me. We can fix the alternative, but the message we're pushing is to go to https://start.spring.io, so why not trim all this down to that?

[dsyer]

I think the curl command is wrong. Should be dependencies=web (not style=web). Does that work for you?

why not trim all this down to that?

Because start.spring.io has a command-line interface as well as a browser one. And I happen to find it useful, so I assume others will.

[Buzzardo]

Please share the curl command you use. The command in the file does not work, at least for me.

This command does work for me: curl https://start.spring.io/starter.tgz style=web -o simple.tgz

[dsyer]

$ curl https://start.spring.io/starter.tgz -d dependencies=web -d name=simple | tar -xzf -
$ ls
HELP.md  mvnw  mvnw.cmd  pom.xml  src

[Buzzardo]

Your command does work.

The command in the document is curl https://start.spring.io/starter.tgz -d style=web -d name=simple | tar -xzvf -

Here they are, one above the other, so we can see the differences:

curl https://start.spring.io/starter.tgz -d dependencies=web -d name=simple | tar -xzf - (yours)
curl https://start.spring.io/starter.tgz -d style=web -d name=simple | tar -xzvf - (from the manual)

[mminella]

I feel that there are two questions here that need to be addressed for this PR:

1. Should our guides/tutorials/etc provide multiple ways of getting a project from Spring Intializr? Given our marketing around the web UI (see Josh Long's past year or more of talks), cluttering all the guides (we should be consistent with this message across all of them) with multiple ways of handling how to get the project seems like a lot for a getting started experience. The Guides have recently been transitioning to have everything based via Spring Intializr's GUI and should be consistent IMHO. As an end user of Spring Intializr, the curl "interface" isn't well marketed and while seems to work great once you get there, does not seem very intuitive to a new user (may be just me in that I wouldn't think to curl the endpoint to see what happens and it's not mentioned anywhere but the Github Repo).
2. How do we maintain the curl command going forward if we leave it in? This PR came out of the fact that the command in these guides was broken by a breaking change in the API that went unnoticed. How do we prevent this from happening in the future? The GUI hasn't changed fundamentally since the site has gone live (from a user interaction perspective). A user still fills out a couple fields and click check boxes.

Personally, I'd like to see all the guides/tutorials/etc be consistent. We already have the Maven/Gradle/IDE options in each one because we believe the market share is close enough between all of them to warrant it. My hunch is that the market share for the curl interface doesn't make sense to add to all the guides when compared to the other options.

[dsyer]

I think that's mostly understandable but also mostly upside down. The curl interface is well supported, even if it is not well marketed. We could fix that (e.g. by including it in the guides). Maintainability is much better for curl commands than for images of screenshots, which is what we have for the browser-based guide instructions. So to answer your 2 questions, 1) yes, and 2) irrelevant.