Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] Plugins not in the build

Hi,

 

That’s why I suggested dev or test J. And will be pleased if we just remove the non-compiling plugins.

 

About memory, as you already now, I would prefer to split the build in semantic module rather than the actual technical split.

 

Doing so, we will be able to have fine gerrit event that will launch compile, test and quality BUT only for the specific modified part.

We will have to be more careful not to broke api, since it won’t be catch by gerrit anymore.

(We currently only catch the api used by extra, dev and tests in their compile phase)

ð  This will also reflect the process that any extra outside the eclipse-papyrus infrastructure is facing.

 

Regards,

Benoit

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de LETAVERNIER Camille
Envoyé : mardi 24 mars 2015 16:53
À : Papyrus Project list
Objet : [PROVENANCE INTERNET] Re: [mdt-papyrus.dev] Plugins not in the build

 

Hi,

 

Just a comment : we’ve had to increase the memory for the master/Main build already (And Findbugs can’t run anymore). So, if you want some plug-ins to be built, but they shouldn’t be part of the distribution, please don’t use the Main build J

 

Thanks,

Camille

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de MAGGI Benoit
Envoyé : mardi 24 mars 2015 16:48
À : Papyrus Project list
Objet : [PROVENANCE INTERNET] Re: [mdt-papyrus.dev] Plugins not in the build

 

Hi Cedric,

 

Thanks for your explanations. Is it written anywhere in the wiki ? (I didn’t found it)

Currently only the plugins  in test\junit are build and executed.

 

Anyway, all plugins should be in the build (at minimum to ensure that it’s still compiling)

About org.eclipse.papyrus.uml.diagram.emftree and org.eclipse.papyrus.integrationtests.editor

ð  Where can I add it ? dev ? test ? 

 

About the other plugins depending *.emf.facet

ð  Has anyone an idea ? is using them ?

 

Regards,

Benoit

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Cedric Dumoulin
Envoyé : vendredi 20 mars 2015 16:10
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Plugins not in the build

 


  Hi,

MAGGI Benoit a écrit :

Hi Team,

 

[...]
 

One is also referring a “core plugin” not in the build

org.eclipse.papyrus.integrationtests.editor

ð  Depends on org.eclipse.papyrus.uml.diagram.emftree

( org.eclipse.papyrus.uml.diagram.emftree is also missing a pom.xml)

 

Here are my questions:

-        Do we need to keep these plugins ?

Yes !
  - integrationtests.editor contains  ... integration tests for the editor, and some base classes used by some others tests plugins.
  - emftree  is used as an example showing how to integrate EMF generated Tree into Papyrus. Also, it is used by some of us for debugging (it allows to inspect opened Papyrus models).

-        What is the difference between debug integration and junit directories?

  - JUnit tests - are 'unit tests' - which for me means they should only tests the related class and its methods. Such tests should only relies on the 'run' dependencies of the plugin containing the class under test. 
  - integration tests - Such tests are used to test if several plugins work well together. They can use any plugins from Papyrus. As example, checking if the Papyrus editor start without exception or if the existing diagrams are all found are integration tests. If a test tests something else than the method behavior, it is certainly an integration test (and not a unit test).

  For me both types of tests should be separated, because they do not involve the same set of plugin dependencies:
  - Unit tests require nearly the same dependencies than the plugin requires to 'run' (running dependencies). Normally, they can be located in the same plugin as the tested classes.
  - Integration tests often require more plugin dependencies. Such tests are better located in their own plugin, importing required plugins.

-        What do we do with org.eclipse.papyrus.uml.diagram.emftree ? Has it ever been released in a papyrus version ?

  It has never been released in a version. It is mainly for developers.
 
We should keep it.

  Cedric

 

Regards,

Benoit

 

1 :

cid:image001.png@01D0632A.3D281E40

 

2:

org.eclipse.papyrus.core.queries.configuration.editor

ð  Depends on org.eclipse.emf.facet.*

org.eclipse.papyrus.extendedtypes.emf.edit

ð  Depends on org.eclipse.emf.facet.*

org.eclipse.papyrus.extendedtypes.uml.edit

ð   Depends on org.eclipse.emf.facet.*

org.eclipse.papyrus.extendedtypes.uml.editor

ð  Depends on org.eclipse.emf.facet.*

org.eclipse.papyrus.infra.extendedtypes.edit

ð  Depends on org.eclipse.emf.facet.*

org.eclipse.papyrus.infra.extendedtypes.editor

ð  Depends on org.eclipse.emf.facet.*

org.eclipse.papyrus.paletteconfiguration.editor

ð  Depends on org.eclipse.emf.facet.*

org.eclipse.papyrus.uml.modelexplorer.recipetest

ð  Depends on org.eclipse.emf.facet.*

 

 




_______________________________________________
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

 


Back to the top