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
>
>
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
