by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 16:18
    sivaprasadreddy edited #806
  • Jan 31 2019 16:18
    sivaprasadreddy edited #806
  • Jan 31 2019 16:17
    sivaprasadreddy opened #806
  • Jan 31 2019 15:32
  • Jan 31 2019 15:14

    snicoll on new-generator

    Adapt to latest API change Move InitializrDefaultStarterBu… (compare)

  • Jan 31 2019 10:42

    snicoll on new-generator

    Switch project structure to use… (compare)

  • Jan 31 2019 10:34

    snicoll on master

    Upgrade to JUnit 5.4.0-RC1 Split metadata specific excepti… (compare)

  • Jan 31 2019 09:43

    snicoll on master

    Initiate 0.8.0.BUILD-SNAPSHOT v… (compare)

  • Jan 31 2019 08:13
    phoenigm starred spring-io/initializr
  • Jan 31 2019 03:43
  • Jan 31 2019 03:04

    mbhave on new-generator

    Adapt tests to use new API Customize build version based o… (compare)

  • Jan 30 2019 19:28
    mbhave closed #805
  • Jan 30 2019 19:27

    mbhave on master

    Fix generate release notes scri… (compare)

  • Jan 30 2019 19:26
    mbhave edited #805
  • Jan 30 2019 19:26
    mbhave commented #805
  • Jan 30 2019 19:05
    snicoll milestoned #805
  • Jan 30 2019 19:05
    snicoll labeled #805
  • Jan 30 2019 19:05
    snicoll assigned #805
  • Jan 30 2019 19:05
    snicoll opened #805
  • Jan 30 2019 19:04
    snicoll milestoned #804
soutchay
@soutchay
I noticed that the reactive facet is not available as well as the ReactorTestBuildCustomizer. For now I can bring those in from start.spring.io to include io.projectreactor:reactor-test but I was wondering if they will be included in a future version?
Rodislav Moldovan
@rodislav
Indeed
version 1.0.0 of hateoas worked just fine
I had to define it manually as I use spring boot 2.3.1
Stéphane Nicoll
@snicoll
@rodislav initializr 0.9 is out. It looks Spring Hateoas add another breaking change as it used to work with both Spring Boot 2.2 and Spring Boot 2.3. If you upgrade to 0.9 it’s built against Spring Boot 2.3
@soutchay No. The library doesn’t have all the opinions that start.spring.io has. If you want start.spring.io + some additional customizations, consider forking that project
Rodislav Moldovan
@rodislav
thanks @snicoll +1
soutchay
@soutchay

got it thank you i see what you're saying. I thought that maybe ReactorTestBuildCustomizer would be included under intiailizr-generator-spring for webflux.

Would some of the additional testing features part of io.projectreactor:reactor-test be included in spring-boot-starter-test' in the future? I suppose this question is better suited for the Spring Boot Gitter conversation

Stéphane Nicoll
@snicoll
No it would not
There are a number of tests specific artifacts that we had when the tech is added. Adding reactor-test for any app doesn’t make sense as you may not use reactor at all
spring-boot-starter-test really has to focus on what’s generally useful
As for ReactorTestBuildCustomizer I got you from the start. I agree there is a fine line between things in generator-test and things in start.spring.io. The key thing to remember is that the library does not know anything about particular dependencies. And the reactor id is defined in the service, not the library. For that reason alone, we can’t move the implementation there
soutchay
@soutchay
thank you for the clarification. It's unfortunate but I do agree with what you're saying 🙂
soutchay
@soutchay

Hello again, I was wondering if there were thoughts to add a @ConditionalOnDependencyGroup annotation? As an example, I would like to always include a BOM(ie. implementation platform('org.testcontainers:testcontainers-bom:1.14.3')) for databases supported by my Initializr

Would this be the right approach or is there something that I may be missing? Thank you

Stéphane Nicoll
@snicoll
That is interesting. You could easily create that condition yourself. Give that a try and let us know how it goes?
soutchay
@soutchay
Sure! I've created a custom conditional before for Java versions following the same pattern as others. I'm using it in addition with the @ConditionalOnLanguage. I thought maybe I was missing a different way of going about it. Maybe using facets instead?
Stéphane Nicoll
@snicoll
Facets could be another way. My main concern is how likely that conditions is going to be reused. But I like the fact things are tagged in the metadata rather than in a customizer when you need to match a “large” amount of dependencies
If you could set a facet for all dependencies in a group that would give you what you need, isn’t it?
Stéphane Nicoll
@snicoll
Thanks @tgeens, did we discuss contributing this back? That rings vaguely a bell
Toon Geens
@tgeens
we did - you said it could be useful, but you did not have a use case at that point and wanted to keep things simple
Stéphane Nicoll
@snicoll
Let’s see what @soutchay thinks of the idea
The main thing that makes me a bit nervous and the reason why I didn’t ask you to contribute back is that it is the only condition that gets the metadata
I felt there’s something we could have done to avoid that somehow. Not sure what though
Toon Geens
@tgeens
take your time thinking it over, I'm going on vacation first ;-)
Stéphane Nicoll
@snicoll
:)
soutchay
@soutchay

If you could set a facet for all dependencies in a group that would give you what you need, isn’t it?

Yes that would work as well! But I think for my case, since I'm not spanning across multiple dependency groups at the moment it may be too much.

conditional-on-facet example here -> https://github.com/xenit-eu/start.xenit.eu/blob/master/initializr-generator/src/main/java/eu/xenit/alfred/initializr/generator/condition/OnRequestedFacetCondition.java

Thank you Toon Geens, I think this is cool. Maybe facets can be part of the ProjectDescription? But that feels weird as well.. Just thinking out loud. I see how retrieving the metadata is less than ideal since it pertains to the Initializr rather than to project generation. Please correct me if I'm wrong

