@Ron
I just tried that. The result is this:
java.lang.IllegalArgumentException: No
org.jboss.arquillian.container.spi.client.protocol.metadata.HTTPContext
found in
org.jboss.arquillian.container.spi.client.protocol.metadata.ProtocolMetaData.
Servlet protocol can not be used
at
org.jboss.arquillian.protocol.servlet.BaseServletProtocol.getExecutor(BaseServletProtocol.java:64)
at
org.jboss.arquillian.protocol.servlet.BaseServletProtocol.getExecutor(BaseServletProtocol.java:35)
at
org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.getContainerMethodExecutor(RemoteTestExecuter.java:136)
at
org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:119)
What if we just add *<protocol type="Servlet 3.0" />* to all the AS7 and
Wildfly profiles? Wouldn't this fix all our problems?
Christian
2014-02-03 Ron Smeral <[email protected]>:
> Hi Christian,
>
> the reason for this could be, that in parent/code/pom.xml, the
> 'org.jboss.arquillian.protocol:arquillian-protocol-servlet' dependency is
> not declared for any non-JBoss profile (OWB, tomee, glassfish, ..).
> Could you try it with the dependency declared?
>
> Ron
>
>
> On 3.2.2014 10:51, Christian Kaltepoth wrote:
>
>> @gerhard:
>>
>> I was getting this when running the build:
>>
>> Caused by: java.lang.IllegalStateException: Defined default protocol
>> Servlet 3.0 can not be found on classpath
>> at
>> org.jboss.arquillian.container.test.impl.client.protocol.
>> ProtocolRegistryCreator.createRegistry(ProtocolRegistryCreator.java:61)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(
>> NativeMethodAccessorImpl.java:57)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:606)
>> at
>> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
>> at
>> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(
>> EventContextImpl.java:99)
>>
>> The weird thing is that Maven simply doesn't run the tests in this case
>> which leads to a successful build.
>>
>> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
>>
>> Full log of running "mvn clean -POWB -Dowb.version=1.1.8" on core-impl
>> with
>> the default protocol entry:
>>
>> http://pastebin.com/raw.php?i=1hk9nxmZ
>>
>>
>> Christian
>>
>>
>>
>>
>> 2014-02-02 Gerhard Petracek <[email protected]>:
>>
>> @christian:
>>>
>>> locally i've tested the owb-, weld- and some build-managed-profiles with
>>> the defaultProtocol you removed and everything is working on my machine.
>>> -> please provide further details.
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2014-02-01 Christian Kaltepoth <[email protected]>:
>>>
>>> @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 <[email protected]>:
>>>>
>>>> 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 <[email protected]>
>>>>>
>>>> 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 <[email protected]>
>>>>>>>
>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> --
>>>>>> 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
>>>>
>>>>
>>
>>
> --
> Ron Smeral
> JBoss Quality Engineer
> Brno
>
>
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
