Discussion:
Tycho-Surefire guessing the Test Framework
(too old to reply)
Hervé Esteguet
2012-05-15 08:45:35 UTC
Permalink
Hello,

One of my bundles, which is not a test bundle, has '.tests' as suffix.
So tycho-pomgenerator assign to that bundle, the 'eclipse-test-plugin' packaging.
When i try to run tests i got the following error:

[Could not determine test framework used by test bundle MavenProject: XXX.XXX.XXX.util.tests:0.2.0-SNAPSHOT]

I try to set the option failIfNoTests to false, but i still got the same error.

By overlooking the code of TestMojo from tycho 0.14.x sources, i discovered that tycho try to guess the test framework to use by searching JUnit declaration into the bundle classpath and failed if it doesn't find one.

I think that tycho should not failed when it could not guess the test framework if the option failIfNotTests is set to false.

Is anyone as already encountered this issue ?


Thanks in advance, for your answers.
Best regards.
Jeff MAURY
2012-05-15 09:19:49 UTC
Permalink
If it is not a test bundle, why do you keep the eclipse-test-plugin
packaging ?
I suspect Tycho/Maven is trying to find some test classes and does not find
them so the error.

Jeff


On Tue, May 15, 2012 at 10:45 AM, Hervé Esteguet <***@mia-software.com
> wrote:

> Hello,
>
> One of my bundles, which is not a test bundle, has '.tests' as suffix.
> So tycho-pomgenerator assign to that bundle, the 'eclipse-test-plugin'
> packaging.
> When i try to run tests i got the following error:
>
> [Could not determine test framework used by test bundle MavenProject:
> XXX.XXX.XXX.util.tests:0.2.0-SNAPSHOT]
>
> I try to set the option failIfNoTests to false, but i still got the same
> error.
>
> By overlooking the code of TestMojo from tycho 0.14.x sources, i
> discovered that tycho try to guess the test framework to use by searching
> JUnit declaration into the bundle classpath and failed if it doesn't find
> one.
>
> I think that tycho should not failed when it could not guess the test
> framework if the option failIfNotTests is set to false.
>
> Is anyone as already encountered this issue ?
>
>
> Thanks in advance, for your answers.
> Best regards.
> _______________________________________________
> tycho-user mailing list
> tycho-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/tycho-user
>



--
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
- Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury
Hervé Esteguet
2012-05-15 09:31:31 UTC
Permalink
I operate in a context of continuous integration.
My tests and bundles are intended to be run and build on jenkins, my poms are regenerated automically
before every build.
The consequence is that i can't manually change the eclipse-test-plugin to eclipse-plugin, to do so i'll have to find a way to do this automatically may be by using an XSLT transformation (an approach that i would rather avoid for just one bundle over 30).

Hervé
Mickael Istria
2012-05-15 09:41:44 UTC
Permalink
On 05/15/2012 11:31 AM, Hervé Esteguet wrote:
> I operate in a context of continuous integration.
> My tests and bundles are intended to be run and build on jenkins, my poms are regenerated automically
> before every build.
Pom files have to be managed, and committed. They do not change often,
so there is no gain in regenerating them on each build.
You should generate them once and commit them, otherwise you loose a lot
of ability to customize your build and you prevent your developers from
running build locally.
--
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>
Jeff MAURY
2012-05-15 09:45:33 UTC
Permalink
+1


Tycho has been designed so that almost all of the project information is
extract from the MANIFEST.MF file so you dont need to generate them.

Jeff


On Tue, May 15, 2012 at 11:41 AM, Mickael Istria <***@redhat.com> wrote:

> On 05/15/2012 11:31 AM, Hervé Esteguet wrote:
>
> I operate in a context of continuous integration.
> My tests and bundles are intended to be run and build on jenkins, my poms are regenerated automically
> before every build.
>
> Pom files have to be managed, and committed. They do not change often, so
> there is no gain in regenerating them on each build.
> You should generate them once and commit them, otherwise you loose a lot
> of ability to customize your build and you prevent your developers from
> running build locally.
> --
> 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>
>
> _______________________________________________
> tycho-user mailing list
> tycho-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/tycho-user
>
>


--
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
- Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury
Igor Fedorenko
2012-05-15 13:30:41 UTC
Permalink
Do not automatically regenerate pom.xml files. Do this once, commit
generated pom.xml files into your source code repository and maintain
them as any other source file from there on.

