@gerhard:
I was getting this when running the build:
Caused by: java.lang.IllegalStateException: Defined default protocol
Servlet 3.0 can not be found on classpath
at
org.jboss.arquillian.container.test.impl.client.protocol.ProtocolRegistryCreator.createRegistry(ProtocolRegistryCreator.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
The weird thing is that Maven simply doesn't run the tests in this case
which leads to a successful build.
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
Full log of running "mvn clean -POWB -Dowb.version=1.1.8" on core-impl with
the default protocol entry:
http://pastebin.com/raw.php?i=1hk9nxmZ
Christian
2014-02-02 Gerhard Petracek <[email protected]>:
> @christian:
>
> locally i've tested the owb-, weld- and some build-managed-profiles with
> the defaultProtocol you removed and everything is working on my machine.
> -> please provide further details.
>
> regards,
> gerhard
>
>
>
> 2014-02-01 Christian Kaltepoth <[email protected]>:
>
> > @Ron & @Jason
> >
> > The defaultProtocol was only used in a single arquillian.xml file of the
> 8
> > different ones we had before. I had to remove it because the plain Weld +
> > OWB integration tests started to fail with it (at least for me) for some
> > reason.
> >
> > Christian
> >
> >
> >
> > 2014-01-31 Jason Porter <[email protected]>:
> >
> > > The JMX protocol for Wildfly / AS is horrible and for any sort of
> > > application or framework the servlet adaptor should be used. Yes, it's
> a
> > > little slower, but it will give you the full environment you're used to
> > > using when you develop.
> > >
> > >
> > > On Fri, Jan 31, 2014 at 1:59 PM, Ron Smeral <[email protected]>
> wrote:
> > >
> > > > Hi Christian,
> > > >
> > > > I see you recently removed defaultProtocol from arquillian.xml. Is
> > there
> > > > any reason not to have it there? The now default JMX protocol seems
> to
> > be
> > > > causing test stability issues, I can't succesfully run for example
> the
> > > Data
> > > > module tests. I'm not sure why this happens. Have you maybe
> encountered
> > > > this too?
> > > >
> > > > Also, just FYI, we now have a job 'DeltaSpike-wildfly-daily' at
> > > > hudson.jboss.org which tests the wildfly-build-managed profile. It
> > will
> > > > be sending mails to commits@deltaspike.
> > > >
> > > > Ron
> > > >
> > > >
> > > > On 25.1.2014 08:36, Christian Kaltepoth wrote:
> > > >
> > > >> Hey Gerhard,
> > > >>
> > > >> yeah, I wasn't aware that the Glassfish jobs have already been
> added.
> > > But
> > > >> Wildfly is still missing.
> > > >>
> > > >> Christian
> > > >>
> > > >>
> > > >>
> > > >> 2014/1/24 Gerhard Petracek <[email protected]>
> > > >>
> > > >> hi christian,
> > > >>>
> > > >>> the jenkins-jobs should be in place already.
> > > >>>
> > > >>> regards,
> > > >>> gerhard
> > > >>>
> > > >>>
> > > >>>
> > > >>> 2014/1/24 Christian Kaltepoth <[email protected]>
> > > >>>
> > > >>> Hey all,
> > > >>>>
> > > >>>> I pushed out all the changes of the "build-managed" integration
> test
> > > >>>>
> > > >>> Maven
> > > >>>
> > > >>>> profiles which I suggested.
> > > >>>>
> > > >>>> You can now run the integration test suite against the different
> > > >>>>
> > > >>> containers
> > > >>>
> > > >>>> like this:
> > > >>>>
> > > >>>> $ mvn clean install -Ptomee-build-managed
> > > >>>> $ mvn clean install -Pjbossas-build-managed-7
> > > >>>> $ mvn clean install -Pwildfly-build-managed
> > > >>>> $ mvn clean install -Pglassfish-build-managed-3
> > > >>>> $ mvn clean install -Pglassfish-build-managed-4
> > > >>>>
> > > >>>> Each profiles will automatically download, unpack and configure
> the
> > > >>>> corresponding container. All TCP ports are changed so that they
> > differ
> > > >>>>
> > > >>> from
> > > >>>
> > > >>>> this default ones. This way we should be able to run them on the
> CI
> > > >>>>
> > > >>> server
> > > >>>
> > > >>>> without any problems.
> > > >>>>
> > > >>>> Could anyone with the required permissions add corresponding jobs
> in
> > > >>>> Jenkins?
> > > >>>>
> > > >>>> Christian
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> 2014/1/11 Christian Kaltepoth <[email protected]>
> > > >>>>
> > > >>>> Hey Ron,
> > > >>>>>
> > > >>>>> yeah, I also thought about using "user.dir", but this could point
> > to
> > > >>>>>
> > > >>>> some
> > > >>>
> > > >>>> weird locations depending on from where you start the build. So
> > let's
> > > >>>>>
> > > >>>> go
> > > >>>
> > > >>>> with "java.io.tmpdir" for now.
> > > >>>>>
> > > >>>>> Christian
> > > >>>>>
> > > >>>>>
> > > >>>>> 2014/1/8 Ron Smeral <[email protected]>
> > > >>>>>
> > > >>>>> Hey Christian,
> > > >>>>>>
> > > >>>>>> you're right, I haven't realized that. Also, if some module
> > needed a
> > > >>>>>> custom arquillian conf, Arquillian reads a system property named
> > > >>>>>> "arquillian.xml" which defines the name of the configuration
> file.
> > > >>>>>>
> > > >>>>>> The last thing I can think of for the testsuite root is the
> Maven
> > > >>>>>> property "user.dir" - the working directory from which mvn was
> > > >>>>>>
> > > >>>>> executed.
> > > >>>
> > > >>>> Ron
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On 7.1.2014 17:20, Christian Kaltepoth wrote:
> > > >>>>>>
> > > >>>>>> Hey Ron,
> > > >>>>>>>
> > > >>>>>>> I don't think unpacking is necessary. If arquillian.xml is
> > located
> > > in
> > > >>>>>>> deltaspike/test-utils/src/main/resources, it will be on the
> > > >>>>>>> classpath
> > > >>>>>>> for
> > > >>>>>>> all integration tests. That's basically the setup we are using
> > for
> > > >>>>>>> Rewrite
> > > >>>>>>> since quite some time and it is working fine. See [1].
> > > >>>>>>>
> > > >>>>>>> I guess you are right regarding the merging of poms and that
> > > >>>>>>>
> > > >>>>>> ${basedir}
> > > >>>
> > > >>>> won't work because of this. Too bad. So perhaps we should use
> > > >>>>>>> java.io.tmpdir for now until we find a better way (if there is
> > > any).
> > > >>>>>>>
> > > >>>>>>> Christian
> > > >>>>>>>
> > > >>>>>>> [1]
> > > >>>>>>> https://github.com/ocpsoft/rewrite/blob/master/test-
> > > >>>>>>> harness/src/main/resources/arquillian.xml
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> 2014/1/7 Ron Smeral <[email protected]>
> > > >>>>>>>
> > > >>>>>>> Hi Christian,
> > > >>>>>>>
> > > >>>>>>>> the test-utils is in the parent/code/pom.xml as a dependency,
> > but
> > > >>>>>>>>
> > > >>>>>>> then
> > > >>>
> > > >>>> still, to get to the arquillian.xml file in the test-utils.jar,
> it
> > > >>>>>>>>
> > > >>>>>>> would
> > > >>>>
> > > >>>>> need to be unpacked using e.g. dependency:unpack plugin goal.
> > > >>>>>>>>
> > > >>>>>>>> Regarding basedir, because POMs are merged in Maven to form
> the
> > > >>>>>>>> Effective
> > > >>>>>>>> POM, the basedir property always points to the current
> project,
> > > >>>>>>>> regardless
> > > >>>>>>>> of the POM in which you reference it.
> > > >>>>>>>> For example, if -- as you suggest -- there's project P and C,
> > > where
> > > >>>>>>>>
> > > >>>>>>> P
> > > >>>
> > > >>>> is
> > > >>>>
> > > >>>>> parent of C, and P contains <root>${basedir}</root>, then for C,
> > the
> > > >>>>>>>> ${root} will contain the base dir of C anyway, not that of P.
> > > >>>>>>>> The least hacky (but still ugly) way that comes to mind is to
> > pass
> > > >>>>>>>>
> > > >>>>>>> the
> > > >>>
> > > >>>> property an absolute path from the shell, as in "mvn clean test
> > > >>>>>>>> -Droot=$(pwd)". The root property could have a default value
> of
> > > >>>>>>>> ${java.io.tmpdir}.
> > > >>>>>>>>
> > > >>>>>>>> Ron
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On 7.1.2014 07:51, Christian Kaltepoth wrote:
> > > >>>>>>>>
> > > >>>>>>>> Hey Ron,
> > > >>>>>>>>
> > > >>>>>>>>> I don't think we will have to copy arquillian.xml using the
> > > >>>>>>>>> resources-plugin. If we add it to src/main/resources of the
> > > >>>>>>>>>
> > > >>>>>>>> test-utils
> > > >>>>
> > > >>>>> module, it will be on the test classpath for all other modules.
> I
> > > >>>>>>>>>
> > > >>>>>>>> think
> > > >>>>
> > > >>>>> this should work fine.
> > > >>>>>>>>>
> > > >>>>>>>>> Regarding the testsuite root directory. I think we could use
> > > >>>>>>>>>
> > > >>>>>>>> Maven's
> > > >>>
> > > >>>> ${basedir} in the parent pom and store it in a system property.
> > > >>>>>>>>> Thoughts?
> > > >>>>>>>>>
> > > >>>>>>>>> Christian
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> 2014/1/3 Ron Smeral <[email protected]>
> > > >>>>>>>>>
> > > >>>>>>>>> Hi Christian,
> > > >>>>>>>>>
> > > >>>>>>>>> looking at the arquillian.xml files, they are 99% the same,
> > the
> > > >>>>>>>>>>
> > > >>>>>>>>> only
> > > >>>
> > > >>>> one
> > > >>>>>>>>>> that actually differs (other than whitespace, comments and
> > > missing
> > > >>>>>>>>>> cdicontainer.version property) is the one in the data
> module,
> > > >>>>>>>>>> containing
> > > >>>>>>>>>> a
> > > >>>>>>>>>> testDatabase configuration for tomee. So, we could have just
> > one
> > > >>>>>>>>>> arquillian.xml file somewhere in the testsuite root, copy it
> > > over
> > > >>>>>>>>>> using
> > > >>>>>>>>>> resources-plugin, and override it only when necessary.
> > > >>>>>>>>>> One minor problem is -- and this is for the container
> > unpacking
> > > >>>>>>>>>>
> > > >>>>>>>>> too
> > > >>>
> > > >>>> --
> > > >>>>
> > > >>>>> that to point to the testsuite root, every pom would need to
> keep
> > > >>>>>>>>>>
> > > >>>>>>>>> a
> > > >>>
> > > >>>> relative reference to it (e.g. <testsuite.root>../../..</
> > > >>>>>>>>>> testsuite.root>),
> > > >>>>>>>>>> which is ugly, but doable.
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> On 3.1.2014 06:26, Christian Kaltepoth wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>> Hey Ron,
> > > >>>>>>>>>>
> > > >>>>>>>>>> yeah, there are differences between arquillian.xml files.
> But
> > > >>>>>>>>>>>
> > > >>>>>>>>>> why?
> > > >>>
> > > >>>> I
> > > >>>>
> > > >>>>> don't
> > > >>>>>>>>>>> see any reason for having different arquillian.xml files
> > > between
> > > >>>>>>>>>>> modules.
> > > >>>>>>>>>>> Actually the integration test Maven profiles are also
> located
> > > in
> > > >>>>>>>>>>>
> > > >>>>>>>>>> a
> > > >>>
> > > >>>> single
> > > >>>>>>>>>>> parent pom and not in each individual module pom. IMHO we
> > > should
> > > >>>>>>>>>>> treat
> > > >>>>>>>>>>> arquillian.xml the same way. Unless there is a good reason
> > for
> > > >>>>>>>>>>>
> > > >>>>>>>>>> having
> > > >>>>
> > > >>>>> multiple ones.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> I agree that we should unpack the container only once. I'm
> > not
> > > >>>>>>>>>>>
> > > >>>>>>>>>> sure I
> > > >>>>
> > > >>>>> like
> > > >>>>>>>>>>> to use java.io.tmpdir though. It would be nice to have it
> in
> > > the
> > > >>>>>>>>>>> top-level
> > > >>>>>>>>>>> "target" directory or something like that. That would
> ensure
> > > that
> > > >>>>>>>>>>> running
> > > >>>>>>>>>>> "mvn clean" would also remove the unpacked container.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Christian
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 2014/1/2 Ron Smeral <[email protected]>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On 2.1.2014 17:55, Christian Kaltepoth wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Hey all,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> there are two things I would like to address regarding
> our
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> integration
> > > >>>>>>>>>>>>> test
> > > >>>>>>>>>>>>> suite.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> 1. Currently each module has its own arquillian.xml file.
> > > IMHO
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> this
> > > >>>>
> > > >>>>> doesn't
> > > >>>>>>>>>>>>> make sense. What about using a single arquillian.xml and
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> placing
> > > >>>
> > > >>>> it in
> > > >>>>>>>>>>>>> the
> > > >>>>>>>>>>>>> test-utils module?
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> +0, there are minor differences among them currently
> > > >>>>>>>>>>>>> (though
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> not
> > > >>>>
> > > >>>>> sure
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> if
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> necessary), and it would make it more difficult to make an
> > > >>>>>>>>>>>> individual
> > > >>>>>>>>>>>> modification if there was single arquillian.xml.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> 2. We have both "managed" and "remote" profiles for
> some
> > > >>>>>>>>>>>> containers.
> > > >>>>>>>>>>>> But
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> the "managed" profiles (especially Wildfly + Glassfish)
> > > >>>>>>>>>>>> require
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> you to
> > > >>>>>>>>>>>>> manually download and setup the corresponding container
> > > which I
> > > >>>>>>>>>>>>> would
> > > >>>>>>>>>>>>> like
> > > >>>>>>>>>>>>> to avoid. I think it would be nicer if the "managed"
> > profiles
> > > >>>>>>>>>>>>> could do
> > > >>>>>>>>>>>>> this
> > > >>>>>>>>>>>>> automatically. This would simplify the process of running
> > the
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> tests
> > > >>>>
> > > >>>>> locally
> > > >>>>>>>>>>>>> before committing and it would also be easier to create
> CI
> > > jobs
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> for
> > > >>>>
> > > >>>>> them.
> > > >>>>>>>>>>>>> See [1] for an example of a profile which sets up the
> > > container
> > > >>>>>>>>>>>>> automatically and therefore runs out of the box even in
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> transient
> > > >>>
> > > >>>> CI
> > > >>>>>>>>>>>>> environments like Travis [2].
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> There already is such profile at least for JBoss AS7
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> (jbossas-build-managed-7) and at this very moment I'm
> > > adding
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> such
> > > >>>>
> > > >>>>> profile
> > > >>>>>>>>>>>> for WildFly. However, currently there is a minor drawback
> to
> > > the
> > > >>>>>>>>>>>> current
> > > >>>>>>>>>>>> approach -- the container is unpacked for every module and
> > so
> > > >>>>>>>>>>>> almost 5
> > > >>>>>>>>>>>> GB
> > > >>>>>>>>>>>> of diskspace is required to run the whole testsuite, which
> > is
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>> quite
> > > >>>>
> > > >>>>> impractical. It would be nice to have the container unpacked to
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>> a
> > > >>>
> > > >>>> shared
> > > >>>>>>>>>>>> location, e.g. ${java.io.tmpdir}, just as in the ocpsoft
> > > rewrite
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>> pom
> > > >>>>
> > > >>>>> you
> > > >>>>>>>>>>>> linked. I'll try that in the AS7 and WF8 profiles.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Thoughts?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> [1]
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> https://github.com/ocpsoft/rewrite/blob/master/pom.xml#L706
> > > >>>
> > > >>>> [2] https://travis-ci.org/ocpsoft/rewrite/builds/16192940
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Christian
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Ron Smeral
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> JBoss Quality Engineer
> > > >>>>>>>>>>>> Brno
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> --
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Ron Smeral
> > > >>>>>>>>>>>
> > > >>>>>>>>>> JBoss Quality Engineer
> > > >>>>>>>>>> Brno
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> --
> > > >>>>>>>>>>
> > > >>>>>>>>> Ron Smeral
> > > >>>>>>>> JBoss Quality Engineer
> > > >>>>>>>> Brno
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> --
> > > >>>>>> Ron Smeral
> > > >>>>>> JBoss Quality Engineer
> > > >>>>>> Brno
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>> --
> > > >>>>> Christian Kaltepoth
> > > >>>>> Blog: http://blog.kaltepoth.de/
> > > >>>>> Twitter: http://twitter.com/chkal
> > > >>>>> GitHub: https://github.com/chkal
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> --
> > > >>>> Christian Kaltepoth
> > > >>>> Blog: http://blog.kaltepoth.de/
> > > >>>> Twitter: http://twitter.com/chkal
> > > >>>> GitHub: https://github.com/chkal
> > > >>>>
> > > >>>>
> > > >>
> > > >>
> > > > --
> > > > Ron Smeral
> > > > JBoss Quality Engineer
> > > > Brno
> > > >
> > > >
> > >
> > >
> > > --
> > > Jason Porter
> > > http://en.gravatar.com/lightguardjp
> > >
> >
> >
> >
> > --
> > Christian Kaltepoth
> > Blog: http://blog.kaltepoth.de/
> > Twitter: http://twitter.com/chkal
> > GitHub: https://github.com/chkal
> >
>
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
