Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] status of AllTests.java

Christian

 

I agree with you: we keep your AllTests.java

I agree with you: it would be great if m2e could run in JUNit view. Personally, sometime I read Surefire xml reports where you have more trace than in JUnit view.

 

So to clarify, I do not want to replace your methodology, I would like to add an additional methodology than many people use to. For instance, it is an advantage to be able to run test in a separate windws/terminal, continuing to work on the code.

 

In my previous email, the question was not anymore on AllTests.java:

Keeping the actual structure, may we add the maven nature and intermediate poms to Papyrus?”

 

But if I read your answer you said

what I like about m2e's (with help from Tycho) build integration is that it uses the pom metadata to direct normal PDE / JDT builds, without an external maven process or repository”

 

Does it mean you agree with my proposition to add maven nature and pom where it is necessary?

 

Francois

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
Envoyé : vendredi 3 juillet 2015 13:54
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] status of AllTests.java

 

My understanding of the maven launch configurations is that they launch an external maven process using a maven repository.  I don't want developers to have to maintain a maven repository in addition to their Eclipse environment.

 

Also, what I like about m2e's (with help from Tycho) build integration is that it uses the pom metadata to direct normal PDE / JDT builds, without an external maven process or repository.  Can it do the same for JUnit execution?  I need the test results presented in JUnit view, where I can selectively re-run subsets and easily visualize and trace failures.  If that can be done with m2e based on the pom, that would be great.  But otherwise, I need the AllTests suites.

 

Cheers,

 

Christian 

 

 

On Fri, Jul 3, 2015 at 3:45 AM, LE FEVRE FRANCOIS <francois.le-fevre@xxxxxx> wrote:

Hi,

 

Here some answers

 

And giving up a one-click execution of a test bundle suite for executing a long command-line in the terminal is a non-starter.”

“If the POM-based approach can be as easy to launch in Eclipse as the tests currently are and if it can aggregate multiple (and/or all) of the tests in a single run-time instance, then that would be a step in the right direction.  Otherwise, I don’t see the value in losing these test suite classes.  We need to keep in mind that the primary developer use cases are in the Eclipse IDE, not the command-line.”

 

You could also, make right click on the pom, run with maven and execute the test or whatever you need

See here for more details: http://www.vogella.com/tutorials/EclipseMaven/article.html#example_eclipsemavenproject4

So from my side, it is easy, isn’t it?

 

“We can also look at ways to make it easier for the AllTests suite to discover test classes to run, if integrating new tests is a problem (is it?).  For example, the CDO project has a test suite runner that finds test classes automatically within the test bundle by using the OSGi bundle APIs to scan for *.class files in the bundle and then reflecting on them to see whether they look like tests.”

Maven Tycho surefire do it automatically based on the convention.

 

 

To formalize the new question,

Keeping the actual structure, may we add the maven nature and intermediate poms to Papyrus?

 

“Add” = add simply something, without removing something else.

May I begin to do it, without touching at first to the directory structure= just adding pom and or maven/project

 

Cheers

 

Francois

 

 

 

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
Envoyé : jeudi 2 juillet 2015 18:33
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] status of AllTests.java

 

Hi,

 

Running tests in parallel within one run-time instance is almost certainly not going to work, given how many of the Papyrus frameworks are not thread-safe and how much is required to execute on the main thread anyways.  Besides that test suites routinely install behaviours in shared registries and uninstall them afterwards that would interfere with other tests.

 

And giving up a one-click execution of a test bundle suite for executing a long command-line in the terminal is a non-starter.

 

Why are the AllTests suite classes a problem?  Because there are 96 of them?  There’s more than 96 of everything else:  bundles, MANIFEST.MF, plugin.xml, etc.  And these aren’t in the Papyrus product anyways.

 

If the POM-based approach can be as easy to launch in Eclipse as the tests currently are and if it can aggregate multiple (and/or all) of the tests in a single run-time instance, then that would be a step in the right direction.  Otherwise, I don’t see the value in losing these test suite classes.  We need to keep in mind that the primary developer use cases are in the Eclipse IDE, not the command-line.

 

We can also look at ways to make it easier for the AllTests suite to discover test classes to run, if integrating new tests is a problem (is it?).  For example, the CDO project has a test suite runner that finds test classes automatically within the test bundle by using the OSGi bundle APIs to scan for *.class files in the bundle and then reflecting on them to see whether they look like tests.

 

Cheers,

 

Christian

 

 

On Thu, Jul 2, 2015 at 12:09 PM, LE FEVRE FRANCOIS <francois.le-fevre@xxxxxx> wrote:

hey,

 

I do understand your concern but I was not aware of your concern to run all the tests in a single workbench instance.

 

I am not sure we could keep a manual procedure when we have a such big and complex project as papyrus.

In order to run the tests of a plugin, you could execute them with maven.

-directly from Eclipse but you need to maven nature

-from command line by executing for instance:

 

mvn clean install -f tests/junit/plugins/uml/profile/org.eclipse.papyrus.uml.profile.drafter.tests/pom.xml -Dpapyrus.repo.main=file:///export/home/flefevre/git/org.eclipse.papyrus/releng/main/site/target/repository/ -Dpapyrus.repo.dev=file:///export/home/flefevre/git/org.eclipse.papyrus/releng/dev/site/target/repository/ -DskipInnerTests=false

 

This way to do is similar/identic to the one executing in eclipse HIPP instance.

 

About the workbench instance, I have looked to https://eclipse.org/tycho/sitedocs/tycho-surefire/tycho-surefire-plugin/test-mojo.html

They are a lot of customization possible.

When look at https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html , they explain that we could use parallel mode

When using reuseForks=true and a forkCount value larger than one, test classes are handed over to the forked process one-by-one. Thus, parallel=classes would not change anything. However, you can useparallel=methods: classes are executed in forkCount concurrent processes, each of the processes can then use threadCount threads to execute the methods of one class in parallel.”

The option all seems good to me?

 

Perhaps there is a way to execute all tests in a same workbench.

 

I have tested at the level of one plugin: it executes only one workbench

If we want to aggregate tests, as usual I would propose to make intermediate pom…

See this bug: https://git.eclipse.org/r/#/c/50501/ ; https://git.eclipse.org/r/#/c/50503/

I didn’t get any answer…

 

Do you think we should look more precisely to Tycho-surefire plugin?

 

waiting additional information.

 

Francois

 

Here configuration for nattable test = 4 plugins grouped with one pom

 

<plugins>

                                                <plugin>

                                                                <groupId>org.eclipse.tycho</groupId>

                                                                <artifactId>tycho-surefire-plugin</artifactId>

                                                                <version>${tycho-version}</version>

                                                                <configuration>

                                                                                <failIfNoTests>false</failIfNoTests>

                                                                                <useUIHarness>true</useUIHarness>

                                                                                <useUIThread>true</useUIThread>

                                                                                <testFailureIgnore>true</testFailureIgnore>

                                                                                <argLine>-Xms512m -Xmx2048m -XX:MaxPermSize=512M -XX:SoftRefLRUPolicyMSPerMB=100</argLine>

                                                                                <appArgLine>-testConfig=${testConfig}</appArgLine>

                                                                                <product>org.eclipse.sdk.ide</product>

                                                                                <skipTests>${skipInnerTests}</skipTests>

 

                                                                                <!-- run tests on a pool of 3 concurrent process -->

                                                                                <forkCount>2</forkCount> <!--or 0 -->

                                                                                <!-- use a pool of JVMs -->

                                                                                <reuseForks>true</reuseForks>

 

                                                                </configuration>

                                                </plugin>

 

                                </plugins>

 

 

[INFO] Reactor Summary:

[INFO]

[INFO] org.eclipse.papyrus.uml.nattable.tests.main ........ SUCCESS [  0.137 s]

[INFO] org.eclipse.papyrus.uml.nattable.clazz.config.tests  SUCCESS [  2.663 s]

[INFO] org.eclipse.papyrus.uml.nattable.generic.tests ..... SUCCESS [ 21.395 s]

[INFO] org.eclipse.papyrus.uml.nattable.stereotype.display.tests SUCCESS [ 24.697 s]

[INFO] org.eclipse.papyrus.uml.nattable.tests ............. SUCCESS [ 17.025 s]

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 02:18 min

[INFO] Finished at: 2015-07-02T18:07:53+02:00

[INFO] Final Memory: 76M/859M

[INFO] ------------------------------------------------------------------------

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
Envoyé : jeudi 2 juillet 2015 16:40
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] status of AllTests.java

 

Hi,

 

We have the suite-of-suites in the org.eclipse.papyrus.tests bundle in order to run all the tests in a single workbench instance.

 

Will this change result in a workbench being launched for each test plug-in when run by Maven?  That will add a lot of overhead (OS resources and time) to the test execution.

 