tycho-pomgenerator was never meant to and will never support
regeneration of pom.xml files.

--
Regards,
Igor

On 12-05-15 5:31 AM, Hervé Esteguet wrote:
> I operate in a context of continuous integration.
> My tests and bundles are intended to be run and build on jenkins, my poms are regenerated automically
> before every build.
> The consequence is that i can't manually change the eclipse-test-plugin to eclipse-plugin, to do so i'll have to find a way to do this automatically may be by using an XSLT transformation (an approach that i would rather avoid for just one bundle over 30).
>
> Hervé
>
> _______________________________________________
> tycho-user mailing list
> tycho-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/tycho-user
Hervé Esteguet
2012-05-15 09:56:27 UTC
Permalink
Thanks for your answer.

In our dev team we separate releng concerns from dev ones. Our idea is that, it's not the same person which is responsible for the development and for the release engineering. The releng engineer maintains a project which inject tycho configuration during the build process on CI. By doing so we separate eclipse bundle development from maven considerations.

Herve

----- Original Message -----
From: "Mickael Istria" <***@redhat.com>
To: "Tycho user list" <tycho-***@eclipse.org>
Sent: Mardi 15 Mai 2012 11:41:44
Subject: Re: [tycho-user] Tycho-Surefire guessing the Test Framework


On 05/15/2012 11:31 AM, Hervé Esteguet wrote:

I operate in a context of continuous integration.
My tests and bundles are intended to be run and build on jenkins, my poms are regenerated automically
before every build. Pom files have to be managed, and committed. They do not change often, so there is no gain in regenerating them on each build.
You should generate them once and commit them, otherwise you loose a lot of ability to customize your build and you prevent your developers from running build locally.

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets
Mickael Istria
2012-05-15 10:12:37 UTC
Permalink
On 05/15/2012 11:56 AM, Hervé Esteguet wrote:
> In our dev team we separate releng concerns from dev ones.
Sounds like a bad idea to separate them. They are tightly coupled. Code
affects releng, releng affects code. You cannot isolate them.

> Our idea is that, it's not the same person which is responsible for the development and for the release engineering.
Ok, but IMHO, the guy doing release engineering is part of the dev team,
and should be allowed to commit poms into bundles.

> The releng engineer maintains a project which inject tycho configuration during the build process on CI. By doing so we separate eclipse bundle development from maven considerations.
What is the gain in separating? Looks like it makes things more
difficult. Moreover, separating both concerns prevent your devs from
testing local builds and so on. By isolating, you reduce cooperation.
--
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>
Hervé Esteguet
2012-05-15 10:41:34 UTC
Permalink
> What is the gain in separating?

- We avoid polluting source with maven metadata. Tycho is not yet the native method used by eclipse to build bundles from the workbench. When it will be so, the presence of the pom.xml into a plugin source will be justified.

- The releng engineer is not always allowed to modify the source repository which can be of different sources and natures. In fact the project could depends on others projects in which you just have a readonly access.

> Looks like it makes things more difficult

- Tycho make this approach easier, in most case the modification of the pom parent generated by tycho will suffice to configure the whole build process (an XSLT transformation do the trick). There are small cases like the original subject of this thread which complicated things.

----- Original Message -----
From: "Mickael Istria" <***@redhat.com>
To: "Tycho user list" <tycho-***@eclipse.org>
Sent: Mardi 15 Mai 2012 12:12:37
Subject: Re: [tycho-user] Tycho-Surefire guessing the Test Framework


On 05/15/2012 11:56 AM, Hervé Esteguet wrote:

In our dev team we separate releng concerns from dev ones. Sounds like a bad idea to separate them. They are tightly coupled. Code affects releng, releng affects code. You cannot isolate them.



Our idea is that, it's not the same person which is responsible for the development and for the release engineering. Ok, but IMHO, the guy doing release engineering is part of the dev team, and should be allowed to commit poms into bundles.



