Re: CI for DeltaSpike?

2017-12-18 Thread Thomas Andraschko 
Reverted my commit for now, will check it again in 2.0.
Tests are looking now good again with TomEE.

2017-12-01 19:32 GMT+01:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> @john
> iIRC ASM should be shaded, not sure why it happends
>
> Am Freitag, 1. Dezember 2017 schrieb Matej Novotny :
>
>> Doesn't look like the error I saw, for me deployment was OK but the test
>> failed (there was no redirection done on button click in the selenium test
>> so it then crashed with NoSuchElementException).
>> Haven't really dug deeper as I am rather unfamiliar with that module,
>> just found out what commits caused that.
>>
>> What I saw was similar to what TomEE fails with -
>> https://builds.apache.org/view/A-D/view/DeltaSpike/job/Delta
>> Spike_TomEE/1215/org.apache.deltaspike.modules$deltaspike-
>> jsf-module-impl/
>>
>> Matej
>>
>> - Original Message -
>> > From: "John D. Ament" <johndam...@apache.org>
>> > To: dev@deltaspike.apache.org
>> > Sent: Friday, December 1, 2017 4:40:24 PM
>> > Subject: Re: CI for DeltaSpike?
>> >
>> > I'm not sure if its the cause or not, but I see this when running the
>> > failing tests on wildfly 10.1
>> >
>> > 10:31:46,124 WARN  [org.jboss.modules] (Weld Thread Pool -- 6) Failed to
>> > define class
>> > org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator$1 in
>> > Module "deployment.nav-event-uc001.war:main" from Service Module
>> Loader:
>> > java.lang.NoClassDefFoundError: Failed to link
>> > org/apache/deltaspike/proxy/impl/AsmDeltaSpikeProxyClassGenerator$1
>> (Module
>> > "deployment.nav-event-uc001.war:main" from Service Module Loader):
>> > org/objectweb/asm/ClassVisitor
>> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> Method)
>> > at
>> > sun.reflect.NativeConstructorAccessorImpl.newInstance(Native
>> ConstructorAccessorImpl.java:62)
>> > at
>> > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(De
>> legatingConstructorAccessorImpl.java:45)
>> > at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>> > at
>> > org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassL
>> oader.java:446)
>> > at
>> > org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleCla
>> ssLoader.java:274)
>> > at
>> > org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleC
>> lassLoader.java:78)
>> > at org.jboss.modules.Module.loadModuleClass(Module.java:606)
>> > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoa
>> der.java:190)
>> > at
>> > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnch
>> ecked(ConcurrentClassLoader.java:363)
>> > at
>> > org.jboss.modules.ConcurrentClassLoader.performLoadClass(Con
>> currentClassLoader.java:351)
>> > at
>> > org.jboss.modules.ConcurrentClassLoader.loadClass(Concurrent
>> ClassLoader.java:93)
>> > at
>> > org.jboss.as.weld.WeldModuleResourceLoader.classForName(Weld
>> ModuleResourceLoader.java:68)
>> > at
>> > org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadClass(Annot
>> atedTypeLoader.java:65)
>> > at
>> > org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedTy
>> pe(AnnotatedTypeLoader.java:60)
>> > at
>> > org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.loadAnnotat
>> edType(FastAnnotatedTypeLoader.java:96)
>> > at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:98)
>> > at
>> > org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(
>> ConcurrentBeanDeployer.java:65)
>> > at
>> > org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(
>> ConcurrentBeanDeployer.java:62)
>> > at
>> > org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(It
>> erativeWorkerTaskFactory.java:63)
>> > at
>> > org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(It
>> erativeWorkerTaskFactory.java:56)
>> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> > at
>> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1149)
>> > at
>> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:624)
>> > at java.lang.Thread.run(Thread.java:748)
>> > at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>> >
>> > 10:31:46,125 INFO  [org.jboss.weld.Bootstrap

Re: CI for DeltaSpike?

2017-12-01 Thread Thomas Andraschko 
@john
iIRC ASM should be shaded, not sure why it happends

Am Freitag, 1. Dezember 2017 schrieb Matej Novotny :

> Doesn't look like the error I saw, for me deployment was OK but the test
> failed (there was no redirection done on button click in the selenium test
> so it then crashed with NoSuchElementException).
> Haven't really dug deeper as I am rather unfamiliar with that module, just
> found out what commits caused that.
>
> What I saw was similar to what TomEE fails with -
> https://builds.apache.org/view/A-D/view/DeltaSpike/job/
> DeltaSpike_TomEE/1215/org.apache.deltaspike.modules$
> deltaspike-jsf-module-impl/
>
> Matej
>
> - Original Message -
> > From: "John D. Ament" <johndam...@apache.org <javascript:;>>
> > To: dev@deltaspike.apache.org <javascript:;>
> > Sent: Friday, December 1, 2017 4:40:24 PM
> > Subject: Re: CI for DeltaSpike?
> >
> > I'm not sure if its the cause or not, but I see this when running the
> > failing tests on wildfly 10.1
> >
> > 10:31:46,124 WARN  [org.jboss.modules] (Weld Thread Pool -- 6) Failed to
> > define class
> > org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator$1 in
> > Module "deployment.nav-event-uc001.war:main" from Service Module Loader:
> > java.lang.NoClassDefFoundError: Failed to link
> > org/apache/deltaspike/proxy/impl/AsmDeltaSpikeProxyClassGenerator$1
> (Module
> > "deployment.nav-event-uc001.war:main" from Service Module Loader):
> > org/objectweb/asm/ClassVisitor
> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> > at
> > sun.reflect.NativeConstructorAccessorImpl.newInstance(
> NativeConstructorAccessorImpl.java:62)
> > at
> > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
> DelegatingConstructorAccessorImpl.java:45)
> > at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> > at
> > org.jboss.modules.ModuleClassLoader.defineClass(
> ModuleClassLoader.java:446)
> > at
> > org.jboss.modules.ModuleClassLoader.loadClassLocal(
> ModuleClassLoader.java:274)
> > at
> > org.jboss.modules.ModuleClassLoader$1.loadClassLocal(
> ModuleClassLoader.java:78)
> > at org.jboss.modules.Module.loadModuleClass(Module.java:606)
> > at org.jboss.modules.ModuleClassLoader.findClass(
> ModuleClassLoader.java:190)
> > at
> > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(
> ConcurrentClassLoader.java:363)
> > at
> > org.jboss.modules.ConcurrentClassLoader.performLoadClass(
> ConcurrentClassLoader.java:351)
> > at
> > org.jboss.modules.ConcurrentClassLoader.loadClass(
> ConcurrentClassLoader.java:93)
> > at
> > org.jboss.as.weld.WeldModuleResourceLoader.classForName(
> WeldModuleResourceLoader.java:68)
> > at
> > org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadClass(
> AnnotatedTypeLoader.java:65)
> > at
> > org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedType(
> AnnotatedTypeLoader.java:60)
> > at
> > org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.loadAnnotatedType(
> FastAnnotatedTypeLoader.java:96)
> > at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:98)
> > at
> > org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.
> doWork(ConcurrentBeanDeployer.java:65)
> > at
> > org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.
> doWork(ConcurrentBeanDeployer.java:62)
> > at
> > org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(
> IterativeWorkerTaskFactory.java:63)
> > at
> > org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(
> IterativeWorkerTaskFactory.java:56)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1149)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:624)
> > at java.lang.Thread.run(Thread.java:748)
> > at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> >
> > 10:31:46,125 INFO  [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 1)
> > WELD-000119: Not generating any bean definitions from
> > org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator
> because
> > of underlying class loading error: Type org.objectweb.asm.ClassVisitor
> from
> > [Module "deployment.nav-event-uc001.war:main" from Service Module
> Loader]
> > not found.  If this is unexpected, enable DEBUG logging to see the full
> > error.
> > 10:31:46,126 INFO  [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 6)
> > WELD-000