I think what I may be having trouble grasping is when are conditionals appropriate versus having checks in a Customizer

Stéphane Nicoll
@snicoll
Yeah that analysis is spot on, the boundary between the two is a bit odd at the moment
I think the main reason is that the metadatat is the only module we haven’t rewritten when we’ve rebuilt the project generation engine from scratch
That’s why we have a Dependency for the purpose of the project generation and a Dependency with metadata element. Ideally, you should have access to the latter from the former.
(or something)
If stuff are spanning multiple dependency groups, I guess the @ConditionalOnDependencyGroup idea you had doesn’t work either then? I am confused
soutchay
@soutchay

If stuff are spanning multiple dependency groups, I guess the @ConditionalOnDependencyGroup idea you had doesn’t work either then? I am confused

sorry to clarify @ConditionalOnDependencyGroup works for me for now. It may just be a one off for my scenario though

Ruben Pahino
@rubasace
Hi guys, I'm trying to use this project for scaffolding my company's projects. I'm trying to add the autogeneration of some files that require some extra inputs from the user. Is there any documentation or example where I can see how to add extra fields (extending the InitializrMetadata class????)
soutchay
@soutchay
It sounds like you would want to have a custom ProjectRequest and ProjectDescription instead? I haven't done this personally but maybe this can help: https://docs.spring.io/initializr/docs/current/reference/html/#create-instance-advanced-config-custom-project-request
Ruben Pahino
@rubasace
That looks exactly like what I'm after. Sorry, I don't know how I missed that on the documentation :S
Stéphane Nicoll
@snicoll
Thanks @soutchay
soutchay
@soutchay
no problem! glad to be of help
soutchay
@soutchay

Hello again, I was looking at the initializr-generator-test and I was wondering what are some use cases where I would want to use the ProjectAssetTester instead of the ProjectGeneratorTester? Is it only when I'm generating anything that does not involve @ProjectGenerationConfiguration annotated classes?

Also, out of curiosity, how come @SpringBootTest was avoided for testing project generation? I initially started there and was referencing https://github.com/spring-io/start.spring.io/blob/master/start-site/src/test/java/io/spring/start/site/extension/AbstractExtensionTests.java before I noticed there was an initializr-generator-test module.

Thank you

Stéphane Nicoll
@snicoll
ProjectAssertTester is more fine grained, see Javadoc. It lets you pick up indivudal contributors and make sure they behave as you expect. ProjectGeneratorTester is the full thing and it detects all available contributors which is not something you may want when testing individual components
I didn’t understand your second question. If each test has its own setup, it’s not an integration test. And therefore @SpringBootTest shouldn’t be used. I should confess that AbstractExtensionTests is not ideal and should be reviewed at some point. We’re making sure that the correct behaviour is observed when all contributions are available. Soe more focused tests would be interesting in that module.
soutchay
@soutchay
Thanks! Regarding my second question, since I'm bringing in initializr-generator-spring, I found I needed to bring in almost everything to get a test to run to the point I thought my test may as well be an integration test with @SpringBootTest. Example setup I currently have:
        ProjectGeneratorTester projectGeneratorTester = new ProjectGeneratorTester()
                .withBean(InitializrMetadata.class,
                        () -> InitializrMetadataTestBuilder.withDefaults().build())
                .withConfiguration(InitializrConfiguration.class)
                .withIndentingWriterFactory()
                .withDirectory(directory);
soutchay
@soutchay

I think I'm missing something again... I would like to allow only certain dependencies depending on project type. Or another option is to prevent someone from selecting multiple dependencies from a dependency group. I feel like the first option seems to make more sense.

Is the proper way to do this to add logic to the InitializrMetadataUpdateStrategy? or should I even be doing something like this? I would like applications to only follow one paradigm instead of multiple

soutchay
@soutchay

After thinking some more about my second question, ProjectGeneratorTester and ProjectAssetTester make sense to test interaction between components. As far as integration tests go though, what would be a preferred method? Possibly making a MockMvc or RestTemplate call to /starters.zip? I do see some useful methods here: https://github.com/spring-io/initializr/blob/master/initializr-web/src/test/java/io/spring/initializr/web/AbstractInitializrIntegrationTests.java

Would it make sense to leverage some of the utility methods from AbstractInitializrIntegrationTests.java?

Stéphane Nicoll
@snicoll
I don’t understand why you’d need to call /starter.zip. You don’t need to test the library in your own code
sililau
@sililau
Version: 2.4.0-SNAPSHOT
implementation 'org.springframework.boot:spring-boot-starter-data-r2dbc'
implementation 'org.springframework.boot:spring-boot-starter-webflux'
runtimeOnly 'dev.miku:r2dbc-mysql'
runtimeOnly 'mysql:mysql-connector-java'
Error:
java.lang.NoSuchMethodError: reactor.netty.http.server.HttpServer.runOn(Lreactor/netty/resources/LoopResources;)
Andy Wilkinson
@wilkinsona
@sililau There are some breaking changes in the latest Reactor snapshots and it would appear that something has not yet adapted to them. Where is the NoSuchMethodError being thrown?
Or the necessary changes may have been made but you're using a cached snapshot. You may need to instruct Gradle to refresh your dependencies.
This doesn't have anything to do with Initializr, BTW, so this isn't really the right channel for this.
soutchay
@soutchay

I don’t understand why you’d need to call /starter.zip. You don’t need to test the library in your own code

I agree with not needing to test libraries. I suppose if that is the case then integration tests are unnecessary and tests leveraging ProjectGeneratorTester and ProjectAssetTester are sufficient.. I think that makes sense