The releng engineer maintains a project which inject tycho configuration during the build process on CI. By doing so we separate eclipse bundle development from maven considerations.

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets
Mickael Istria
2012-05-15 10:53:45 UTC
Permalink
On 05/15/2012 12:41 PM, Hervé Esteguet wrote:
> - We avoid polluting source with maven metadata.
You do not pollute: you add the necessary stuff to let anyone perform a
build locally in an equivalent way as your production build. IMO XSLT is
more pollution in a build process than a pom is. Pom is straightforward,
XSLT is workaround.

> Tycho is not yet the native method used by eclipse to build bundles from the workbench. When it will be so, the presence of the pom.xml into a plugin source will be justified.
It is your native method to build. Giving your developers an opportunity
to see how the build will behave by typing "mvn install" in a console is
priceless.

> - The releng engineer is not always allowed to modify the source repository which can be of different sources and natures. In fact the project could depends on others projects in which you just have a readonly access.
Too bad.

> - Tycho make this approach easier, in most case the modification of
> the pom parent generated by tycho will suffice to configure the whole
> build process (an XSLT transformation do the trick). There are small
> cases like the original subject of this thread which complicated things.
You should really try a less constrained approach and generate your pom
once, commit them, and make release engineers committers on the project
they are working one. You'll quickly see a lot of difficulties disappear.

My 2c.
--
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>
Jeff MAURY
2012-05-15 10:54:20 UTC
Permalink
I agree with Michael that devs and release teams not cooperating is not a
good idea at all.

Jeff


On Tue, May 15, 2012 at 12:41 PM, Hervé Esteguet <***@mia-software.com
> wrote:

> > What is the gain in separating?
>
> - We avoid polluting source with maven metadata. Tycho is not yet the
> native method used by eclipse to build bundles from the workbench. When it
> will be so, the presence of the pom.xml into a plugin source will be
> justified.
>
> - The releng engineer is not always allowed to modify the source
> repository which can be of different sources and natures. In fact the
> project could depends on others projects in which you just have a readonly
> access.
>
> > Looks like it makes things more difficult
>
> - Tycho make this approach easier, in most case the modification of the
> pom parent generated by tycho will suffice to configure the whole build
> process (an XSLT transformation do the trick). There are small cases like
> the original subject of this thread which complicated things.
>
> ----- Original Message -----
> From: "Mickael Istria" <***@redhat.com>
> To: "Tycho user list" <tycho-***@eclipse.org>
> Sent: Mardi 15 Mai 2012 12:12:37
> Subject: Re: [tycho-user] Tycho-Surefire guessing the Test Framework
>
>
> On 05/15/2012 11:56 AM, Hervé Esteguet wrote:
>
> In our dev team we separate releng concerns from dev ones. Sounds like a
> bad idea to separate them. They are tightly coupled. Code affects releng,
> releng affects code. You cannot isolate them.
>
>
>
> Our idea is that, it's not the same person which is responsible for the
> development and for the release engineering. Ok, but IMHO, the guy doing
> release engineering is part of the dev team, and should be allowed to
> commit poms into bundles.
>
>
>
> The releng engineer maintains a project which inject tycho configuration
> during the build process on CI. By doing so we separate eclipse bundle
> development from maven considerations.
>
> --
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat
> My blog - My Tweets
> _______________________________________________
> tycho-user mailing list
> tycho-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/tycho-user
> _______________________________________________
> tycho-user mailing list
> tycho-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/tycho-user
>



--
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
- Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury
Dieter Van de Walle
2012-05-15 11:00:31 UTC
Permalink
When creating a software project, there is a need for reliable and
reproducable creation of builds.
To do this, a build tool is chosen and build metadata is committed with
the source.

As far as I understand it, you have chosen Eclipse as the main build tool.
The releng engineers then need to try to reproduce the build using Maven.

In my view, it is the responsability of the devs to supply a reliable,
tested and reproducable build.
How this is packaged and deployed is another concern.

However, relying on Eclipse as the main build tool seems like a bad idea.
Do you persist the Eclipse configuration also somewhere?
What build metadata do you persist? Eclipse project files?

IMO, Maven should be the main build tool.
I would be satisfied if I can produce a build using Maven, and Eclipse
offers only text highlighting and editing. All the rest is extra,
because build reproducability in time and between machines is primary.

Getting a project working in Eclipse and not in Maven is the equivalent
of "works on my machine" for me. Not acceptable.

However, if you think there is a valid use case for this, please explain!
Maybe in your situation it makes sense, I would like to understand.

Dieter

