When a project is generated with no dependency at all, a metric with id "counter.initializr.dependency." (notice the extra dot) is published.

Meta-data V1 was solely used by Spring Boot 1.2.0.RC1 so we should remove its support now 1.2.0. final is out.

For backward compatibility reason, it would be nice that we can support older ids if we ever decided to change it. We have one example with spring-boot-starter-jpa that was renamed to spring-boot-starter-data-jpa.

The issues appear when importing the generated 'Gradle' projects into STS (or I gather eclipse).

1. Gradle project's JRE container doesn't follow the 'javaVersion' selection.

I think this is a bug in Gradle's eclipse plugin. Reported here: http://issues.gradle.org/browse/GRADLE-3100
Maybe it would be a good idea to add the 'workaround' code snippet to generated build.gradle.

2. imported Gradle + war projects aren't drag-dropable on TcServer intsance in the STS workspace

To fix this the build.gradle should "apply plugin:'eclipse-wtp'" instead of ""apply plugin:'eclipse'" (only if 'war' packaging is selected).

See also here: https://issuetracker.springsource.com/browse/STS-3828?focusedCommentId=102010&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-102010

If one uses the initializr via http://start.spring.io/ and leave all options unchecked,
one gets a plain Spring Boot Application which is a good start if users just want to
create a simple CLI app to play with DI and configuration.

Right now it its (IMHO) not obvious to users that they can get such a plain configuration when they don't check anything at all.

I'd suggest to make this more obvious either with an (always on default selection like "basic" or "basic configuration") or a little help text, or even show the generated pom directly in a window nearby...

Some extra metrics (perhaps via Spring Boot's metrics features) would be handy to track things like:

• total new projects created
• usage of each "starter" for a given project. This could later be summed for total usage
• gradle vs. maven usage
• project vs. build file

Basically, if we cataloged each project, then later on, we can write summation queries. If we only collect sums, we can't do alternative analysis later on.

The main layout of the interface should be polished so that it looks better (better use of bootstrap, etc).

Not much more right now but I'll update the description when I get more feedback.

It would be nice if start.spring.io could use the meta-data for versions from the main spring.io site.

logging as a chore.

This commit is responsible 8f1ce31

For causing this issue:
https://issuetracker.springsource.com/browse/STS-3944

Please don't change the names of the 'type' options. These names mean specific things to the STS import wizard (i.e. what type of import strategy needs to be used to import particular zip file into the IDE).

I'd like to be able to specify the name of the main application class when creating a new project. Currently, after creating a project, I have to rename Application.java to something that better describes the application. This would also encourage me to be less lazy and avoid having tens of Application (n) run configurations in Eclipse.

to expose proper meta-data...

With the release of Spring Boot 1.2.0, there are a set of new starters that are being made available but they are not defined yet. The main reason behind that is that if the user selects such starter and then choose Spring Boot 1.1.x the build will fail since that stater does not exist in that version.

This is a general issue (Spring Boot being the primary consumer in the case of start.spring.io).

The purpose of this issue is to add an optional versionRange attribute to each dependency that would expose which versions apply for that dependency, something like:

initializr:
  dependencies:
    - name: Group
      content:
        - name: Foo
          id: foo
          versionRanges:
            - springBoot:
                from: 1.2.0.RELEASE
       - name: Bar
          id: bar
          versionRanges:
            - springBoot:
                from: 1.0.2.RELEASE
                to: 1.2.0.M1

That information would be exposed in the meta-data (v2.1 coming?) so that the client can use that information to react accordingly. In the case of the web UI, some javascript hook should enable/disable the visibility of the starter according to the Spring boot version chosen by the user.

Use the new SpringBootApplication available as from Spring boot 1.2.0.RC1

spring-projects/spring-boot#1842

It would be nice if the UI had a reference to this issue tracker for those who want to report a problem or suggest some improvement.

Example: https://twitter.com/chbatey/status/536888702623301632

See #67

We currently store manually all the starters that are "web" related in order to figure out if we have to bring spring-boot-starter-web or if we have to create the templates and static directories.

Let's externalize that in the config, potentially in a reusable manner.

Hello

For http://start.spring.io, which is used for STS - Spring Starter Project
About Styles:

if Web is chosen the project structure, within src/main/, must include
webapp
webapp/resources
webapp/WEB-INF

To let export the project how a .war, therefore deploy it without any problem in Tomcat for example.

Same consideration if Thymeleaf is chosen, the project structure, within src/main/resources, must include

static
templates

Furthermore of include again

webapp
webapp/resources
webapp/WEB-INF

To let export the project how a .war, therefore deploy it without any problem in Tomcat for example.

Thank You.

I'm thinking of something similar to mvn archetype but better to generate a project from custom code templates. mvn archetype supports code templates using velocity and simple placeholder substitution. Also dynamic directory paths that bind to properties, e.g. /src/main/resources/../artifiact_id/.. .I'm specifically looking at what can be leveraged for Spring XD modules. In this case, there is no main (Application.java) , but some configuration templates - files generated for src/main/resources and corresponding tests. Beyond what the maven archetype plugin does, some support for profiles or conditional configuration would be great, i.e., alternate source sets driven by a property value. e.g.: moduleType = (job,source,processor,sink). The output of a sample processor project would be based on https://github.com/dturanski/spring-xd/blob/java-config-module/spring-xd-module/src/test/resources/ModuleFactoryTests/modules/processor/siDslModule.zip[this]

Provide more information regarding the available styles (see also #17):

• Selected by default
• Description (what it does, what it brings, links to the doc, etc)
• Ref to an icon

All these are optional and have obvious defaults (i.e. not selected by default, etc).

From a brainstorming with @olivergierke

The JSON representation of the links should be improved to:

"_links": {
    "gradle-build": {
        "href": "https://start-staging.cfapps.io/build.gradle{?dependencies,packaging,javaVersion,language,bootVersion,groupId,artifactId,version,name,description,packageName}",
        "templated": true
    },
    "gradle-project": {
        "href": "https://start-staging.cfapps.io/starter.{zipOrTgz}?type=gradle-project{&dependencies,packaging,javaVersion,language,bootVersion,groupId,artifactId,version,name,description,packageName}",
        "templated": true
    },
    "maven-build": {
        "href": "https://start-staging.cfapps.io/pom.xml{?dependencies,packaging,javaVersion,language,bootVersion,groupId,artifactId,version,name,description,packageName}",
        "templated": true
    },
    "maven-project": {
        "href": "https://start-staging.cfapps.io/starter.{zipOrTgz}?type=maven-project{?dependencies,packaging,javaVersion,language,bootVersion,groupId,artifactId,version,name,description,packageName}",
        "templated": true
    }
}

Summary of changes:

• the *-project links have got their zip/tgz replaced by a (non-optiona) tempalte variable. zipOrTgz could be renamed to something better and the available values should become a property in the rest of the document just as artifactId is etc.
• the *-project links have got their type request parameter fixed to gradle or maven as it doesn't make sense to customize them if the link relation already predefines them. Alternatively you could have a "(starter-)project" relation that allows customization via a type parameter but I guess you wanted to predefine what's available.
• the *-build links got the type attribute removed as the links already predefine it. Again you could also use a generic "(starter-)build" relation and allow customization if you want but using the root build file name as resource name is kind of neat already.

http://start.spring.io/install.sh fails because there no such file named as mentioned in install.sh

i.e. JAR_URL="https://repo.springsource.org/milestone/org/springframework/boot/spring-boot-cli/${VERSION}/spring-boot-cli-${VERSION}-dist.zip" is pointing to non-existing file.

Also version is older (0.5.0.M4)

The other URL (cloudfoundry) is completely broken
spring.cfapps.io is now non-existent.

I am making changes and making a pull request for the installation instructions.
Hopefully it will help others as well.

The dependencies that we provide should have a proper description as we have that in the guide already.

Simple String are considered a spring-boot-starter dependency as a convenience (maybe we shouldn't support that?). There is a regression with the metrics listener that blows up with a NPE

org.springframework.boot.cli.command.init.ProjectGenerationException: Failed to generate requestHTTP/1.1 500 Internal Server Error
    at org.springframework.boot.cli.command.init.ProjectFactory.generate(ProjectFactory.java:57)
    at org.springframework.boot.cli.command.init.InitCommandOptionHandler.generateProject(InitCommandOptionHandler.java:149)
    at org.springframework.boot.cli.command.init.InitCommandOptionHandler.run(InitCommandOptionHandler.java:103)
    at org.springframework.boot.cli.command.options.OptionHandler.run(OptionHandler.java:92)
    at org.springframework.boot.cli.command.OptionParsingCommand.run(OptionParsingCommand.java:53)

The ProjectRequest build based on URL parameters is not validated according to the service capabilities. For instance, we could set Java version to 99 and it will blindly put that in the generated project.

We should validate a project request meet the options that the service supports and generate a proper error message if it does not.

This idea came from a brainstorming with @philwebb on #66

Since curl is sending a user-agent header we could react to that and instead of dumping the meta-data in JSON format, we could provide assistance as to how the commands can be written.

Spring boot CLI has two kind of assistance:

• spring help init is a help page on the init command with a few examples and a description of the various options
• spring init --list contact the server and list its capabilities. This provides namely the supported dependencies (i.e. starters) and their respective ids.

Since we need to contact the server anyway, curl start.spring.io could return a text document tailored for curl with both a usage description and the capabilities of the server.

Hello,

I tried using http://start.spring.io together with Groovy as language, Maven as build tool and Java 1.8, as I wanted to use both Groovy and Java 8 in a project.

It failed with an unknown error when building (mvn clean package). After searching, I found a StackOverflow issue with the exact same problem: https://stackoverflow.com/questions/24711651/maven-compilation-fails-without-explaining-why

Bumping the version numbers from the original:

            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                <compilerId>groovy-eclipse-compiler</compilerId>
                </configuration>
                <dependencies>
                <dependency>
                    <groupId>org.codehaus.groovy</groupId>
                    <artifactId>groovy-eclipse-compiler</artifactId>
                    <version>2.8.0-01</version>
                </dependency>
                <dependency>
                    <groupId>org.codehaus.groovy</groupId>
                    <artifactId>groovy-eclipse-batch</artifactId>
                    <version>2.1.8-01</version>
                </dependency>
                </dependencies>
            </plugin>
            <plugin>
                <groupId>org.codehaus.groovy</groupId>
                <artifactId>groovy-eclipse-compiler</artifactId>
                <version>2.8.0-01</version>
                <extensions>true</extensions>
            </plugin>

To

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.1</version>
        <configuration>
          <compilerId>groovy-eclipse-compiler</compilerId>
          <source>1.8</source>
          <target>1.8</target>
        </configuration>
        <dependencies>
          <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-compiler</artifactId>
            <version>2.9.0-01</version>
          </dependency>
          <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-batch</artifactId>
            <version>2.3.7-01</version>
          </dependency>
        </dependencies>
      </plugin>
      <plugin>
        <groupId>org.codehaus.groovy</groupId>
        <artifactId>groovy-eclipse-compiler</artifactId>
        <version>2.9.0-01</version>
        <extensions>true</extensions>
      </plugin>

Solved the issue for me.

So the idea is to move from a list of well-known things to something more descriptive. Here is the current format (for reference): https://gist.github.com/snicoll/3140760e52e6987b8829

Here is the target format: https://gist.github.com/snicoll/cd6a342cdac3c61ad989

Summary of changes:

• Default is gone, instead every concepts is defined in a consistent manner
• Each concept has the following information (besides their names)
  • A "type" that is a hint on the format. We support "text" (simple text value), "single-select" (multiple values, a default, and one value should be selected) and "hierarchical-multi-select (multiple values can be selected). The type is also a hint on the way the "values" attribute is defined.
  • A "requestParam" that maps to the request parameter one should use to create the request. We have used default for everything so if the same as the name we don't need to mention it. Note that "dependencies" has a value since it's called "style"
  • a "values" that defines the possible values (id, name and description are common fields). In the case of hierarchical-multi-select, the values itself is hierarchical (values containing values)
  • The default value, if any. This refers to either an id of the potential "values" or a text if the type type is "text"
    The type concept does define a generate link using HATEOS. I am not sure if we should put the full URL or what used to be in "action"

The concepts look alike but they deviate from InitializrMetadata so maybe we need two separate objects now.

Since you can now do things like this:

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

It might be nice if the UI dynamically build that command as you check options on the screen.

Currently, the type attribute does not provide any descriptive information about what kind of artifact it is going to produce. This can be a problem for 3rd party clients that have to know before downloading the content of the archive to take some actions.

We don't want to make this too constrained so the idea is to add a tags attribute to the metadata for type that can accept any arbitrary tag. We want to support well-know tag such as build and format.

This should eventually fix the situation raised in #42

The generated archive is named "starter" no matter what and it contains a directory with the same name. It would be good to name that according to the actual name in the project (which would be demo according to current defaults)

The current start.spring.io shows a "Spring Boot Version:" setting with "app.Projects" as the only options.

It would be nice to create project directly at github instead of downloading them. This would make easier to start. It will also help to demonstrate a bug in case an error.

I forgot to add link of github api which is supporting to create a repository.

https://developer.github.com/v3/repos/#create

To me it is surprising to download a file from start.spring.io and unzip it and have anything but a self contained directory.

For example, if I used start.spring.io I might unzip the result to ~/code/ which contains all of my other code in it. Then I would need to find all the contents of the zip, delete them, create a new directory, and extract it there.

If instead the zip contained a folder named demo (i.e. the name entered into the UI) then all the contents would be self contained.

Since they are no longer part of the parent we should add them to the generated build files.

start.spring.io is a good way to introduce a new developer to Spring and spring-boot but some of the nomenclature can be confusing as well.

I was ramping up a new developer and here are some questions that came up:

1. What are the 'group', 'artifact', 'name', 'description' and 'package name' values used for? Is it okay to not specify them? How does it affect the application?
2. What are styles? In this section there's a list of dependencies but not everyone knows what they are for. Adding some description or categories (logging, development mode, datasources, templating, etc) may help the user and prevent him to make a selection that doesn't make much sense (JDBC and JPA).
3. What are types? Maybe renaming to Build tools or 'What is your preferred build tool?' makes it more straight forward
4. Another suggestion is to have a pre set that allows the user to start a working project such as: 'dynamic web' (web + some persistence + some template language + actuator) or 'restful API' (web + persistence + actuator).

Open the service to custom styles (i.e. starters). Right now, a style is defined by its name and has a textual value.

The name is used to build the actual dependency declaration, something like:

<dependencies><% styles.each { %>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter${it}</artifactId>
  </dependency><% } %>

This should be replaced by a more descriptive way of defining the starter, i.e.

• groupId
• artifactId
• version

To avoid the burden of repeating the groupId (and version), a set of styles can be grouped with a default for those.

This means that a custom/external style relates to one starter (or whatever the dependency is called). I think that's actually a good thing because it forces these to be easily configurable.

since older STS versions rely on the structure of the HTML page to figure out the starters to use, we have decided to split that in two separate apps. But this turns out to be a maintenance headache. The idea is to serve the previous ui from a different endpoint, something like http://start.spring.io/sts

Recent work has provided REST endpoints to serve metadata regarding the available options of the service (styles, language, java version, etc). It is also possible to generate a project by submitting such document to another endpoint.

The purpose of this issue is to review the structure of that document and ensure we can extend it in the future without breaking existing clients. Adding non regression tests for that would be a good bonus.

Once the API is stabilized, providing a documentation of it would ease the development of 3rd party clients.

Update the project so that it is really easy to deploy its own instance. Right now, the easier would be to clone this repository, perform some modifications to it and push/deploy the result somewhere.

What we're probably after is an easier way to consume and deploy this service. Something with a reference to a library and a few lines of code to enable it. That way, updating would be a matter of updating the dependency and tune the configuration if necessary.

This would help if we would provide samples in our own repo so that users have a concrete example for packaging and deployment.

We should find a way to provide a default set of templates and let the user override some or all of these.

When using Groovy, Initializr puts Groovy sources in src/main/groovy. The groovy-eclipse-compiler supports putting both Groovy and Java files side-by-side in src/main/java, and this is the default setup for a polyglot project in STS. Using separate source directories can cause some issues when the classes refer to each other, and I suggest putting all the sources under src/main/java.

The current ids for type are weird (I even suspect that these are used so that the browser choose a sensitive name for the content it downloads). We should fix them so that they can be used properly by a 3rd party client.

style is the only request parameter that deviates from the standard argument name. We should support dependencies as an alias so that 3rd party clients do not need to translate such parameter.

Hello,
initializr is failing to build in my environment after a clone. See exception below. Here's some environmental information:

C:\Users\swall\Documents\GitHub\initializr\initializr>mvn -v
Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T14:58:10-06:00)
Maven home: Q:\Private Drop\tools\apache-maven-3.2.3\bin..
Java version: 1.7.0_67, vendor: Oracle Corporation
Java home: c:\Program Files\Java\jdk1.7.0_67\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

Exception

Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Failure to find org.springframework:spring-test-htmlunit:jar:1.0.0.M2 in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced
at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.newException(DefaultUpdateCheckMa

It would be nice if the download and installer links had a description on how to use the files you're about to download and why I want to click on the download/installer buttons.

If no dependency is selected at all, spring-boot-starter should be added by default. This is no longer the case.

Refine and structure additional configuration items so that the service is more configurable out of the box.

Defaults for the project

• default.project.name 'demo'
• default.project.description 'Demo project for Spring Boot'
• default.project.group-id 'org.demo'
• default.project.artifact-id 'demo'
• default.project.version '0.0.1-SNAPSHOT'
• default.project.packaging 'jar'
• default.project.language 'java'
• default.project.java-version '1.7'

Right now, it is possible to download the spring cli distribution but we need to upload it every time we have a new version. An easier way would be to use the default boot version (assumed to be the latest or the one we want to promote) and send a redirect to the official repo.