For eclipse users we already have a test debug configuration for this in
the drop down list. You can use -Dtest.debug and -Ditest.debug to set
breaks in the code creating the deployment, and the actual
deployment/tests, respectively.
On 12/19/2012 7:47 AM, John Mazzitelli wrote:
-Ditest.debug will run the arquillian stuff such that you can attach
a debugger to it over port 8798 (I think that's the port number).
----- Original Message -----
> On Tuesday, December 18, 2012 14:49:04 Jay Shaughnessy wrote:
>
> ... snip ...
>
>>> 2) Use remote container instead of managed container
>>> Arquillian handles starting and stopping a managed container
>>> whereas
>>> the lifecycle of a remote container is not handled by Arquillian.
>>> I
>>> kept my AS 7 instance running. Maybe Jay and/or Mazz have some
>>> insights into whether or not there might be issues with using a
>>> remote
>>> container.
>> Certainly using a running remote server can speed things up since
>> it
>> avoids that setup/teardown, although I suspect it can affect a lot
>> of
>> the tests as written today, given that many freely perform
>> transaction
>> management and interact with the entitymanager.
>>
>> I have nothing against doing this when it make sense. Perhaps you
>> could
>> give us some instructions if you have this working for certain
>> tests.
>>
>> From the perspective of jenkins CI runs the managed container
>> certainly
>> makes sense.
>>
>
http://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/integration-
> tests/jndi-access/jndi-access-test/pom.xml#n152
>
> E.g. Jenkins does "mvn clean install" and gets the managed server.
> You as a
> developer do "mvn clean install -Premote-test-server" and run your
> test on the
> pre-started AS7 with a debugger attached. There are 2 pros to this:
> 1) you
> don't get the overhead of starting and stopping the full server for a
> single
> test run, 2) You can actually debug your test code ;)
>
> I tried a similar approach in itests-2 module and for some reason it
> didn't
> work that well - but I didn't spend too much time on it since I knew
> we were
> making big changes in the module and its pom at that time so I kinda
> let it be
> and concentrated on other things.
>
> But given how small those profiles are and how much utitility they
> provide I'd
> be very much for including something like this more "globally" in the
> build
> (if we manage to make it work everywhere)...
>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel