Create the starter project in a self contained directory about initializr HOT 14 CLOSED

You have a point here. I guess it wasn't such an issue for me so far since MacOS creates a directory with the name of the zip file by default. This is tricky as changing this breaks the CLI: if you run spring init -d=web foo-bar then you get a new foo-bar directory with your web-based Spring boot project.

If we create an extra directory in the archive, that use case is broken. It's a bit ambivalent: I really dislike when things are being extracted in the current directory but on the other hand if we "burn" a directory in the archive, there's no way for you to choose where to actually extract the project (i.e. if you want to extract in ~/code/foo-bar, it stills create a demo directory in it).

Thoughts?

from initializr.

on the other hand if we "burn" a directory in the archive, there's no way for you to choose where to actually extract the project (i.e. if you want to extract in ~/code/foo-bar, it stills create a demo directory in it).

True, but this is a lot easier to fix. If you extract the existing zip to a directory that contains lots of files, cleanup is a lot more difficult as you need to find all the files that need to be moved into a directory.

I do see your point about backward compatibility. Perhaps this needs to be a larger discussion.

from initializr.

It only has to be a feature of the HTML UI i think. Seems like a good idea to me (an optional extra parameter that isn't exposed to the CLI client).

from initializr.

@rwinch @dsyer I have pushed a candidate fix for this issue on http://start-staging.cfapps.io/ - Could you please try that out with your existing use cases to make sure it does what you want?

Thanks!

from initializr.

It does. Thanks.

from initializr.

Works for me. However, why not allow the parameter to be used in the CLI? Obviously you would not want to change the default behavior, but I think it would be valuable from a CLI tooling too.

from initializr.

I'd prefer not adding too much parameter in there. We already have too much of them if you ask me.

from initializr.

It just seems like it would simplify the steps for a lot of instructions that have to do something like:

$ mkdir ui && cd ui
$ curl https://start.spring.io/starter.tgz -d style=web \
-d style=security -d name=ui | tar -xzvf - 

from initializr.

This works already now:

$ curl https://start.spring.io/starter.tgz -d style=web \
-d style=security -d name=ui -d selfContaind=true | tar -xzvf - 

It's not exposed in the UI but you can use it if you set it. Maybe selfContained is not that good as a name.

from initializr.

I was not aware of that parameter. Thanks! Looks great to me :)

from initializr.

that reminds me there is still an "inconsistency" between name and artifactId. That command above is going to create a directory named demo because name is the attribute for the "name" of the project, not the identifier of the artifact. We use artifactId to derive the name of the directory and the artifactId entry of the build; We use name to derive the name of the app and the name entry in the pom.

The proper command would be

$  curl https://start-staging.cfapps.io/starter.tgz -d style=web \
-d style=security -d name=ui -d artifactId=ui -d selfContained=true | tar -xzvf - 

from initializr.

@dsyer, @rwinch and I discussed offline and the selfContained parameter is confusing. Rob is suggesting useBaseDir. Thoughts?

from initializr.

I would prefer -d baseDir=ui , and default that to something sensible in the UI. I think you implemented it to default as the "artifact" ID (not the "name") BTW (at least that's what happens when I try it from start-staging.cfapps.io).

from initializr.

@dsyer @rwinch staging has been updated with that suggestion. The new command is

$ curl https://start-staging.cfapps.io/starter.tgz -d style=web \
-d style=security -d name=ui -d baseDir=ui | tar -xzvf -

How does that sound?

from initializr.