Re: CI for DeltaSpike?

2017-12-01 Thread Matej Novotny 
Doesn't look like the error I saw, for me deployment was OK but the test failed 
(there was no redirection done on button click in the selenium test so it then 
crashed with NoSuchElementException).
Haven't really dug deeper as I am rather unfamiliar with that module, just 
found out what commits caused that.

What I saw was similar to what TomEE fails with - 
https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike_TomEE/1215/org.apache.deltaspike.modules$deltaspike-jsf-module-impl/

Matej

- Original Message -
> From: "John D. Ament" <johndam...@apache.org>
> To: dev@deltaspike.apache.org
> Sent: Friday, December 1, 2017 4:40:24 PM
> Subject: Re: CI for DeltaSpike?
> 
> I'm not sure if its the cause or not, but I see this when running the
> failing tests on wildfly 10.1
> 
> 10:31:46,124 WARN  [org.jboss.modules] (Weld Thread Pool -- 6) Failed to
> define class
> org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator$1 in
> Module "deployment.nav-event-uc001.war:main" from Service Module Loader:
> java.lang.NoClassDefFoundError: Failed to link
> org/apache/deltaspike/proxy/impl/AsmDeltaSpikeProxyClassGenerator$1 (Module
> "deployment.nav-event-uc001.war:main" from Service Module Loader):
> org/objectweb/asm/ClassVisitor
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:446)
> at
> org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274)
> at
> org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78)
> at org.jboss.modules.Module.loadModuleClass(Module.java:606)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> at
> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
> at
> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
> at
> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
> at
> org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68)
> at
> org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadClass(AnnotatedTypeLoader.java:65)
> at
> org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedType(AnnotatedTypeLoader.java:60)
> at
> org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.loadAnnotatedType(FastAnnotatedTypeLoader.java:96)
> at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:98)
> at
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:65)
> at
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:62)
> at
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
> at
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 
> 10:31:46,125 INFO  [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 1)
> WELD-000119: Not generating any bean definitions from
> org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator because
> of underlying class loading error: Type org.objectweb.asm.ClassVisitor from
> [Module "deployment.nav-event-uc001.war:main" from Service Module Loader]
> not found.  If this is unexpected, enable DEBUG logging to see the full
> error.
> 10:31:46,126 INFO  [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 6)
> WELD-000119: Not generating any bean definitions from
> org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator$1 because
> of underlying class loading error: Type Failed to link
> org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator$1 (Module
> "deployment.nav-event-uc001.war:main" from Service Module Loader):
> org.objectweb.asm.ClassVisitor not found.  If this is unexpected, enable
> DEBUG logging to see the full error.
> 
> If that's the case, then it should be as simple as adding the missing
> libraries.
> 
> On Fri, Dec 1, 2017 at 6:52 AM Thomas Andraschko <
> andraschko.tho...@gmail.com> wrote:
> 
> > @mate

