The multiple test run makes perfect sense. The second round of test is performed against a clean checkout from the tag. That makes sure that the build is really reproducible. That's actually a HUGE win and we introduced this in maven for good reasons!
> What do you propose? Assume we split in 2 repos, you get the exact same > issue in the examples repo but need to build 2 repo in the release now, > right? No, the examples do NOT get released. They already get kind of half-excluded in our standard release. But just bei weird tricks like setting a different distributionMangement which does not exist, etc. > > Don't get that, you reduce openejb-core build removing examples which > depends on openejb-core? It is not correlated normally. Can you give a few > more words on that please? No the examples do not depend on openejb-core but most times on the result of the main build. Or a different version hereof. > Can you build master and commit having a green build with regression? yes. > so it gets worse. That's what i meant. It doesn't get worse. Because right now most committers don't even build with tests enabled because it takes so long. Any many of the tests did behave stochastic before I fixed them. And other tests only worked with the system being set to en_US. So people did solely rely on CI anyway it seems. I want to change this and make committers more often run the tests locally _before_ they commit. And of course have CI of main TomEE + afterwards TomEE-Examples for getting the CI quality as we have today. LieGrue, strub > Am 27.06.2018 um 11:35 schrieb Romain Manni-Bucau <[email protected]>: > > Le mer. 27 juin 2018 à 11:22, Mark Struberg <[email protected]> a > écrit : > >> Thanks for the feedback! >> >> >>>> * they break the maven-release-plugin, because they don't use the same >>>> version >>>> >>> >>> Moving it to another repo will not solve it since they must be >> independent >>> and not have a common parent to be copiable and runnable without >>> dependencies. >> >> Exactly that missing parent is the problem! >> If we do not have the examples in the TomEE repo then this problem simply >> goes away! >> And we do NOT release our examples anyway! >> The deploy is explicitly disabled (with a few dirty tricks). >> >> >>> Also I'm not sure we'll use the plugin anyway since it doesn't fit much >> big >>> projects and with git it is useless >> >> No, the maven-releas-plugin works perfectly fine even in huge projects. >> > > It is more about the time consumption with no gain due to the multiple test > run. > > >> The problem is that our current setup is really broken because those >> examples sub modules miss the back reference to the reactor build. >> >> >>> Each release manager should ensure it is bumped to next master version, >> we >>> can have missed it a bit but this is a bug we should fix. >> >> Most of them have been on different versions. Some 1.1-SNAPSHOT, some >> 1.7.3-SNAPSHOT, others even 1.0-SNAPSHOT. >> With other words: it was pretty much a mess because all the automation >> which maven provides was NOT used. Instead the releases seem to have been >> performed manually. >> > > Normally it is 1.0 (or 1.0.0) - SNAPSHOT, 1.1 can be a post release hack or > a need when some API has been broken (I have 2 cases in mind, no more) > > >> >> >> >>>> * We have many people who want to probably add samples without wanting >> to >>>> go through all the hassle to build full tomee >>>> >>> >>> This is the case by design since they are independent. >> >> This is exactly the shizophrenic situation. They are part of the build - >> but also not. It is really only half done right now. >> > > What do you propose? Assume we split in 2 repos, you get the exact same > issue in the examples repo but need to build 2 repo in the release now, > right? > > >> >> >>> I don't get what it changes here since if you drop 15mn you still have >>> something like 3h to run. >> >> Build gets reduced to 20 minutes over here. A big part is openejb-core, >> and of course also the TCKs. >> > > Don't get that, you reduce openejb-core build removing examples which > depends on openejb-core? It is not correlated normally. Can you give a few > more words on that please? > > >> >> >> >>> Anyaway if we go that path we can just contribute most of them back to >>> javaee_samples and only keep our specific ones. >> >> Would love to keep them here so we can tweak them as we need and can link >> to the examples on our site. >> > > Works for me, no strong opinion, was just thiking out loud. > > >> >>> To summarize it to make it very clear I'm +-0 (as really neutral since it >>> doesn't change anything at the end IMHO) to drop them IF (and only if) >> the >>> coverage is contributed back to the main project. >> >> The coverage doesn't get worse. It's then just split into two different >> CIs. >> > > Can you build master and commit having a green build with regression? yes. > so it gets worse. That's what i meant. > > >> Even better: we can have an EE6 samples which we can test against new and >> old containers. >> Plus an EE7 examples and EE8 examples project which can run against newer >> containers. >> > > We align our examples on the branch so not a big advantage from my window. > > >> >> But we certainly have to think about how to do the final setup. >> >> LieGrue, >> strub >> >> >>> Anfang der weitergeleiteten Nachricht: >>> >>> Von: Romain Manni-Bucau <[email protected]> >>> Betreff: Aw: [DISCUSS] Extract examples into own git repo >>> Datum: 27. Juni 2018 um 11:01:19 MESZ >>> An: [email protected] >>> Antwort an: [email protected] >>> >>> Hi Mark, >>> >>> think we already discuss it somewhere else but wrote again the points >>> inline if it has been missed >>> >>> 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. 27 juin 2018 à 10:48, Mark Struberg <[email protected]> >> a >>> écrit : >>> >>>> Hi folks! >>>> >>>> While trying to release TomEE-7.0.5 I figured that the Examples as part >> of >>>> the TomEE core project are really counter productive. >>>> >>>> * they break the maven-release-plugin, because they don't use the same >>>> version >>>> >>> >>> Moving it to another repo will not solve it since they must be >> independent >>> and not have a common parent to be copiable and runnable without >>> dependencies. They should also depend on current tomee snapshot and be >>> aligned on tomee lifecycle for that reason(cause they can show feature we >>> just added on master). Not sure how you plan to solve it in another repo >>> but doable. >>> >>> Also I'm not sure we'll use the plugin anyway since it doesn't fit much >> big >>> projects and with git it is useless to go through the full lifecycle (you >>> use local branches/tags you push later so no potential conflicts like you >>> can have with svn). You can save half of the release time not using it >> ;). >>> >>> >>>> * They pollute the build (samples alone take 15 minutes of our build), >>>> which might lower contributions >>>> >>> >>> See it the other way around. It is part of the build cause mainly used as >>> integration tests for a big part of them so if you drop them you must >> move >>> all the tests to the main build before doing it which will lead to just >>> save ~5mn on 3h of build (CI). >>> >>> >>>> * They are bound to a specific tomee version, so they cannot easily be >>>> tested against another version >>>> >>> >>> Each release manager should ensure it is bumped to next master version, >> we >>> can have missed it a bit but this is a bug we should fix. >>> >>> >>>> * We have many people who want to probably add samples without wanting >> to >>>> go through all the hassle to build full tomee >>>> >>> >>> This is the case by design since they are independent. >>> >>> >>>> >>>> Of course there are also downsides, mainly: >>>> * by having the samples as part of our build we also have improved test >>>> coverage. >>>> >>>> Well, since right now almost nobody runs the tests when building TomEE >>>> (but instead rely on our CI, because it takes so long) it makes no >>>> difference anyway. I'd rather have a core project with decently good >> test >>>> coverage - and people also run it - than having a bit better coverage >>>> which nobody runs. >>>> >>> >>> I don't get what it changes here since if you drop 15mn you still have >>> something like 3h to run. >>> >>> >>>> >>>> So I propose to move the Examples to a separate repo and add a separate >> CI >>>> for it. >>>> >>> >>> Anyaway if we go that path we can just contribute most of them back to >>> javaee_samples and only keep our specific ones. >>> >>> >>>> Of course we should look at how to set it up so we can have samples for >>>> multiple EE versions. >>>> >>> >>> Our site is not versionned (think we said it was too costly to maintain >> to >>> do it earlier, not sure we still stand on that point) so not sure it is >>> important. However we must still generate the example pages etc in our >> site >>> generation so if they move we should ensure it is not broken. >>> >>> >>>> >>>> wdyt? >>>> >>> >>> To summarize it to make it very clear I'm +-0 (as really neutral since it >>> doesn't change anything at the end IMHO) to drop them IF (and only if) >> the >>> coverage is contributed back to the main project. >>> >>> >>>> >>>> LieGrue, >>>> strub
