You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Mark Struberg <st...@yahoo.de.INVALID> on 2018/06/27 08:48:09 UTC
[DISCUSS] Extract examples into own git repo
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
* They pollute the build (samples alone take 15 minutes of our build), which might lower contributions
* They are bound to a specific tomee version, so they cannot easily be tested against another version
* We have many people who want to probably add samples without wanting to go through all the hassle to build full tomee
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.
So I propose to move the Examples to a separate repo and add a separate CI for it.
Of course we should look at how to set it up so we can have samples for multiple EE versions.
wdyt?
LieGrue,
strub
Re: [DISCUSS] Extract examples into own git repo
Posted by Gurkan Erdogdu <cg...@gmail.com>.
Hi Mark
++1 for this. Examples must not be a test suite, and it is a great idea to
separate them from the main source code. It must be independently build and
execute from main TomEE codebase.
Best
Gurkan
On Wed, Jun 27, 2018 at 9:48 AM, Mark Struberg <st...@yahoo.de.invalid>
wrote:
> 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
> * They pollute the build (samples alone take 15 minutes of our build),
> which might lower contributions
> * They are bound to a specific tomee version, so they cannot easily be
> tested against another version
> * We have many people who want to probably add samples without wanting to
> go through all the hassle to build full tomee
>
> 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.
>
> So I propose to move the Examples to a separate repo and add a separate CI
> for it.
> Of course we should look at how to set it up so we can have samples for
> multiple EE versions.
>
> wdyt?
>
> LieGrue,
> strub
>
>
Re: [DISCUSS] Extract examples into own git repo
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 27 juin 2018 à 11:59, Mark Struberg <st...@yahoo.de.invalid> a
écrit :
> 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!
>
Well with git you create the branch then run tests and then you don't have
to do it agan ever since the hash is constant so you just loose time
redoing it. This is why gitflow doesnt redo it for example.
You would need to redo it only if you mutate the branch/tag which is a
biggest issue if done anyway.
>
> > 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.
>
Right but their tests are passed in the release process (and the release
manager generally ensures they run on the release branch).
>
>
> >
> > 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.
>
My 2cts is that you will loose time going that way. When you do a fix you
will not wait 3h to ensure it passes. Even you Mark never run
-Pall-adapters which means you have ~1/3 of the actual coverage for several
modules. We did a fastbuild profile to solve that local build time issue a
long time ago. Maybe just invest in making it better?
>
> LieGrue,
> strub
>
>
> > Am 27.06.2018 um 11:35 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Le mer. 27 juin 2018 à 11:22, Mark Struberg <st...@yahoo.de.invalid>
> 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 <rm...@gmail.com>
> >>> Betreff: Aw: [DISCUSS] Extract examples into own git repo
> >>> Datum: 27. Juni 2018 um 11:01:19 MESZ
> >>> An: dev@tomee.apache.org
> >>> Antwort an: dev@tomee.apache.org
> >>>
> >>> 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 <struberg@yahoo.de.invalid
> >
> >> 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
>
>
Re: [DISCUSS] Extract examples into own git repo
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <rm...@gmail.com>:
>
> Le mer. 27 juin 2018 à 11:22, Mark Struberg <st...@yahoo.de.invalid> 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 <rm...@gmail.com>
>>> Betreff: Aw: [DISCUSS] Extract examples into own git repo
>>> Datum: 27. Juni 2018 um 11:01:19 MESZ
>>> An: dev@tomee.apache.org
>>> Antwort an: dev@tomee.apache.org
>>>
>>> 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 <st...@yahoo.de.invalid>
>> 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
Re: [DISCUSS] Extract examples into own git repo
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 27 juin 2018 à 11:22, Mark Struberg <st...@yahoo.de.invalid> 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 <rm...@gmail.com>
> > Betreff: Aw: [DISCUSS] Extract examples into own git repo
> > Datum: 27. Juni 2018 um 11:01:19 MESZ
> > An: dev@tomee.apache.org
> > Antwort an: dev@tomee.apache.org
> >
> > 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 <st...@yahoo.de.invalid>
> 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
> >>
> >>
>
>
Fwd: [DISCUSS] Extract examples into own git repo
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <rm...@gmail.com>
> Betreff: Aw: [DISCUSS] Extract examples into own git repo
> Datum: 27. Juni 2018 um 11:01:19 MESZ
> An: dev@tomee.apache.org
> Antwort an: dev@tomee.apache.org
>
> 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 <st...@yahoo.de.invalid> 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
>>
>>
Re: [DISCUSS] Extract examples into own git repo
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <st...@yahoo.de.invalid> 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
>
>