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
>

Reply via email to