@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 <lightguard...@gmail.com>:
> 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 <rsme...@redhat.com> 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 <gerhard.petra...@gmail.com>
> >>
> >> hi christian,
> >>>
> >>> the jenkins-jobs should be in place already.
> >>>
> >>> regards,
> >>> gerhard
> >>>
> >>>
> >>>
> >>> 2014/1/24 Christian Kaltepoth <christ...@kaltepoth.de>
> >>>
> >>> 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 <christ...@kaltepoth.de>
> >>>>
> >>>> 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 <rsme...@redhat.com>
> >>>>>
> >>>>> 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 <rsme...@redhat.com>
> >>>>>>>
> >>>>>>> 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 <rsme...@redhat.com>
> >>>>>>>>>
> >>>>>>>>> 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 <rsme...@redhat.com>
> >>>>>>>>>>>
> >>>>>>>>>>> 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
