Not sure I understand it well Tibor, do you encourage to multiply the number of potential solutions to request more time to contributor to see how to do things? Don't think it is good, a single simple solution sounds more promising - once again from my past experience.
Once again Tibor, all I'm writing is about current state and my experience, I don't want to block anything but I don't want we do choices on some "potential" gain and not "validable" hypothesis, if we have a doubt we should stay simple IMHO. When I first wrote a maven plugin I checked out the solution to test it and there was several options, inconsistent between plugins and it was not helping me to move forward. Here we have the opportunity to solve that kind of issues for new contributors and I think it is taking a great direction. It does not enforce to use @MavenIT but it does not document how to do it 5 different ways which is good. That said I guess once we have it feature complete we can just do a vote with a "majority wins" rules and it would be good enough for such a solution, we don't need to all fully agree on such low level topic I think. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 30 oct. 2019 à 17:26, Tibor Digana <tibordig...@apache.org> a écrit : > Romain, the Java has not made any significant progress in language after > Java 9. Yes, some JVM features in J13 were really great but not in > language. > All fixes about switch-case in several versions, strings, preliminary > feature. Nothing very progressive for developers! And I think the frequent > releases/6months were too big hammer. > The Java should think about these frequent releases because f/w do not > adapt fast and the developer has no benefit from dropped or preliminary > features. > For instance for me J13 has sense oly because of JVM feature JEP351 but not > because of language and all these dances around ASM versions are just > because of too frequent Java release with minimum value. > > IMO these developers in Maven can use multiple languages and this will be > then attractive project for the contributors. > Here Karl developed some new f/w and it will take some time to complete it > and use it in the Maven ITs. Until then the Spock will change and Java as > well. > So he can decide what to use and maybe he will do it so well that JUnit5 > and Spock can be used together. > > On Wed, Oct 30, 2019 at 5:03 PM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > @Tibor: do you agree we write the tests with chai (js)? It is the same to > > use groovy for a java dev today since java caught up its lateness. Not > > stacking layers and avoiding useless abstractions is the best way to > enable > > people to contribute from my experience. As soon as you add a layer which > > has a step people can find blockers to go upon it will not work (to be > > explicit here you add a language blocker + an API blocker + a change in > > native maven conventions which is likely bad for us). > > Lastly, my point about the java issues is not that it can't be fixed, > > people there are good enough to fix them all releases after releases, it > is > > just that it delays the availability and adoption of spock which means it > > is not mainstream so contributor friendly. > > So picking spock woudnt hit our goal. > > > > Le mer. 30 oct. 2019 à 16:58, Tibor Digana <tibordig...@apache.org> a > > écrit : > > > > > Romain, I am glad that you are with me. > > > Attracting the contributors! > > > > > > I hope we all voted for Java 8 sources in Maven Core. > > > And Spock is the same story. > > > > > > Java is the like C++ old style. > > > Lambda makes this language more moderns a bit. > > > > > > Regarding issues with Java 14, all can be fixed, just give the Spock > the > > > chance! > > > > > > > > > > > > On Wed, Oct 30, 2019 at 4:52 PM Romain Manni-Bucau < > > rmannibu...@gmail.com> > > > wrote: > > > > > > > @Tibor: one goal we should focus on on any new feature is to enable > us > > to > > > > attract more new contributors, spock has the disadvantage to not be > > > > mainstream at all + to be on groovy which has some issues to support > > > recent > > > > java version so it will not help it to be more adopted, therefore I > > guess > > > > jupiter is not really a question these days whatever we can think > about > > > it. > > > > > > > > Romain Manni-Bucau > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > > <http://rmannibucau.wordpress.com> | Github < > > > > https://github.com/rmannibucau> | > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > > < > > > > > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > > > > > > > > Le mer. 30 oct. 2019 à 16:16, Tibor Digana <tibordig...@apache.org> > a > > > > écrit : > > > > > > > > > Karl, where you define CLI command in each test? > > > > > Regarding the f/w you have selected. If I had to decide between > > JUnit5 > > > or > > > > > Groovy/Spock, I would decide for Spock. > > > > > > > > > > On Tue, Oct 29, 2019 at 9:47 PM Karl Heinz Marbaise < > > khmarba...@gmx.de > > > > > > > > > wrote: > > > > > > > > > > > Hi to all, > > > > > > > > > > > > I've invested some time to get a thing working in a different way > > > which > > > > > > nags me for a long time. > > > > > > > > > > > > Integration tests for maven plugins and for maven core... > > > > > > > > > > > > So created a prototype based on a JUnit Jupiter extension. > > > > > > > > > > > > The following is the JUnit Jupiter extension (currently very > hacky > > > > code; > > > > > > not intended to win a competition for good code!) > > > > > > > > > > > > https://github.com/khmarbaise/maven-it-extension > > > > > > > > > > > > which contains some documentation which is of course not ready > > yet... > > > > > > but the implementation and usage (see maven-ear-plugin) gives me > at > > > the > > > > > > moment already a very good impression how easy it can be to write > > > > > > integration tests for a maven plugin etc. > > > > > > > > > > > > Example from the docs(not 100% working like that yet): > > > > > > > > > > > > @MavenIT > > > > > > class FirstMavenIT { > > > > > > > > > > > > @MavenTest > > > > > > void the_first_test_case(MavenProjectResult result) { > > > > > > assertThat(result) > > > > > > .build() > > > > > > .isSuccessful() > > > > > > .and() > > > > > > .project() > > > > > > .hasTarget() > > > > > > .withEarFile() > > > > > > .containsOnlyOnce("META-INF/MANIFEST.MF") > > > > > > .log() > > > > > > .info().contains("Writing data to file") > > > > > > .cache() > > > > > > .withEarFile("G:A:V") > > > > > > .withPomFile("G:A:V") > > > > > > .withMetadata().contains("xxx"); > > > > > > } > > > > > > } > > > > > > > > > > > > > > > > > > I created a branch "maven-it-extension" on Maven EAR Plugin which > > > shows > > > > > > that it can be used in combination with > > maven-invoker-plugin:install > > > > > > goal and using maven-failsafe-plugin to run the tests for > > > > > > maven-ear-plugin (some of them at the moment. Not migrated all of > > > them > > > > > > yet). > > > > > > > > > > > > Example which already works: > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/maven-ear-plugin/blob/maven-it-extension/src/test/java/org/apache/maven/plugins/ear/it/EARIT.java > > > > > > > > > > > > > > > > > > WDYT ? > > > > > > > > > > > > Kind regards > > > > > > Karl Heinz Marbaise > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > >
