4:04 p.m.
Hi all,
With Tycho 0.19.0, we could fix the long-standing issue JBIDE-13869.
This will allow you to run your test with Maven against an RCP
application which is available in your filesystem.
You can do it by simply running for example:
$ cd tests/my.test.bundle
$ mvn clean verify -Dtest.profileName=epp.package.jee
-Dtest.installPath=/home/me/eclipse-4.4.M2
If test.installPath is not set, you get the default surefire behaviour
which is to generate a simple minimal installation to run the tests in
target/work.
More info about the profileName can be found in
http://wiki.eclipse.org/Tycho/Testing_with_Surefire#p2Installed_on_provis...
. This works on any RCP application that relies on p2 (in case you want
to test JBoss Tools inside Websphere Studio ;).
We've configured it so that by default, it is JBDS-friendly and set the
jbds profileName. So to test on JBDS, you can simply use:
$ mvn clean verify
-Dtest.installPath=/home/me/jbdevstudio-8.0.0.Alpha1-SNAPSHOT/studio
Except a few exception, other surefire parameters, such as the very cool
debugPort parameter, can be used together with this mechanism.
Enjoy!
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
11:30 a.m.
On Fri, Nov 08, 2013 at 06:17:40PM -0800, Denis Golovin wrote:
Mickael,
sounds really good :), so I gave it a try and found out:
1. Not all our test plug-ins are ready to be used with this feature
due to
forgetting include test projects into binary build; so far I've found
o.j.t.tests.test and o.j.t.foundation.core.test have such problem; I couldn't
go further than foundation.core.test plug-in because of problems explained
below
You mean forgetting to add files/directories in build.properties ?
That should even fail just running a normal mvn test thus that sounds weird?
It is worth noting that this feature aren't really expected to work with
all our unit tests out of the box - mainly since the unittests been written
to run in a much more constrained environement.
It is mostly useful to automate running of the integration tests AND to allow
testing in different installs without having to rebuild the test plugins.
2. Second try to run usually ends up with
[INFO] Installing IUs [org.jboss.tools.foundation.core.test,
org.eclipse.tycho.surefire.osgibooter, org.eclipse.tycho.surefire.junit4] to /
home/eskimo/jbdevstudio-java-with-space/studio
Installing org.jboss.tools.foundation.core.test 1.1.0.Alpha1-v20131109-0206.
Installing org.eclipse.tycho.surefire.osgibooter 0.19.0.
Installing org.eclipse.tycho.surefire.junit4 0.19.0.
Installation failed.
Cannot complete the install because of a conflicting dependency.
Software being installed: JBoss Foundation Tests 1.1.0.Alpha1-v20131109-0206
(org.jboss.tools.foundation.core.test 1.1.0.Alpha1-v20131109-0206)
Software currently installed: JBoss Foundation Tests
1.1.0.Alpha1-v20131109-0203 (org.jboss.tools.foundation.core.test
1.1.0.Alpha1-v20131109-0203)
Only one of the following can be installed at once:
JBoss Foundation Tests 1.1.0.Alpha1-v20131109-0203
(org.jboss.tools.foundation.core.test 1.1.0.Alpha1-v20131109-0203)
JBoss Foundation Tests 1.1.0.Alpha1-v20131109-0206
(org.jboss.tools.foundation.core.test 1.1.0.Alpha1-v20131109-0206)
Application failed, log file location: /tmp/config3255596288906066066equinox/
1383962733126.log
[INFO] ------------------------------------------------------------------------
looks like you are running against an install that already have the tests installed ?
Where else would it get conflicting features from ?
3. Also I've seen problems with shutting down the RCP
installation:
<snip>
Job found still running after platform shutdown. Jobs should be
canceled by
the plugin that scheduled them during shutdown:
org.eclipse.ui.internal.decorators.DecorationScheduler$3
Job found still running after platform shutdown. Jobs should be canceled by
the plugin that scheduled them during shutdown:
org.eclipse.ui.internal.decorators.DecorationScheduler$1
Job found still running after platform shutdown. Jobs should be canceled by
the plugin that scheduled them during shutdown:
org.eclipse.ui.internal.progress.AnimationManager$1
An error has occurred. See the log file
/home/eskimo/Projects/jbdevstudio/src-fork/jbosstools-base/foundation/tests/
org.jboss.tools.foundation.core.test/target/work/data/.metadata/.log.
Thats less nice - might be fully expected though in a fully loaded install.
Should keep an eye on it though.
/max
9:15 a.m.
On 11/11/2013 02:30 AM, Max Rydahl Andersen wrote:
On Fri, Nov 08, 2013 at 06:17:40PM -0800, Denis Golovin wrote:
> Mickael,
>
> sounds really good :), so I gave it a try and found out:
> 1. Not all our test plug-ins are ready to be used with this feature
> due to
> forgetting include test projects into binary build; so far I've found
> o.j.t.tests.test and o.j.t.foundation.core.test have such problem; I
> couldn't
> go further than foundation.core.test plug-in because of problems
> explained
> below
You mean forgetting to add files/directories in build.properties ?
That should even fail just running a normal mvn test thus that sounds
weird?
This is exactly what I mean, I haven't look why it works in tycho yet, I
guess tycho runs it the same way as Eclipse does it from Development
environment.
It is worth noting that this feature aren't really expected to work
with all our unit tests out of the box - mainly since the unittests
been written
to run in a much more constrained environement.
It is mostly useful to automate running of the integration tests AND
to allow
testing in different installs without having to rebuild the test plugins.
Looking through
http://wiki.eclipse.org/Tycho/Testing_with_Surefire#p2Installed_on_provis...
I don't see how we can do this. Mickael, could you help with example here?
> 2. Second try to run usually ends up with
>
> [INFO] Installing IUs [org.jboss.tools.foundation.core.test,
> org.eclipse.tycho.surefire.osgibooter,
> org.eclipse.tycho.surefire.junit4] to /
> home/eskimo/jbdevstudio-java-with-space/studio
> Installing org.jboss.tools.foundation.core.test
> 1.1.0.Alpha1-v20131109-0206.
> Installing org.eclipse.tycho.surefire.osgibooter 0.19.0.
> Installing org.eclipse.tycho.surefire.junit4 0.19.0.
> Installation failed.
> Cannot complete the install because of a conflicting dependency.
> Software being installed: JBoss Foundation Tests
> 1.1.0.Alpha1-v20131109-0206
> (org.jboss.tools.foundation.core.test 1.1.0.Alpha1-v20131109-0206)
> Software currently installed: JBoss Foundation Tests
> 1.1.0.Alpha1-v20131109-0203 (org.jboss.tools.foundation.core.test
> 1.1.0.Alpha1-v20131109-0203)
> Only one of the following can be installed at once:
> JBoss Foundation Tests 1.1.0.Alpha1-v20131109-0203
> (org.jboss.tools.foundation.core.test 1.1.0.Alpha1-v20131109-0203)
> JBoss Foundation Tests 1.1.0.Alpha1-v20131109-0206
> (org.jboss.tools.foundation.core.test 1.1.0.Alpha1-v20131109-0206)
> Application failed, log file location:
> /tmp/config3255596288906066066equinox/
> 1383962733126.log
> [INFO]
> ------------------------------------------------------------------------
looks like you are running against an install that already have the
tests installed ?
Where else would it get conflicting features from ?
That's how it works now. I just run test again and again which is pretty
much repeats test developing process. Current implementation doesn't let
do do that.
> 3. Also I've seen problems with shutting down the RCP installation:
<snip>
> Job found still running after platform shutdown. Jobs should be
> canceled by
> the plugin that scheduled them during shutdown:
> org.eclipse.ui.internal.decorators.DecorationScheduler$3
> Job found still running after platform shutdown. Jobs should be
> canceled by
> the plugin that scheduled them during shutdown:
> org.eclipse.ui.internal.decorators.DecorationScheduler$1
> Job found still running after platform shutdown. Jobs should be
> canceled by
> the plugin that scheduled them during shutdown:
> org.eclipse.ui.internal.progress.AnimationManager$1
> An error has occurred. See the log file
> /home/eskimo/Projects/jbdevstudio/src-fork/jbosstools-base/foundation/tests/
>
> org.jboss.tools.foundation.core.test/target/work/data/.metadata/.log.
Thats less nice - might be fully expected though in a fully loaded
install.
Should keep an eye on it though.
/max
2:05 p.m.
On Wed, Nov 13, 2013 at 12:15:48AM -0800, Denis Golovin wrote:
>
>You mean forgetting to add files/directories in build.properties ?
>
>That should even fail just running a normal mvn test thus that
>sounds weird?
This is exactly what I mean, I haven't look why it works in tycho yet,
I guess tycho runs it the same way as Eclipse does it from Development
environment.
if it does that is a change. The strenght of tycho is/was that it ran tests
as they would be run in eclipse, not with PDE's "cheating" :)
/max
9:37 a.m.
On 11/09/2013 03:17 AM, Denis Golovin wrote:
1. Not all our test plug-ins are ready to be used with this feature
due to forgetting include test projects into binary build; so far I've
found o.j.t.tests.test and o.j.t.foundation.core.test have such
problem; I couldn't go further than foundation.core.test plug-in
because of problems explained below
I don't understand this issue. You mean
that surefire-plugin was
configured to include dependencies, and that using an installed
application doesn't work? If so, it's somehow normal, Tycho will ignore
the extra-depedencies with this mode, and will only install the bundle +
its dependencies from MANFIEST (if not already available). Additional
dependencies will be ignored, and expected to be already available in
the target application.
http://www.eclipse.org/tycho/sitedocs/tycho-surefire/tycho-surefire-plugi...
However, I understand this can quickly become a kind of limitation. Feel
free to open a bug against Tycho asking for support of additional
dependencies. Please add me in CC.
2. Second try to run usually ends up with
[INFO] Installing IUs [org.jboss.tools.foundation.core.test,
org.eclipse.tycho.surefire.osgibooter,
org.eclipse.tycho.surefire.junit4] to
/home/eskimo/jbdevstudio-java-with-space/studio
Installing org.jboss.tools.foundation.core.test
1.1.0.Alpha1-v20131109-0206.
Installing org.eclipse.tycho.surefire.osgibooter 0.19.0.
Installing org.eclipse.tycho.surefire.junit4 0.19.0.
Installation failed.
Cannot complete the install because of a conflicting dependency.
Software being installed: JBoss Foundation Tests
1.1.0.Alpha1-v20131109-0206 (org.jboss.tools.foundation.core.test
1.1.0.Alpha1-v20131109-0206)
Software currently installed: JBoss Foundation Tests
1.1.0.Alpha1-v20131109-0203 (org.jboss.tools.foundation.core.test
1.1.0.Alpha1-v20131109-0203)
Only one of the following can be installed at once:
JBoss Foundation Tests 1.1.0.Alpha1-v20131109-0203
(org.jboss.tools.foundation.core.test 1.1.0.Alpha1-v20131109-0203)
JBoss Foundation Tests 1.1.0.Alpha1-v20131109-0206
(org.jboss.tools.foundation.core.test 1.1.0.Alpha1-v20131109-0206)
Application failed, log file location:
/tmp/config3255596288906066066equinox/1383962733126.log
[INFO]
------------------------------------------------------------------------
That's
because Foundation Tests is a singleton, and that you tried to
run tests twice which caused to install the same bundle twice. p2
doesn't allow multiple version in same application.
If possible, remove the singleton directive from bundle. If not, then
you need to use a clean application (which doesn't already contain the
bundle) for every tests.
3. Also I've seen problems with shutting down the RCP
installation:
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.jboss.tools.foundation.core.test.FoundationAllTests
[...]
Results :
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0
Job found still running after platform shutdown. Jobs should be
canceled by the plugin that scheduled them during shutdown:
org.eclipse.ui.internal.decorators.DecorationScheduler$3
Job found still running after platform shutdown. Jobs should be
canceled by the plugin that scheduled them during shutdown:
org.eclipse.ui.internal.decorators.DecorationScheduler$1
Job found still running after platform shutdown. Jobs should be
canceled by the plugin that scheduled them during shutdown:
org.eclipse.ui.internal.progress.AnimationManager$1
An error has occurred. See the log file
/home/eskimo/Projects/jbdevstudio/src-fork/jbosstools-base/foundation/tests/org.jboss.tools.foundation.core.test/target/work/data/.metadata/.log.
So it looks like pending jobs cause application to send an error code.
Not sure of who's responsible of that. I tend to think it can be an
issue with the tycho surefirebooter application.
Please open a bug against Tycho and add me in CC.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
9:25 a.m.
On 11/12/2013 12:37 AM, Mickael Istria wrote:
On 11/09/2013 03:17 AM, Denis Golovin wrote:
> 1. Not all our test plug-ins are ready to be used with this feature
> due to forgetting include test projects into binary build; so far
> I've found o.j.t.tests.test and o.j.t.foundation.core.test have such
> problem; I couldn't go further than foundation.core.test plug-in
> because of problems explained below
I don't understand this issue. You mean that surefire-plugin was
configured to include dependencies, and that using an installed
application doesn't work? If so, it's somehow normal, Tycho will
ignore the extra-depedencies with this mode, and will only install the
bundle + its dependencies from MANFIEST (if not already available).
Additional dependencies will be ignored, and expected to be already
available in the target application.
http://www.eclipse.org/tycho/sitedocs/tycho-surefire/tycho-surefire-plugi...
However, I understand this can quickly become a kind of limitation.
Feel free to open a bug against Tycho asking for support of additional
dependencies. Please add me in CC.
It is build.properties problems when not all resources from test plug-in
are included into bundle jar. Should be fixed.
>
> 2. Second try to run usually ends up with
>
> [INFO] Installing IUs [org.jboss.tools.foundation.core.test,
> org.eclipse.tycho.surefire.osgibooter,
> org.eclipse.tycho.surefire.junit4] to
> /home/eskimo/jbdevstudio-java-with-space/studio
> Installing org.jboss.tools.foundation.core.test
> 1.1.0.Alpha1-v20131109-0206.
> Installing org.eclipse.tycho.surefire.osgibooter 0.19.0.
> Installing org.eclipse.tycho.surefire.junit4 0.19.0.
> Installation failed.
> Cannot complete the install because of a conflicting dependency.
> Software being installed: JBoss Foundation Tests
> 1.1.0.Alpha1-v20131109-0206 (org.jboss.tools.foundation.core.test
> 1.1.0.Alpha1-v20131109-0206)
> Software currently installed: JBoss Foundation Tests
> 1.1.0.Alpha1-v20131109-0203 (org.jboss.tools.foundation.core.test
> 1.1.0.Alpha1-v20131109-0203)
> Only one of the following can be installed at once:
> JBoss Foundation Tests 1.1.0.Alpha1-v20131109-0203
> (org.jboss.tools.foundation.core.test 1.1.0.Alpha1-v20131109-0203)
> JBoss Foundation Tests 1.1.0.Alpha1-v20131109-0206
> (org.jboss.tools.foundation.core.test 1.1.0.Alpha1-v20131109-0206)
> Application failed, log file location:
> /tmp/config3255596288906066066equinox/1383962733126.log
> [INFO]
> ------------------------------------------------------------------------
That's because Foundation Tests is a singleton, and that you tried to
run tests twice which caused to install the same bundle twice. p2
doesn't allow multiple version in same application.
If possible, remove the singleton directive from bundle. If not, then
you need to use a clean application (which doesn't already contain the
bundle) for every tests.
If I cannot change test an then run it again and again against the same
product installation then there is no point to use this feature in
development.
Should it be updating singleton instead of installing it? Would that help?
> 3. Also I've seen problems with shutting down the RCP installation:
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.jboss.tools.foundation.core.test.FoundationAllTests
> [...]
> Results :
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0
>
> Job found still running after platform shutdown. Jobs should be
> canceled by the plugin that scheduled them during shutdown:
> org.eclipse.ui.internal.decorators.DecorationScheduler$3
> Job found still running after platform shutdown. Jobs should be
> canceled by the plugin that scheduled them during shutdown:
> org.eclipse.ui.internal.decorators.DecorationScheduler$1
> Job found still running after platform shutdown. Jobs should be
> canceled by the plugin that scheduled them during shutdown:
> org.eclipse.ui.internal.progress.AnimationManager$1
> An error has occurred. See the log file
>
/home/eskimo/Projects/jbdevstudio/src-fork/jbosstools-base/foundation/tests/org.jboss.tools.foundation.core.test/target/work/data/.metadata/.log.
So it looks like pending jobs cause application to send an error code.
Not sure of who's responsible of that. I tend to think it can be an
issue with the tycho surefirebooter application.
Please open a bug against Tycho and add me in CC.
I'll do that.
Thanks
Denis
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
9:32 a.m.
On 11/13/2013 09:25 AM, Denis Golovin wrote:
It is build.properties problems when not all resources from test
plug-in are included into bundle jar. Should be fixed.
Cool.
>>
>> 2. Second try to run usually ends up with
>>
>> [INFO] Installing IUs [org.jboss.tools.foundation.core.test,
>> org.eclipse.tycho.surefire.osgibooter,
>> org.eclipse.tycho.surefire.junit4] to
>> /home/eskimo/jbdevstudio-java-with-space/studio
>> Installing org.jboss.tools.foundation.core.test
>> 1.1.0.Alpha1-v20131109-0206.
>> Installing org.eclipse.tycho.surefire.osgibooter 0.19.0.
>> Installing org.eclipse.tycho.surefire.junit4 0.19.0.
>> Installation failed.
>> Cannot complete the install because of a conflicting dependency.
>> Software being installed: JBoss Foundation Tests
>> 1.1.0.Alpha1-v20131109-0206 (org.jboss.tools.foundation.core.test
>> 1.1.0.Alpha1-v20131109-0206)
>> Software currently installed: JBoss Foundation Tests
>> 1.1.0.Alpha1-v20131109-0203 (org.jboss.tools.foundation.core.test
>> 1.1.0.Alpha1-v20131109-0203)
>> Only one of the following can be installed at once:
>> JBoss Foundation Tests 1.1.0.Alpha1-v20131109-0203
>> (org.jboss.tools.foundation.core.test 1.1.0.Alpha1-v20131109-0203)
>> JBoss Foundation Tests 1.1.0.Alpha1-v20131109-0206
>> (org.jboss.tools.foundation.core.test 1.1.0.Alpha1-v20131109-0206)
>> Application failed, log file location:
>> /tmp/config3255596288906066066equinox/1383962733126.log
>> [INFO]
>> ------------------------------------------------------------------------
> That's because Foundation Tests is a singleton, and that you tried to
> run tests twice which caused to install the same bundle twice. p2
> doesn't allow multiple version in same application.
> If possible, remove the singleton directive from bundle. If not, then
> you need to use a clean application (which doesn't already contain
> the bundle) for every tests.
If I cannot change test an then run it again and again against the
same product installation then there is no point to use this feature
in development.
Should it be updating singleton instead of installing it? Would that help?
If you
can avoid singletons, p2 will allow installation of multiple
version of the same plugin. And you shouldn't see this error.
Otherwise, it means that you'll need either to uninstall previous
version of the bundle, or run tests on a clean application everytime.
Singletons are only necessary when plugin define extension points or
extensions. Bundle org.jboss.tools.foundation.test doesn't provide
anything like that. Just get rid of the plugin.xml, remove the singleton
directive in
https://github.com/jbosstools/jbosstools-base/blob/master/foundation/test...
, and p2 would allow several installations of the bundle so you'll be
able to sequentially run tests on the same application without
uninstalling anything.
> Please open a bug against Tycho and add me in CC.
I'll do that.
Thx
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
9:42 a.m.
On 11/13/2013 12:32 AM, Mickael Istria wrote:
On 11/13/2013 09:25 AM, Denis Golovin wrote:
>
> It is build.properties problems when not all resources from test
> plug-in are included into bundle jar. Should be fixed.
Cool.
>>>
>>> 2. Second try to run usually ends up with
>>>
>>> [INFO] Installing IUs [org.jboss.tools.foundation.core.test,
>>> org.eclipse.tycho.surefire.osgibooter,
>>> org.eclipse.tycho.surefire.junit4] to
>>> /home/eskimo/jbdevstudio-java-with-space/studio
>>> Installing org.jboss.tools.foundation.core.test
>>> 1.1.0.Alpha1-v20131109-0206.
>>> Installing org.eclipse.tycho.surefire.osgibooter 0.19.0.
>>> Installing org.eclipse.tycho.surefire.junit4 0.19.0.
>>> Installation failed.
>>> Cannot complete the install because of a conflicting dependency.
>>> Software being installed: JBoss Foundation Tests
>>> 1.1.0.Alpha1-v20131109-0206 (org.jboss.tools.foundation.core.test
>>> 1.1.0.Alpha1-v20131109-0206)
>>> Software currently installed: JBoss Foundation Tests
>>> 1.1.0.Alpha1-v20131109-0203 (org.jboss.tools.foundation.core.test
>>> 1.1.0.Alpha1-v20131109-0203)
>>> Only one of the following can be installed at once:
>>> JBoss Foundation Tests 1.1.0.Alpha1-v20131109-0203
>>> (org.jboss.tools.foundation.core.test 1.1.0.Alpha1-v20131109-0203)
>>> JBoss Foundation Tests 1.1.0.Alpha1-v20131109-0206
>>> (org.jboss.tools.foundation.core.test 1.1.0.Alpha1-v20131109-0206)
>>> Application failed, log file location:
>>> /tmp/config3255596288906066066equinox/1383962733126.log
>>> [INFO]
>>> ------------------------------------------------------------------------
>> That's because Foundation Tests is a singleton, and that you tried
>> to run tests twice which caused to install the same bundle twice. p2
>> doesn't allow multiple version in same application.
>> If possible, remove the singleton directive from bundle. If not,
>> then you need to use a clean application (which doesn't already
>> contain the bundle) for every tests.
>
> If I cannot change test an then run it again and again against the
> same product installation then there is no point to use this feature
> in development.
>
> Should it be updating singleton instead of installing it? Would that
> help?
If you can avoid singletons, p2 will allow installation of multiple
version of the same plugin. And you shouldn't see this error.
Otherwise, it means that you'll need either to uninstall previous
version of the bundle, or run tests on a clean application everytime.
Singletons are only necessary when plugin define extension points or
extensions. Bundle org.jboss.tools.foundation.test doesn't provide
anything like that. Just get rid of the plugin.xml, remove the
singleton directive in
https://github.com/jbosstools/jbosstools-base/blob/master/foundation/test...
, and p2 would allow several installations of the bundle so you'll be
able to sequentially run tests on the same application without
uninstalling anything.
Not all tests can be singletons, If we cannot have tests
singletons, how
we suppose to test extension points?
>
>> Please open a bug against Tycho and add me in CC.
>
> I'll do that.
Thx
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
9:48 a.m.
On 11/13/2013 09:42 AM, Denis Golovin wrote:
Not all tests can be singletons, If we cannot have tests singletons,
how we suppose to test extension points?
That's indeed a limitation for now. In
case of singleton, then you'll
need to uninstall previous bundle manually, or always re-install a new
application.
Another workaround is to split the singleton plugin and the test one,
but I understand that's much overhead and not a very comfortable option.
You can also open an enhancement request in Tycho to explain the
use-case, so I'll negociate to have surefire first uninstall previous
installation in case of a singleton. But this won't happen soon (at
least not before next Tycho release).
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
12:15 p.m.
I'm not fully grokking this.
Are we talking about the install that is used already have an install of the test plugin
or about it not being possible to install tests plugin into the install ?
The first one just don't make sense to me. The whole point is to test against a real
eclipse. This eclipse shouldn't have any test plugins anyway.
If it is the second - then that seems to be rather limiting since then 99.9% Ui driven
eclipse plugins are singletons.
/max (sent from my phone)
On 13/11/2013, at 09.49, Mickael Istria <mistria(a)redhat.com>
wrote:
> On 11/13/2013 09:42 AM, Denis Golovin wrote:
> Not all tests can be singletons, If we cannot have tests singletons, how we suppose
to test extension points?
That's indeed a limitation for now. In case of singleton, then you'll need to
uninstall previous bundle manually, or always re-install a new application.
Another workaround is to split the singleton plugin and the test one, but I understand
that's much overhead and not a very comfortable option.
You can also open an enhancement request in Tycho to explain the use-case, so I'll
negociate to have surefire first uninstall previous installation in case of a singleton.
But this won't happen soon (at least not before next Tycho release).
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
12:27 p.m.
On 11/13/2013 12:15 PM, Max Andersen wrote:
Are we talking about the install that is used already have an install
of the test plugin
Yes, that's what we are talking about: when test plugin is a
singleton,
and a previous test already installed another version of this singleton
in the install.
It's not blocker usage, but it makes the feedback loop longer while
writing/testing/debugging a test.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
1:02 p.m.
On 13/11/2013, at 12.27, Mickael Istria <mistria(a)redhat.com>
wrote:
> On 11/13/2013 12:15 PM, Max Andersen wrote:
> Are we talking about the install that is used already have an install of the test
plugin
Yes, that's what we are talking about: when test plugin is a singleton, and a
previous test already installed another version of this singleton in the install.
It's not blocker usage, but it makes the feedback loop longer while
writing/testing/debugging a test.
My expectations kinda was that the test run would cleanup after itself...
But I can see how that would be not always possible.
I think I'll try creating the install, run git init and commit everything. Then it
should be close to instant to revert the test install.
Would be nice if tycho could have option to uninstall/revert what it installed.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets
12:58 p.m.
On 13/11/2013, at 09.25, Denis Golovin <dgolovin(a)exadel.com>
wrote:
If I cannot change test an then run it again and again against the same product
installation then there is no point to use this feature in development.
Should it be updating singleton instead of installing it? Would that help?
Ah now I get it. Sounds like it should allow to uninstall what it in installed....
10:13 a.m.
On Tue, Nov 12, 2013 at 09:37:08AM +0100, Mickael Istria wrote:
On 11/09/2013 03:17 AM, Denis Golovin wrote:
>1. Not all our test plug-ins are ready to be used with this feature
>due to forgetting include test projects into binary build; so far
>I've found o.j.t.tests.test and o.j.t.foundation.core.test have such
>problem; I couldn't go further than foundation.core.test plug-in
>because of problems explained below
I don't understand this issue. You mean that surefire-plugin was
configured to include dependencies, and that using an installed
application doesn't work? If so, it's somehow normal, Tycho will
ignore the extra-depedencies with this mode, and will only install the
bundle + its dependencies from MANFIEST (if not already available).
Additional dependencies will be ignored, and expected to be already
available in the target application.
http://www.eclipse.org/tycho/sitedocs/tycho-surefire/tycho-surefire-plugi...
However, I understand this can quickly become a kind of limitation.
Feel free to open a bug against Tycho asking for support of additional
dependencies. Please add me in CC.
I definitely think it should be possible to install these additional dependencies
since why else should they be listed there ?
/max
11:10 a.m.
On 11/14/2013 10:13 AM, Max Rydahl Andersen wrote:
I definitely think it should be possible to install these additional
dependencies
since why else should they be listed there ?
Can you share your POV on
bugs.eclipse.org ? ;)
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
1:20 p.m.
On Thu, Nov 14, 2013 at 11:10:37AM +0100, Mickael Istria wrote:
On 11/14/2013 10:13 AM, Max Rydahl Andersen wrote:
>I definitely think it should be possible to install these additional
>dependencies
>since why else should they be listed there ?
Can you share your POV on bugs.eclipse.org ? ;)
yes, once I understand the usecase of why you would not want these installed ?
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
1:33 p.m.
On 11/14/2013 01:20 PM, Max Rydahl Andersen wrote:
On Thu, Nov 14, 2013 at 11:10:37AM +0100, Mickael Istria wrote:
> On 11/14/2013 10:13 AM, Max Rydahl Andersen wrote:
>> I definitely think it should be possible to install these additional
>> dependencies
>> since why else should they be listed there ?
> Can you share your POV on bugs.eclipse.org ? ;)
yes, once I understand the usecase of why you would not want these
installed ?
I don't know any use-case that drove that choice. It's just
that at the
time we developed it, it didn't sound bad to ignore them in a
p2installed scenario. It could simply be a bad choice.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
11:19 a.m.
This is really useful for running our integration tests (as opposed to unit tests ;)
Can you add something to
https://github.com/jbosstools/jbosstools-devdoc/tree/master/building
about this feature and document both how to run it against jbds and a plain eclipse since
thats where BYOE scenarioes would be tested.
/max
On Fri, Nov 08, 2013 at 04:04:38PM +0100, Mickael Istria wrote:
Hi all,
With Tycho 0.19.0, we could fix the long-standing issue JBIDE-13869.
This will allow you to run your test with Maven against an RCP
application which is available in your filesystem.
You can do it by simply running for example:
$ cd tests/my.test.bundle
$ mvn clean verify -Dtest.profileName=epp.package.jee
-Dtest.installPath=/home/me/eclipse-4.4.M2
If test.installPath is not set, you get the default surefire behaviour
which is to generate a simple minimal installation to run the tests in
target/work.
More info about the profileName can be found in
http://wiki.eclipse.org/Tycho/Testing_with_Surefire#p2Installed_on_provis...
. This works on any RCP application that relies on p2 (in case you
want to test JBoss Tools inside Websphere Studio ;).
We've configured it so that by default, it is JBDS-friendly and set
the jbds profileName. So to test on JBDS, you can simply use:
$ mvn clean verify
-Dtest.installPath=/home/me/jbdevstudio-8.0.0.Alpha1-SNAPSHOT/studio
Except a few exception, other surefire parameters, such as the very
cool debugPort parameter, can be used together with this mechanism.
Enjoy!
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
9:39 a.m.
On 11/11/2013 11:19 AM, Max Rydahl Andersen wrote:
Can you add something to
https://github.com/jbosstools/jbosstools-devdoc/tree/master/building
about this feature and document both how to run it against jbds and a
plain eclipse since
thats where BYOE scenarioes would be tested.
What about renaming folder debugging
into testing_and_debugging and
adding a page there instead?
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
10:19 a.m.
On Tue, Nov 12, 2013 at 09:39:36AM +0100, Mickael Istria wrote:
On 11/11/2013 11:19 AM, Max Rydahl Andersen wrote:
>Can you add something to
>https://github.com/jbosstools/jbosstools-devdoc/tree/master/building
>about this feature and document both how to run it against jbds and
>a plain eclipse since
>thats where BYOE scenarioes would be tested.
What about renaming folder debugging into testing_and_debugging and
adding a page there instead?
adding a "testing" folder works too. Plenty of content spread outside this
devdoc that could make sense for our various unit and integration test
"defacto" standards ;)
/max
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
1:43 p.m.
On 11/14/2013 10:19 AM, Max Rydahl Andersen wrote:
On Tue, Nov 12, 2013 at 09:39:36AM +0100, Mickael Istria wrote:
> On 11/11/2013 11:19 AM, Max Rydahl Andersen wrote:
>> Can you add something to
>> https://github.com/jbosstools/jbosstools-devdoc/tree/master/building
>> about this feature and document both how to run it against jbds and
>> a plain eclipse since
>> thats where BYOE scenarioes would be tested.
> What about renaming folder debugging into testing_and_debugging and
> adding a page there instead?
adding a "testing" folder works too. Plenty of content spread outside
this
devdoc that could make sense for our various unit and integration test
"defacto" standards ;)
I made it simple:
https://github.com/jbosstools/jbosstools-devdoc/pull/26
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
3823
days inactive
3829
days old
jbosstools-dev@lists.jboss.org
21 comments
4 participants
participants (4)
-
Denis Golovin -
Max Andersen -
Max Rydahl Andersen
-
Mickael Istria