Re: CI for DeltaSpike?

2017-12-01 Thread John D. Ament 
t; present,
> > > where the author apparently didn't even execute the tests.
> > > Checking this before release means you bump into problems with issues
> > > which were "fixed" six months ago.
> > > Hence I am suggesting whether we shouldn't look into some more flexible
> > > approach.
> > > I know Travis still isn't quite the thing beucase of the structure, I
> am
> > > just trying to start a discussion here and see how people view thing -
> > > maybe I am just weird with my requirements :)
> > >
> > > > back then i also added ci-jobs for new owb/weld releases immediately.
> > > > (it looks like nobody took over that part.)
> > >
> > > Would be great if this was still done, every new weld release is
> > announced
> > > directly on DS mailing list, so it's just about updating it.
> > >
> > >
> > > Matej
> > >
> > > - Original Message -
> > > > From: "Gerhard Petracek" <gpetra...@apache.org <javascript:;>>
> > > > To: dev@deltaspike.apache.org <javascript:;>
> > > > Sent: Thursday, November 30, 2017 3:32:04 PM
> > > > Subject: Re: CI for DeltaSpike?
> > > >
> > > > hi matej,
> > > >
> > > > one of the (manual) steps for a release is to check those results
> > > (before a
> > > > release gets started at all).
> > > > i'm not sure if others are still following it. at the time i did the
> > > > releases, it was a mandatory step.
> > > > back then i also added ci-jobs for new owb/weld releases immediately.
> > > > (it looks like nobody took over that part.)
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2017-11-30 14:59 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com
> > <javascript:;>>:
> > > >
> > > > > Sorry Matej, I don't get how Travis would help since you can do the
> > > > > same with jenkins which is already configured.
> > > > >
> > > > > Having the default build running on both weld and OWB would be more
> > > > > beneficial IMHO, but it is just the opinion from my side of the
> fence
> > > > > and experience.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> > > > >
> > > > >
> > > > > 2017-11-30 14:57 GMT+01:00 Matej Novotny <manov...@redhat.com
> > <javascript:;>>:
> > > > > > Thanks, but it was more of a rhetorical question (you saved me
> some
> > > > > digging though).
> > > > > > Still my claim holds true, nobody cares about them much. They
> must
> > > have
> > > > > been failing for quite some time now
> > > > > > Not to mention they aren't even updated to latest Weld version
> (or
> > > > > WildFly version for that matter).
> > > > > >
> > > > > >
> > > > > > Matej
> > > > > >
> > > > > > - Original Message -
> > > > > >> From: "Romain Manni-Bucau" <rmannibu...@gmail.com
> <javascript:;>>
> > > > > >> To: dev@deltaspike.apache.org <javascript:;>
> > > > > >> Sent: Wednesday, November 29, 2017 5:03:02 PM
> > > > > >> Subject: Re: CI for DeltaSpike?
> > > > > >>
> > > > > >> Hi Matej,
> > > > > >>
> > > > > >> they are all on the ASF jenkins:
> > > > > >> https://builds.apache.org/view/A-D/view/DeltaSpike/
> > > > > >>
> > > > > >> Romain Manni-Bucau
> > > > > >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> > > > > >>
> > > > > >>
> > > > > >> 2017-11-29 16:47 GMT+01:00 Matej Novotny <manov...@redhat.com
> > <javascript:;>>:
> > > > > >> > Hello
> > > > > >> >
> > > > > >> > I wanted to bring up a topic of CI (Continuous Irritation -
> eh,
> > I
> > > > > meant
> > > > > >> > Integration OFC) and DeltaSpike.
> > > > > >> > Apparently, there is no such thing now and even while some CI
>

Re: CI for DeltaSpike?

2017-12-01 Thread John D. Ament 
The main issues are that we're all independent contributors to DS, all with
the same level of rights to write to the repo.  We typically don't do PRs.
We actually do have a PR job in Jenkins for those external parties that do
raise PRs ->
https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike-PR-Builder/

As for the state of the builds, agreed that it's a pain point.  We have too
many permutations of our tests, and it's pretty hard to test all of them
locally.  We need to come up with either a definitive short list of tests
to always run, or figure out a way to better modularize DeltaSpike to limit
the impacts.

I do still think it's worthwhile to re envision our pipeline to have better
control over what tests are run and how they are managed.

John

On Wed, Nov 29, 2017 at 10:47 AM Matej Novotny  wrote:

> Hello
>
> I wanted to bring up a topic of CI (Continuous Irritation - eh, I meant
> Integration OFC) and DeltaSpike.
> Apparently, there is no such thing now and even while some CI jobs exist
> (where are they, anyway?), nobody really pays attention to them.
> I mean those for Weld ones must have been failing for few months and yet
> the JIRAs causing that were happily marked as Resolved.
> Meaning whoever fixed that probably only ran smoke tests with OWB.
>
> Today I noticed there is going to be a release soon and so I quikly went
> to check how the build/tests fare with Weld profiles.
> Turned out to be a disaster. So I then have to spend considerable time
> backtracking the changes and figuring out the actual problem.
> And it's not the first time this happened either.
>
> Therefore I wanted to bring up the topic of CI to avoid this in the
> future. The ideal scenario is sending PRs and having them checked *before*
> merging - obviously not an option here.
> The GH repo is but a mirror (something we have to stick to I presume)
> which makes it more complex, but still, it should be possible to set up a
> Travis build on GH master which will execute after every sync.
> That way the failures would be readily visible (via the travis status
> "button").
> In order to discover most problems there is no need for a complete test
> matrix, it would do to just have two version of OWB and Weld without EE
> container (with just the Arq. one).
>
>
> A penny for your thoughts?
>
>
> Regards
> Matej
>

Re: CI for DeltaSpike?

2017-12-01 Thread Thomas Andraschko 
@matej
You also reopened a issue that i created.
I'm currently in brasil, so i dont have time to look at it.
I removed this call as its actually not required and the wrapping in
PrimeFaces works fine. Not sure why it breaks navigation but we can simple
revert it for this release.

Am Freitag, 1. Dezember 2017 schrieb Gerhard Petracek :

> hi matej,
>
> imo the main point here is that in the past we received too many wrong
> failures and almost no commit really broke the backward compatibility.
>
> regards,
> gerhard
>
>
>
> 2017-12-01 11:49 GMT+01:00 Matej Novotny <manov...@redhat.com
> <javascript:;>>:
>
> > Hi Gerhard,
> >
> > > i'm not sure if others are still following it. at the time i did the
> > > releases, it was a mandatory step.
> >
> > Yes, I hope nobody releases without actually testing it at all.
> > But this check IMO comes too late - there are multiple "fixes" present,
> > where the author apparently didn't even execute the tests.
> > Checking this before release means you bump into problems with issues
> > which were "fixed" six months ago.
> > Hence I am suggesting whether we shouldn't look into some more flexible
> > approach.
> > I know Travis still isn't quite the thing beucase of the structure, I am
> > just trying to start a discussion here and see how people view thing -
> > maybe I am just weird with my requirements :)
> >
> > > back then i also added ci-jobs for new owb/weld releases immediately.
> > > (it looks like nobody took over that part.)
> >
> > Would be great if this was still done, every new weld release is
> announced
> > directly on DS mailing list, so it's just about updating it.
> >
> >
> > Matej
> >
> > - Original Message -
> > > From: "Gerhard Petracek" <gpetra...@apache.org <javascript:;>>
> > > To: dev@deltaspike.apache.org <javascript:;>
> > > Sent: Thursday, November 30, 2017 3:32:04 PM
> > > Subject: Re: CI for DeltaSpike?
> > >
> > > hi matej,
> > >
> > > one of the (manual) steps for a release is to check those results
> > (before a
> > > release gets started at all).
> > > i'm not sure if others are still following it. at the time i did the
> > > releases, it was a mandatory step.
> > > back then i also added ci-jobs for new owb/weld releases immediately.
> > > (it looks like nobody took over that part.)
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2017-11-30 14:59 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com
> <javascript:;>>:
> > >
> > > > Sorry Matej, I don't get how Travis would help since you can do the
> > > > same with jenkins which is already configured.
> > > >
> > > > Having the default build running on both weld and OWB would be more
> > > > beneficial IMHO, but it is just the opinion from my side of the fence
> > > > and experience.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> > > >
> > > >
> > > > 2017-11-30 14:57 GMT+01:00 Matej Novotny <manov...@redhat.com
> <javascript:;>>:
> > > > > Thanks, but it was more of a rhetorical question (you saved me some
> > > > digging though).
> > > > > Still my claim holds true, nobody cares about them much. They must
> > have
> > > > been failing for quite some time now
> > > > > Not to mention they aren't even updated to latest Weld version (or
> > > > WildFly version for that matter).
> > > > >
> > > > >
> > > > > Matej
> > > > >
> > > > > - Original Message -
> > > > >> From: "Romain Manni-Bucau" <rmannibu...@gmail.com <javascript:;>>
> > > > >> To: dev@deltaspike.apache.org <javascript:;>
> > > > >> Sent: Wednesday, November 29, 2017 5:03:02 PM
> > > > >> Subject: Re: CI for DeltaSpike?
> > > > >>
> > > > >> Hi Matej,
> > > > >>
> > > > >> they are all on the ASF jenkins:
> > > > >> https://builds.apache.org/view/A-D/view/DeltaSpike/
> > > > >>
> > > > >> Romain Manni-Bucau
> > > > >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> > > > >>
> > > >

