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. 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. >> * 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. > 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. > 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. > 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. 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. 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 >> >>