On 05/15/2012 12:41 PM, Hervé Esteguet wrote:
>> What is the gain in separating?
> - We avoid polluting source with maven metadata. Tycho is not yet the native method used by eclipse to build bundles from the workbench. When it will be so, the presence of the pom.xml into a plugin source will be justified.
>
> - The releng engineer is not always allowed to modify the source repository which can be of different sources and natures. In fact the project could depends on others projects in which you just have a readonly access.
>
>> Looks like it makes things more difficult
> - Tycho make this approach easier, in most case the modification of the pom parent generated by tycho will suffice to configure the whole build process (an XSLT transformation do the trick). There are small cases like the original subject of this thread which complicated things.
>
> ----- Original Message -----
> From: "Mickael Istria"<***@redhat.com>
> To: "Tycho user list"<tycho-***@eclipse.org>
> Sent: Mardi 15 Mai 2012 12:12:37
> Subject: Re: [tycho-user] Tycho-Surefire guessing the Test Framework
>
>
> On 05/15/2012 11:56 AM, Hervé Esteguet wrote:
>
> In our dev team we separate releng concerns from dev ones. Sounds like a bad idea to separate them. They are tightly coupled. Code affects releng, releng affects code. You cannot isolate them.
>
>
>
> Our idea is that, it's not the same person which is responsible for the development and for the release engineering. Ok, but IMHO, the guy doing release engineering is part of the dev team, and should be allowed to commit poms into bundles.
>
>
>
> The releng engineer maintains a project which inject tycho configuration during the build process on CI. By doing so we separate eclipse bundle developmen
X Shel
2012-05-15 12:10:34 UTC
Permalink
Hi there

I dont know if i completely understand the subject. But i'll try to give my
point of view.

> As far as I understand it, you have chosen Eclipse as the main build tool.
> The releng engineers then need to try to reproduce the build using Maven.

In a development phase, an eclipse plugin developper should only rely on
PDE tools to run its tests or to validate its mofidications.
In a context of continuous integration of eclipse-based project, non
intrusive tools such as buckminster or now tycho are usually used.

>IMO, Maven should be the main build tool.
>I would be satisfied if I can produce a build using Maven, and Eclipse
>offers only text highlighting and editing.

As i understand it, Eclipse PDE internally use ant generated scripts to
build plugins. Those scripts are generated using configuration files such
as build.properties and others.

> However, if you think there is a valid use case for this, please explain!
> Maybe in your situation it makes sense, I would like to understand.

I can see a use case that i've recently encourter, migrating a
buckminster-based build process into a tycho-based one, with sources only
accessible in a readonly mode.


----- Original Message -----
From: "Dieter Van de Walle" <***@ebit.be>
To: tycho-***@eclipse.org
Sent: Mardi 15 Mai 2012 13:00:31
Subject: Re: [tycho-user] Tycho-Surefire guessing the Test Framework

When creating a software project, there is a need for reliable and
reproducable creation of builds.
To do this, a build tool is chosen and build metadata is committed with
the source.

As far as I understand it, you have chosen Eclipse as the main build tool.
The releng engineers then need to try to reproduce the build using Maven.

In my view, it is the responsability of the devs to supply a reliable,
tested and reproducable build.
How this is packaged and deployed is another concern.

However, relying on Eclipse as the main build tool seems like a bad idea.
Do you persist the Eclipse configuration also somewhere?
What build metadata do you persist? Eclipse project files?

IMO, Maven should be the main build tool.
I would be satisfied if I can produce a build using Maven, and Eclipse
offers only text highlighting and editing. All the rest is extra,
because build reproducability in time and between machines is primary.

Getting a project working in Eclipse and not in Maven is the equivalent
of "works on my machine" for me. Not acceptable.

However, if you think there is a valid use case for this, please explain!
Maybe in your situation it makes sense, I would like to understand.

Dieter