And what does this mean for all of the launch configurations in every test project?

 

And how will we launch tests in the Eclipse IDE?  The JUnit launch config doesn’t look at the POM.

 

Christian

 

 

On Thu, Jul 2, 2015 at 10:36 AM, LE FEVRE FRANCOIS <francois.le-fevre@xxxxxx> wrote:

Gabriel,

 

Ok, I will submit a gerrit.

I have created a bug here https://bugs.eclipse.org/bugs/show_bug.cgi?id=471707

I have putted the discussion we had in it.

 

I will make it as soon as my eclipse give me back the control…

 

Francois

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Gabriel Pascual
Envoyé : jeudi 2 juillet 2015 14:15
À : mdt-papyrus.dev@xxxxxxxxxxx
Objet : Re: [mdt-papyrus.dev] status of AllTests.java

 

IMHO, without Alltests files, it will be simpler to make testing contributions and this will avoid to create unnecessary dependencies too.

Did you begin to work on ? If yes, did you create a Gerrit review or branch ?

Regards

Gabriel

Le 02/07/2015 12:58, LE FEVRE FRANCOIS a écrit :

Gabriel,

 

Tycho surefire plugin will execute all tests (that match the pattern *Test.java etc..) foreach plugin.

So inside one plugin it will execute all tests.

So from a parent module, it will call all modules children and so call all tests inside the children module.

 

Moreover Benoit M. highligts me that it will introduce some binding in plugin dependencies.

If we take as example the extra plugins, the Alltests.java master plugin call all AllTests.java in each extraplugins

But those plugins should be totally independent.

But with the Alltests.java files it aggregates the dependencies…

 

Francois

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Gabriel Pascual
Envoyé : jeudi 2 juillet 2015 12:33
À : mdt-papyrus.dev@xxxxxxxxxxx
Objet : Re: [mdt-papyrus.dev] status of AllTests.java

 

Hi François,

It seems me that AllTests files are used to aggregate all tests. With this configuration, we have one execution for all tests. My questions are :

  • Can Tycho-Surefire aggregate all tests to keep this test configuration ?
  •  If not, the policy of test will have to change with one test plug-in for one execution.  Will we have the same result  ?

Regards

Gabriel


Le 02/07/2015 11:24, LE FEVRE FRANCOIS a écrit :

Dear all,

 

You already know that I like a lot when we have the less source code to manage, and that we rely on convention rather on configuration.

 

I have noticed the existence of several AllTests.java that list for a given eclipse-test-plugin the class to test.

Such as this one:

/org.eclipse.papyrus.uml.profile.drafter.tests/test/org/eclipse/papyrus/uml/profile/drafter/tests/AllTests.java

 

We have 96 AllTests.java files in org.eclipse.papyrus

 

I would like to know if we could delete those files because it seems not to be relevant to list in a file the test suite.

Actually we use the Tycho surefire plugin that is able by default to list the test to run given the convention pattern.

https://eclipse.org/tycho/sitedocs/tycho-surefire/tycho-surefire-plugin/test-mojo.html

 

What is your remarks on the deletion or not of those files?

 

Francois

 

 

<image001.png>

<image002.jpg>

Francois LE FEVRE

Research Engineer

Commission for Atomic Energy and Alternative Energies (CEA)

Model-driven Engineering for Embedded Systems Laboratory (LISE)

Projet: Papyrus: https://www.eclipse.org/papyrus/

<image003.jpg>

Commissariat à l’énergie atomique et aux énergies alternatives (CEA)

Paris-Saclay Campus - Nano-INNOV | Bât. 862-PC1087 | F-91191 Gif-sur-Yvette Cedex

T. +33 (0)1 69 08 49 86  |  F. +33 (0)1 69 08 83 95  |

francois.le-fevre@xxxxxx   |  Blog: http://biocamp.blogspot.fr/

 

 

 

_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

 

--

<image004.jpg>

 

 

 

Gabriel PASCUAL
Software Engineer


6 rue Léonard De Vinci - BP 0119 - 53001 LAVAL Cedex - FRANCE
www.all4tec.net

 

 

_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

 

--

<image005.jpg>

 

 

 

Gabriel PASCUAL
Software Engineer


6 rue Léonard De Vinci - BP 0119 - 53001 LAVAL Cedex - FRANCE
www.all4tec.net

 

<smime.p7s>

 

<smime.p7s>

 

<smime.p7s>

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Back to the top