Re: CI for DeltaSpike?

2017-12-01 Thread Gerhard Petracek 
hi matej,

imo the main point here is that in the past we received too many wrong
failures and almost no commit really broke the backward compatibility.

regards,
gerhard



2017-12-01 11:49 GMT+01:00 Matej Novotny <manov...@redhat.com>:

> Hi Gerhard,
>
> > i'm not sure if others are still following it. at the time i did the
> > releases, it was a mandatory step.
>
> Yes, I hope nobody releases without actually testing it at all.
> But this check IMO comes too late - there are multiple "fixes" present,
> where the author apparently didn't even execute the tests.
> Checking this before release means you bump into problems with issues
> which were "fixed" six months ago.
> Hence I am suggesting whether we shouldn't look into some more flexible
> approach.
> I know Travis still isn't quite the thing beucase of the structure, I am
> just trying to start a discussion here and see how people view thing -
> maybe I am just weird with my requirements :)
>
> > back then i also added ci-jobs for new owb/weld releases immediately.
> > (it looks like nobody took over that part.)
>
> Would be great if this was still done, every new weld release is announced
> directly on DS mailing list, so it's just about updating it.
>
>
> Matej
>
> - Original Message -
> > From: "Gerhard Petracek" <gpetra...@apache.org>
> > To: dev@deltaspike.apache.org
> > Sent: Thursday, November 30, 2017 3:32:04 PM
> > Subject: Re: CI for DeltaSpike?
> >
> > hi matej,
> >
> > one of the (manual) steps for a release is to check those results
> (before a
> > release gets started at all).
> > i'm not sure if others are still following it. at the time i did the
> > releases, it was a mandatory step.
> > back then i also added ci-jobs for new owb/weld releases immediately.
> > (it looks like nobody took over that part.)
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2017-11-30 14:59 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >
> > > Sorry Matej, I don't get how Travis would help since you can do the
> > > same with jenkins which is already configured.
> > >
> > > Having the default build running on both weld and OWB would be more
> > > beneficial IMHO, but it is just the opinion from my side of the fence
> > > and experience.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> > >
> > >
> > > 2017-11-30 14:57 GMT+01:00 Matej Novotny <manov...@redhat.com>:
> > > > Thanks, but it was more of a rhetorical question (you saved me some
> > > digging though).
> > > > Still my claim holds true, nobody cares about them much. They must
> have
> > > been failing for quite some time now
> > > > Not to mention they aren't even updated to latest Weld version (or
> > > WildFly version for that matter).
> > > >
> > > >
> > > > Matej
> > > >
> > > > - Original Message -
> > > >> From: "Romain Manni-Bucau" <rmannibu...@gmail.com>
> > > >> To: dev@deltaspike.apache.org
> > > >> Sent: Wednesday, November 29, 2017 5:03:02 PM
> > > >> Subject: Re: CI for DeltaSpike?
> > > >>
> > > >> Hi Matej,
> > > >>
> > > >> they are all on the ASF jenkins:
> > > >> https://builds.apache.org/view/A-D/view/DeltaSpike/
> > > >>
> > > >> Romain Manni-Bucau
> > > >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> > > >>
> > > >>
> > > >> 2017-11-29 16:47 GMT+01:00 Matej Novotny <manov...@redhat.com>:
> > > >> > Hello
> > > >> >
> > > >> > I wanted to bring up a topic of CI (Continuous Irritation - eh, I
> > > meant
> > > >> > Integration OFC) and DeltaSpike.
> > > >> > Apparently, there is no such thing now and even while some CI jobs
> > > exist
> > > >> > (where are they, anyway?), nobody really pays attention to them.
> > > >> > I mean those for Weld ones must have been failing for few months
> and
> > > yet
> > > >> > the JIRAs causing that were happily marked as Resolved.
> > > >> > Meaning whoever fixed that probably only ran smoke tests with OWB.
> > > >> >
> > > >> > Today I noticed there is going to be a release soon and so I
> quikly

Re: CI for DeltaSpike?

2017-12-01 Thread Matej Novotny 
Hi Gerhard,

> i'm not sure if others are still following it. at the time i did the
> releases, it was a mandatory step.

Yes, I hope nobody releases without actually testing it at all.
But this check IMO comes too late - there are multiple "fixes" present, where 
the author apparently didn't even execute the tests.
Checking this before release means you bump into problems with issues which 
were "fixed" six months ago.
Hence I am suggesting whether we shouldn't look into some more flexible 
approach. 
I know Travis still isn't quite the thing beucase of the structure, I am just 
trying to start a discussion here and see how people view thing - maybe I am 
just weird with my requirements :)

> back then i also added ci-jobs for new owb/weld releases immediately.
> (it looks like nobody took over that part.)