On 05/15/2012 12:41 PM, Hervé Esteguet wrote:
>> What is the gain in separating?
> - We avoid polluting source with maven metadata. Tycho is not yet the
native method used by eclipse to build bundles from the workbench. When it
will be so, the presence of the pom.xml into a plugin source will be
justified.
>
> - The releng engineer is not always allowed to modify the source
repository which can be of different sources and natures. In fact the
project could depends on others projects in which you just have a readonly
access.
>
>> Looks like it makes things more difficult
> - Tycho make this approach easier, in most case the modification of the
pom parent generated by tycho will suffice to configure the whole build
process (an XSLT transformation do the trick). There are small cases like
the original subject of this thread which complicated things.
>
> ----- Original Message -----
> From: "Mickael Istria"<***@redhat.com>
> To: "Tycho user list"<tycho-***@eclipse.org>
> Sent: Mardi 15 Mai 2012 12:12:37
> Subject: Re: [tycho-user] Tycho-Surefire guessing the Test Framework
>
>
> On 05/15/2012 11:56 AM, Hervé Esteguet wrote:
>
> In our dev team we separate releng concerns from dev ones. Sounds like a
bad idea to separate them. They are tightly coupled. Code affects releng,
releng affects code. You cannot isolate them.
>
>
>
> Our idea is that, it's not the same person which is responsible for the
development and for the release engineering. Ok, but IMHO, the guy doing
release engineering is part of the dev team, and should be allowed to
commit poms into bundles.
>
>
>
> The releng engineer maintains a project which inject tycho configuration
during the build process on CI. By doing so we separate eclipse bundle
development from maven considerations.
>
Mickael Istria
2012-05-15 12:25:27 UTC
Permalink
I like this debate ;)

On 05/15/2012 02:10 PM, X Shel wrote:
> In a development phase, an eclipse plugin developper should only rely
> on PDE tools to run its tests or to validate its mofidications.
If you are in a "continuous" approach, there is no line between
development phase and build phase. Both perform simultaneously.
Why do you say an Eclipse plugin developer should *only* rely on PDE
tools, and as a consequence should not run a "mvn install" ? "mvn
install" guarantees much more stuff that Right-Click > Run As... > JUnit
plugin tests. It guarantees more comformance to OSGi (it's pretty easy
to forget a critical entry in build.properties and get a test working in
PDE; this error is not tolerated by Tycho), and it guarantees the build
won't break because of one of his change. PDE does not guarantee that.
It's a matter of habits, but developers should really run "mvn install"
when they have a pom, it does not cost a lot of time now but will save a
lot of time later trying to debug it in CI build.

> As i understand it, Eclipse PDE internally use ant generated scripts
> to build plugins. Those scripts are generated using configuration
> files such as build.properties and others.

I think PDE/Build uses Ant scripts, but PDE tooling in IDE relies on
internal builders of JDT to generate a classpath from MANIFEST.MF and
build continuously. build.properties is ignored in IDE, it can lead to
errors that are not detected in Eclipse.

> I can see a use case that i've recently encourter, migrating a
> buckminster-based build process into a tycho-based one, with sources
> only accessible in a readonly mode.
Then the solution would probably be to avoid readonly mode ;) Most IT
problems can be solved by removing constraints.

--
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>
Davy Meers
2012-05-15 13:05:20 UTC
Permalink
Hello,
Can you explain to me why you have a bundle that ends in ".tests" which is not a test bundle?It looks suspicious to me.
Besides that i would not expect the build to fail if "failIfNoTests" is set to "false" and a bundle with 'eclipse-test-plugin' packaging contains no tests.
Kind regards
> Date: Tue, 15 May 2012 10:45:35 +0200
> From: ***@mia-software.com
> To: tycho-***@eclipse.org
> Subject: [tycho-user] Tycho-Surefire guessing the Test Framework
>
> Hello,
>
> One of my bundles, which is not a test bundle, has '.tests' as suffix.
> So tycho-pomgenerator assign to that bundle, the 'eclipse-test-plugin' packaging.
> When i try to run tests i got the following error:
>
> [Could not determine test framework used by test bundle MavenProject: XXX.XXX.XXX.util.tests:0.2.0-SNAPSHOT]
>
> I try to set the option failIfNoTests to false, but i still got the same error.
>
> By overlooking the code of TestMojo from tycho 0.14.x sources, i discovered that tycho try to guess the test framework to use by searching JUnit declaration into the bundle classpath and failed if it doesn't find one.
>
> I think that tycho should not failed when it could not guess the test framework if the option failIfNotTests is set to false.
>
> Is anyone as already encountered this issue ?
>
>
> Thanks in advance, for your answers.
> Best regards.
> _______________________________________________
> tycho-user mailing list
> tycho-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/tycho-user
Dieter Van de Walle
2012-05-15 13:22:09 UTC
Permalink
I understand this use case.
I also have such a project which does nothing else than use tycho-surefire-plugin to automatically setup a lightweight OSGI container with some components automatically deployed to be able to manually integration test a subset of the developed modules.
This project is an eclipse-test-plugin to enable tycho-surefire-plugin running, but does not contain any tests (yet) .

