I have been playing a little with a JRebel extension to Arquillian, but it's not done yet..

It should basically let you deploy to the server once, then in addition add the rebel.xml file that points back to local disk. The next deploy is then only written to disk and handled by the JRebel classloaders.

I can push it out to github if you want to play with it. .

It's been a while since I looked at it.. don't expect it to work, it's a very early prototype..

https://github.com/arquillian/arquillian-extension-jrebel/tree/wip

But you're welcome to hack away on it..

Aaa yes.. that's right. Forgot about those, probably why it never got published in the first place. It relies on a few changes to Arquillian Core.. which is probably have in some old branch here..

Hi Bernard,

at first, this is fanstastic achievement, I can't wait to try this extension!

Few comments here:

Ad 2.

This is connected to point 1. Right now there is only one exploded package directory and it's used as marker file telling if package is deployed.

Does it make sense to prefix the deployment name with FQN of test class?

Then there will be no clash, you could name exploded directory by test class name.

Ad 4.

Currently the extension blocks undeployment so the package remains on the server all the time and when we do i.e. mvn clean test then extension tries to redeploy the archive but Oops, AS7 will throw exception because package with such name is already deployed and the tests will run against old (already deployed) archive.

Probably if we don't see marker files and think we need to redeploy then throw undeploy event first?

What if the extension could "cache" only last scenario (it means all deployments for class which was run last).

Arquillian internal rules say:

A @Deployment.name must be unqie within a TestClass if

- there are more then one Archive Deployment in the TestClass

A Archive.name returned by a @Deployment method can be the same but only if

- the @Deployment has different @TargetsContainer

TesClass + Target + Deployment.name should be unique

@Inject Instance<TestClass> testClass;

testClass.get().getName() + event.getContainer().getName() + event.getDeployment().getName()

Why limit like that if it's already possible to cache all deployments? If you want to force redeployment then remove temp dir.

My first thought was to only have one deployment active at the time. So you would run one test, rebel kicks in. run it again, rebel is active. But when you run another test, the previous run is undeployed, new test run, rebel kicks in.. etc

But there might be better ways of doing this. Maybe it's ok that sometimes you have to go clean up the servers deployment manually during dev ?

I currently see only the one use case, where one deployment scenario is cached, since you are hacking on that.

And having one deployment scenario (multiple deployments) seems like overall simplification.

Could you see any other use case?

not sure i understand what you mean by "

And having one deployment scenario (multiple deployments) seems like overall simplification." ?

I mean that it could simplify design heavily, since you don't need to solve conflicts which can arise with many deployments.

You can be sure that there are only deployments related to current class deployed at the time.

Yea, I think it's atleast a good start for the first version. JRebel is something you would use in a pure dev setting, not on CI etc. As long as we can jump between tests seamlessly, I don't think the undeploy of the previous testcase should be to much of a hassle.