Would be great if this was still done, every new weld release is announced 
directly on DS mailing list, so it's just about updating it.


Matej

- Original Message -
> From: "Gerhard Petracek" <gpetra...@apache.org>
> To: dev@deltaspike.apache.org
> Sent: Thursday, November 30, 2017 3:32:04 PM
> Subject: Re: CI for DeltaSpike?
> 
> hi matej,
> 
> one of the (manual) steps for a release is to check those results (before a
> release gets started at all).
> i'm not sure if others are still following it. at the time i did the
> releases, it was a mandatory step.
> back then i also added ci-jobs for new owb/weld releases immediately.
> (it looks like nobody took over that part.)
> 
> regards,
> gerhard
> 
> 
> 
> 2017-11-30 14:59 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> 
> > Sorry Matej, I don't get how Travis would help since you can do the
> > same with jenkins which is already configured.
> >
> > Having the default build running on both weld and OWB would be more
> > beneficial IMHO, but it is just the opinion from my side of the fence
> > and experience.
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> >
> >
> > 2017-11-30 14:57 GMT+01:00 Matej Novotny <manov...@redhat.com>:
> > > Thanks, but it was more of a rhetorical question (you saved me some
> > digging though).
> > > Still my claim holds true, nobody cares about them much. They must have
> > been failing for quite some time now
> > > Not to mention they aren't even updated to latest Weld version (or
> > WildFly version for that matter).
> > >
> > >
> > > Matej
> > >
> > > - Original Message -
> > >> From: "Romain Manni-Bucau" <rmannibu...@gmail.com>
> > >> To: dev@deltaspike.apache.org
> > >> Sent: Wednesday, November 29, 2017 5:03:02 PM
> > >> Subject: Re: CI for DeltaSpike?
> > >>
> > >> Hi Matej,
> > >>
> > >> they are all on the ASF jenkins:
> > >> https://builds.apache.org/view/A-D/view/DeltaSpike/
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> > >>
> > >>
> > >> 2017-11-29 16:47 GMT+01:00 Matej Novotny <manov...@redhat.com>:
> > >> > Hello
> > >> >
> > >> > I wanted to bring up a topic of CI (Continuous Irritation - eh, I
> > meant
> > >> > Integration OFC) and DeltaSpike.
> > >> > Apparently, there is no such thing now and even while some CI jobs
> > exist
> > >> > (where are they, anyway?), nobody really pays attention to them.
> > >> > I mean those for Weld ones must have been failing for few months and
> > yet
> > >> > the JIRAs causing that were happily marked as Resolved.
> > >> > Meaning whoever fixed that probably only ran smoke tests with OWB.
> > >> >
> > >> > Today I noticed there is going to be a release soon and so I quikly
> > went to
> > >> > check how the build/tests fare with Weld profiles.
> > >> > Turned out to be a disaster. So I then have to spend considerable time
> > >> > backtracking the changes and figuring out the actual problem.
> > >> > And it's not the first time this happened either.
> > >> >
> > >> > Therefore I wanted to bring up the topic of CI to avoid this in the
> > future.
> > >> > The ideal scenario is sending PRs and having them checked *before*
> > merging
> > >> > - obviously not an option here.
> > >> > The GH repo is but a mirror (something we have to stick to I presume)
> > which
> > >> > makes it more complex, but still, it should be possible to set up a
> > Travis
> > >> > build on GH master which will execute after every sync.
> > >> > That way the failures would be readily visible (via the travis status
> > >> > "button").
> > >> > In order to discover most problems there is no need for a complete
> > test
> > >> > matrix, it would do to just have two version of OWB and Weld without
> > EE
> > >> > container (with just the Arq. one).
> > >> >
> > >> >
> > >> > A penny for your thoughts?
> > >> >
> > >> >
> > >> > Regards
> > >> > Matej
> > >>
> >
>

Re: CI for DeltaSpike?

2017-11-30 Thread Gerhard Petracek 
hi matej,

one of the (manual) steps for a release is to check those results (before a
release gets started at all).
i'm not sure if others are still following it. at the time i did the
releases, it was a mandatory step.
back then i also added ci-jobs for new owb/weld releases immediately.
(it looks like nobody took over that part.)

regards,
gerhard