Dieter

On 05/15/2012 03:05 PM, Davy Meers wrote:
Hello,

Can you explain to me why you have a bundle that ends in ".tests" which is not a test bundle?
It looks suspicious to me.

Besides that i would not expect the build to fail if "failIfNoTests" is set to "false" and a bundle with 'eclipse-test-plugin' packaging contains no tests.

Kind regards

> Date: Tue, 15 May 2012 10:45:35 +0200
> From: ***@mia-software.com<mailto:***@mia-software.com>
> To: tycho-***@eclipse.org<mailto:tycho-***@eclipse.org>
> Subject: [tycho-user] Tycho-Surefire guessing the Test Framework
>
> Hello,
>
> One of my bundles, which is not a test bundle, has '.tests' as suffix.
> So tycho-pomgenerator assign to that bundle, the 'eclipse-test-plugin' packaging.
> When i try to run tests i got the following error:
>
> [Could not determine test framework used by test bundle MavenProject: XXX.XXX.XXX.util.tests:0.2.0-SNAPSHOT]
>
> I try to set the option failIfNoTests to false, but i still got the same error.
>
> By overlooking the code of TestMojo from tycho 0.14.x sources, i discovered that tycho try to guess the test framework to use by searching JUnit declaration into the bundle classpath and failed if it doesn't find one.
>
> I think that tycho should not failed when it could not guess the test framework if the option failIfNotTests is set to false.
>
> Is anyone as already encountered this issue ?
>
>
> Thanks in advance, for your answers.
> Best regards.
> _______________________________________________
> tycho-user mailing list
> tycho-***@eclipse.org<mailto:tycho-***@eclipse.org>
> https://dev.eclipse.org/mailman/listinfo/tycho-user
Hervé Esteguet
2012-05-15 13:19:11 UTC
Permalink
Thanks davy for coming back to the original subject.

The bundle that ends with '.tests' contains tests utilities and has maybe been wrongly named.
As i was saying in my first post, it seems that tycho-surefire is looking for Junit dependencies and complains if it doesn't find them, regardless of the value of the failIfNoTests option.

A quick workaround if we don't want to rename the bundle, is to add a dependency to JUnit or a dummy tests.

Best regards

> Hello,
>
>
> Can you explain to me why you have a bundle that ends in ".tests" which is not a test bundle?
> It looks suspicious to me.
>
>
> Besides that i would not expect the build to fail if " failIfNoTests" is set to "false" and a bundle with 'eclipse-test-plugin' > > packaging contains no tests.
>
>
> Kind regards
>
>
>
>> Date: Tue, 15 May 2012 10:45:35 +0200
>> From: ***@mia-software.com
>> To: tycho-***@eclipse.org
>> Subject: [tycho-user] Tycho-Surefire guessing the Test Framework
>>
>> Hello,
>>
>> One of my bundles, which is not a test bundle, has '.tests' as suffix.
>> So tycho-pomgenerator assign to that bundle, the 'eclipse-test-plugin' packaging.
>> When i try to run tests i got the following error:
>>
>> [Could not determine test framework used by test bundle MavenProject: XXX.XXX.XXX.util.tests:0.2.0-SNAPSHOT]
>>
>> I try to set the option failIfNoTests to false, but i still got the same error.
>>
>> By overlooking the code of TestMojo from tycho 0.14.x sources, i discovered that tycho try to guess the test framework to use by >searching JUnit declaration into the bundle classpath and failed if it doesn't find one.
>>
>> I think that tycho should not failed when it could not guess the test framework if the option failIfNotTests is set to false.
>>
>> Is anyone as already encountered this issue ?
>>
>>
>> Thanks in advance, for your answers.
>> Best regards.
>> _______________________________________________
>> tycho-user mailing list
>> tycho-***@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/tycho-user
Continue reading on narkive:
Loading...