2017-11-30 14:59 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> Sorry Matej, I don't get how Travis would help since you can do the
> same with jenkins which is already configured.
>
> Having the default build running on both weld and OWB would be more
> beneficial IMHO, but it is just the opinion from my side of the fence
> and experience.
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>
>
> 2017-11-30 14:57 GMT+01:00 Matej Novotny <manov...@redhat.com>:
> > Thanks, but it was more of a rhetorical question (you saved me some
> digging though).
> > Still my claim holds true, nobody cares about them much. They must have
> been failing for quite some time now
> > Not to mention they aren't even updated to latest Weld version (or
> WildFly version for that matter).
> >
> >
> > Matej
> >
> > - Original Message -
> >> From: "Romain Manni-Bucau" <rmannibu...@gmail.com>
> >> To: dev@deltaspike.apache.org
> >> Sent: Wednesday, November 29, 2017 5:03:02 PM
> >> Subject: Re: CI for DeltaSpike?
> >>
> >> Hi Matej,
> >>
> >> they are all on the ASF jenkins:
> >> https://builds.apache.org/view/A-D/view/DeltaSpike/
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> >>
> >>
> >> 2017-11-29 16:47 GMT+01:00 Matej Novotny <manov...@redhat.com>:
> >> > Hello
> >> >
> >> > I wanted to bring up a topic of CI (Continuous Irritation - eh, I
> meant
> >> > Integration OFC) and DeltaSpike.
> >> > Apparently, there is no such thing now and even while some CI jobs
> exist
> >> > (where are they, anyway?), nobody really pays attention to them.
> >> > I mean those for Weld ones must have been failing for few months and
> yet
> >> > the JIRAs causing that were happily marked as Resolved.
> >> > Meaning whoever fixed that probably only ran smoke tests with OWB.
> >> >
> >> > Today I noticed there is going to be a release soon and so I quikly
> went to
> >> > check how the build/tests fare with Weld profiles.
> >> > Turned out to be a disaster. So I then have to spend considerable time
> >> > backtracking the changes and figuring out the actual problem.
> >> > And it's not the first time this happened either.
> >> >
> >> > Therefore I wanted to bring up the topic of CI to avoid this in the
> future.
> >> > The ideal scenario is sending PRs and having them checked *before*
> merging
> >> > - obviously not an option here.
> >> > The GH repo is but a mirror (something we have to stick to I presume)
> which
> >> > makes it more complex, but still, it should be possible to set up a
> Travis
> >> > build on GH master which will execute after every sync.
> >> > That way the failures would be readily visible (via the travis status
> >> > "button").
> >> > In order to discover most problems there is no need for a complete
> test
> >> > matrix, it would do to just have two version of OWB and Weld without
> EE
> >> > container (with just the Arq. one).
> >> >
> >> >
> >> > A penny for your thoughts?
> >> >
> >> >
> >> > Regards
> >> > Matej
> >>
>

Re: CI for DeltaSpike?

2017-11-30 Thread Romain Manni-Bucau 
Sorry Matej, I don't get how Travis would help since you can do the
same with jenkins which is already configured.

Having the default build running on both weld and OWB would be more
beneficial IMHO, but it is just the opinion from my side of the fence
and experience.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-11-30 14:57 GMT+01:00 Matej Novotny <manov...@redhat.com>:
> Thanks, but it was more of a rhetorical question (you saved me some digging 
> though).
> Still my claim holds true, nobody cares about them much. They must have been 
> failing for quite some time now
> Not to mention they aren't even updated to latest Weld version (or WildFly 
> version for that matter).
>
>
> Matej
>
> - Original Message -
>> From: "Romain Manni-Bucau" <rmannibu...@gmail.com>
>> To: dev@deltaspike.apache.org
>> Sent: Wednesday, November 29, 2017 5:03:02 PM
>> Subject: Re: CI for DeltaSpike?
>>
>> Hi Matej,
>>
>> they are all on the ASF jenkins:
>> https://builds.apache.org/view/A-D/view/DeltaSpike/
>>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>>
>>
>> 2017-11-29 16:47 GMT+01:00 Matej Novotny <manov...@redhat.com>:
>> > Hello
>> >
>> > I wanted to bring up a topic of CI (Continuous Irritation - eh, I meant
>> > Integration OFC) and DeltaSpike.
>> > Apparently, there is no such thing now and even while some CI jobs exist
>> > (where are they, anyway?), nobody really pays attention to them.
>> > I mean those for Weld ones must have been failing for few months and yet
>> > the JIRAs causing that were happily marked as Resolved.
>> > Meaning whoever fixed that probably only ran smoke tests with OWB.
>> >
>> > Today I noticed there is going to be a release soon and so I quikly went to
>> > check how the build/tests fare with Weld profiles.
>> > Turned out to be a disaster. So I then have to spend considerable time
>> > backtracking the changes and figuring out the actual problem.
>> > And it's not the first time this happened either.
>> >
>> > Therefore I wanted to bring up the topic of CI to avoid this in the future.
>> > The ideal scenario is sending PRs and having them checked *before* merging
>> > - obviously not an option here.
>> > The GH repo is but a mirror (something we have to stick to I presume) which
>> > makes it more complex, but still, it should be possible to set up a Travis
>> > build on GH master which will execute after every sync.
>> > That way the failures would be readily visible (via the travis status
>> > "button").
>> > In order to discover most problems there is no need for a complete test
>> > matrix, it would do to just have two version of OWB and Weld without EE
>> > container (with just the Arq. one).
>> >
>> >
>> > A penny for your thoughts?
>> >
>> >
>> > Regards
>> > Matej
>>

Re: CI for DeltaSpike?

2017-11-30 Thread Matej Novotny 
Thanks, but it was more of a rhetorical question (you saved me some digging 
though).
Still my claim holds true, nobody cares about them much. They must have been 
failing for quite some time now
Not to mention they aren't even updated to latest Weld version (or WildFly 
version for that matter).


Matej

- Original Message -
> From: "Romain Manni-Bucau" <rmannibu...@gmail.com>
> To: dev@deltaspike.apache.org
> Sent: Wednesday, November 29, 2017 5:03:02 PM
> Subject: Re: CI for DeltaSpike?
> 
> Hi Matej,
> 
> they are all on the ASF jenkins:
> https://builds.apache.org/view/A-D/view/DeltaSpike/
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> 
> 
> 2017-11-29 16:47 GMT+01:00 Matej Novotny <manov...@redhat.com>:
> > Hello
> >
> > I wanted to bring up a topic of CI (Continuous Irritation - eh, I meant
> > Integration OFC) and DeltaSpike.
> > Apparently, there is no such thing now and even while some CI jobs exist
> > (where are they, anyway?), nobody really pays attention to them.
> > I mean those for Weld ones must have been failing for few months and yet
> > the JIRAs causing that were happily marked as Resolved.
> > Meaning whoever fixed that probably only ran smoke tests with OWB.
> >
> > Today I noticed there is going to be a release soon and so I quikly went to
> > check how the build/tests fare with Weld profiles.
> > Turned out to be a disaster. So I then have to spend considerable time
> > backtracking the changes and figuring out the actual problem.
> > And it's not the first time this happened either.
> >
> > Therefore I wanted to bring up the topic of CI to avoid this in the future.
> > The ideal scenario is sending PRs and having them checked *before* merging
> > - obviously not an option here.
> > The GH repo is but a mirror (something we have to stick to I presume) which
> > makes it more complex, but still, it should be possible to set up a Travis
> > build on GH master which will execute after every sync.
> > That way the failures would be readily visible (via the travis status
> > "button").
> > In order to discover most problems there is no need for a complete test
> > matrix, it would do to just have two version of OWB and Weld without EE
> > container (with just the Arq. one).
> >
> >
> > A penny for your thoughts?
> >
> >
> > Regards
> > Matej
>

Re: CI for DeltaSpike?

2017-11-29 Thread Romain Manni-Bucau 
Hi Matej,

they are all on the ASF jenkins:
https://builds.apache.org/view/A-D/view/DeltaSpike/

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-11-29 16:47 GMT+01:00 Matej Novotny :
> Hello
>
> I wanted to bring up a topic of CI (Continuous Irritation - eh, I meant 
> Integration OFC) and DeltaSpike.
> Apparently, there is no such thing now and even while some CI jobs exist 
> (where are they, anyway?), nobody really pays attention to them.
> I mean those for Weld ones must have been failing for few months and yet the 
> JIRAs causing that were happily marked as Resolved.
> Meaning whoever fixed that probably only ran smoke tests with OWB.
>
> Today I noticed there is going to be a release soon and so I quikly went to 
> check how the build/tests fare with Weld profiles.
> Turned out to be a disaster. So I then have to spend considerable time 
> backtracking the changes and figuring out the actual problem.
> And it's not the first time this happened either.
>
> Therefore I wanted to bring up the topic of CI to avoid this in the future. 
> The ideal scenario is sending PRs and having them checked *before* merging - 
> obviously not an option here.
> The GH repo is but a mirror (something we have to stick to I presume) which 
> makes it more complex, but still, it should be possible to set up a Travis 
> build on GH master which will execute after every sync.
> That way the failures would be readily visible (via the travis status 
> "button").
> In order to discover most problems there is no need for a complete test 
> matrix, it would do to just have two version of OWB and Weld without EE 
> container (with just the Arq. one).
>
>
> A penny for your thoughts?
>
>
> Regards
> Matej

CI for DeltaSpike?

2017-11-29 Thread Matej Novotny 
Hello

I wanted to bring up a topic of CI (Continuous Irritation - eh, I meant 
Integration OFC) and DeltaSpike.
Apparently, there is no such thing now and even while some CI jobs exist (where 
are they, anyway?), nobody really pays attention to them.
I mean those for Weld ones must have been failing for few months and yet the 
JIRAs causing that were happily marked as Resolved.
Meaning whoever fixed that probably only ran smoke tests with OWB.

Today I noticed there is going to be a release soon and so I quikly went to 
check how the build/tests fare with Weld profiles.
Turned out to be a disaster. So I then have to spend considerable time 
backtracking the changes and figuring out the actual problem.
And it's not the first time this happened either.

Therefore I wanted to bring up the topic of CI to avoid this in the future. The 
ideal scenario is sending PRs and having them checked *before* merging - 
obviously not an option here.
The GH repo is but a mirror (something we have to stick to I presume) which 
makes it more complex, but still, it should be possible to set up a Travis 
build on GH master which will execute after every sync.
That way the failures would be readily visible (via the travis status "button").
In order to discover most problems there is no need for a complete test matrix, 
it would do to just have two version of OWB and Weld without EE container (with 
just the Arq. one).


A penny for your thoughts?


Regards
Matej