Community
Participate
Working Groups
In order to get faster feedback on Gerrit builds, we need to build smaller components. However, the current structure does not properly support this, due to several issues: - Not all plug-ins properly implement the Papyrus architecture (e.g. some infra plug-ins depend on UML or GMF) - The build is split into 4 units (Main, Main Tests, Extra, Extra Tests). We should get more smaller units (e.g. Infra/Core, Views, Diagrams, Tables, UML Diagrams, UML Tables) - The tests should be closer to the tested components, to be able to run tests when building tested components. Currently we can only run "Main Tests" or "Extra Tests" - The lack of clear API doesn't provide enough confidence when changing core components, so we need to rebuild/retest everything to ensure that we don't break anyone Some components that could be improved (This list is not exhaustive): - Extract the ServicesRegistry outside infra.core (Or: separate Services from Sash Editor). This "core" plug-in includes both UI Components (Sash Editor) and core service management (Services/ServiceRegistry). Most plug-in depend on it for Services, but end up with a strong UI dependency - ModelExplorer (UI Trees in general): Semantic Model & Content provider. Currently, the only abstraction we have for a "Semantic Model" is the IModel interface/UmlModel implementation. When we want to retrieve the "Semantic Model" of Papyrus (And content provider), we need to depend on uml.tools. - Palette: The palette framework has a dependency to UML to support profiles. This means that either a) All our palettes are based on UML, or b) Our generic palette framework has a dependency to UML (For example, infra.gmfdiag.css.palette depends on UML although it simply contributes a Post-Action for the generic palette framework) - Remove the strong dependency on the *.uml file extension, which makes it impossible to support normative XMI in Papyrus (OMG XMI URIs, properly supported by Eclipse/UML). This extension is used in many places in Papyrus This task is not related to the build issue but still makes sense for a more modular architecture (It is also probably more complex): - Diagram Runtime: GMF is split between "GMF Runtime" and "GMF Diagram UI" (The first one doesn't depend on GEF). We don't do this distinction in Papyrus, which means that all our generic diagram components depend on GEF3.x (Making it complicated to support both GEF3 and GEF4 without duplicating code or introducing a dependency from GEF4 Editors to GMF Editors). We should have a clearer separation of the Runtime and UI components for the diagrams
Regarding the tests, we should probably have a better separation between Unit tests (That can be executed along with the tested component) and integration tests (That still require a complete Papyrus configuration, and should be executed in a single pass to avoid restarting Eclipse N times during the build) While Maven typically runs tests for each plug-in, this doesn't work well in the context of Eclipse because building the Eclipse installation and starting the workbench may take a lot of time (This is done in e.g. SysML 1.4 and Papyrus-RT, but they are much smaller projects). So we should keep the option to run "All Tests" for each build. Maybe use a more hierarchical test configuration? - Main -- Infra --- Infra.core --- Infra.Services -- GMF --- Infra.GMF --- ... ... We probably need a similar structure for the Maven build (And it may change over time - it already changed a few times in Mars), so maybe we should get a flexible model for the papyrus layers (With the ability to easily move a component from a layer to another, or introduce new intermediate layers, and generate the AllTests/Maven POM structure). Maybe ADL4Eclipse could be used here
(In reply to Camille Letavernier from comment #1) > > - Main > -- Infra > --- Infra.core > --- Infra.Services > -- GMF > --- Infra.GMF > --- ... > ... To some degree, the test-suite infrastructure is already prepared for this. See, for example, how the Diagram Assistants component has an all-tests suite of its own that is aggregated into the Papyrus All Tests.
The architectural problems go all the way to the bottom of the plug-in layer stack: the oep.infra.tools bundle, on which oep.infra.core depends, also has many UI dependencies and re-exports UI concepts in its own APIs.
If we want to commit to this omelette for Neon, then we are going to have to break a lot of eggs. Many very core and widely used classes will have to move to new packages to get the benefit of clean layering and separation of dependencies. That is, if we want to avoid splitting packages [1], which I think should be avoided. Basically, many of the core APIs will be renamed and therefore will break Papyrus clients and extenders. That implies Papyrus version 2.0 for Neon. Are we okay with that? [1] http://wiki.osgi.org/wiki/Split_Packages
New Gerrit change created: https://git.eclipse.org/r/63594
> Basically, many of the core APIs will be renamed and therefore will break Papyrus clients and extenders. That implies Papyrus version 2.0 for Neon. Are we okay with that? Yes, I think so (Actually I've never doubted that would be required :) ) > That is, if we want to avoid splitting packages [1], which I think should be avoided. Agreed; it's important to keep consistency in bundles. We have so many bundles that splitting packages would only introduce more confusion; we don't really need that :)
Gerrit change https://git.eclipse.org/r/63594 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=1dbd408ab7427b161e0ee1e02ab9413a646bd178
New Gerrit change created: https://git.eclipse.org/r/63660
Gerrit change https://git.eclipse.org/r/63660 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=9036d29e37a0a3b45ea76962677faf7099b96406
New Gerrit change created: https://git.eclipse.org/r/63689
Gerrit change https://git.eclipse.org/r/63689 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=f5520356ced096a82fa0075f70d954e473670c8b
Added URL reference to the Wiki page documenting the analysis of the Papyrus bundle dependencies, initially in the Infra Layer.
Review 63777 [1] demonstrates the scale of the impact of such a (conceptually) simple change as extracting the UI-dependent APIs from the infra.tools bundle into infra.ui. This includes refactoring the test bundle similarly and introducing two new OSGi services to invert crucial UI dependencies that headless code will still need: * IExecutorService extends Java Platform's ExecutorService with APIs for synchronous execution (a la Display.syncExec). A new CoreExecutors class in the infra.tools bundle supplies the instance provided by the OSGi service implementation in the infra.ui bundle. This provides compatibility for clients of various UIUtil APIs that they can no longer access * IContextualServiceRegistryTracker abstracts the concept of the default ServicesRegistry found in the currently active editor, which the ServiceUtilsForHandlers class (and hence all of its clients) relies on. Again an OSGi service implementation in the infra.ui bundle supplies the implementation of this tracker, which is exposed in infra.core through the service-utils API Note that this gerrit change covers all of the Main plug-ins (afaik) but not the Extras. The main all-tests suite shows no obvious regressions, and the diagram editors still seem to work as normal in a run-time workbench. Attempting to pursue these kinds of migrations across the board (this is extracting the UI out of a single plug-in!) for illegal UI, GEF/GMF, and UML dependencies will be a large undertaking and probably difficult to do in parallel with *any* other development activities! [1] https://git.eclipse.org/r/63777
Another thing I didn't mention in the bug description (And I didn't see it in the wiki page either): We have some dependencies from the Table layer to the GMF one, because infra.gmfdiag.common provides the NotationModel (IModel). Since the Notation resource is shared by various components (CSS, GMF Notation, Table Model, and potentially others), it should be moved to a non-GMF layer. I'm not sure how much the GMF NotationResource implementation is required for this shared resource (i.e. if we can really get rid of the GMF dependency), but I think it shouldn't be an issue (We may have to configure the resource save/load options ourselves, but we already do that for most resources anyway)
(In reply to Camille Letavernier from comment #14) > Another thing I didn't mention in the bug description (And I didn't see it > in the wiki page either): Yes, indeed. I just hadn't looked at the Nattable bundles, yet. Note that, as I mentioned on the wiki page, I don't consider infra.nattable as an "infra layer" component. It really should just be called "nattable". Maybe there's an "infra" of the "nattable", but the "nattable" is not an "infra" of Papyrus. :-)
(In reply to Christian W. Damus from comment #15) > (In reply to Camille Letavernier from comment #14) > > Another thing I didn't mention in the bug description (And I didn't see it > > in the wiki page either): > > Yes, indeed. I just hadn't looked at the Nattable bundles, yet. Note that, > as I mentioned on the wiki page, I don't consider infra.nattable as an > "infra layer" component. It really should just be called "nattable". Maybe > there's an "infra" of the "nattable", but the "nattable" is not an "infra" > of Papyrus. :-) Just for your information, Christian, I pushed a new version of the ADL4Eclipse tool today on gerrit, that helps looking at the architecture of plugins and feature in Papyrus. That tool lets you reverse the architecture of the current platform or plugin/features in the workspace, creating a UML view of this architecture. You can then run some analyzes on the result model. About these analyzes, I pushed on gerrit an additional action on the root of the reversed model, to the refactoring popp menu area on model explorer. This refactoring creates dependencies between the features, by looking at the plugins contained in the feature and their own plugin dependencies. I can do a quick demo of this tool if you think that could be of interest for your work. This helps finding architectural issues between plugins (e.g. uml.gmfdiag.export that depends on gmfdiag.css, where it should not). The dependencies between features are ordered the following way: Papyrus intra-dependencies, External features to Papyrus (should be empty for now), Papryus to external features (our technology dependencies), and the dependencies between our external features (not the most interesting thing for now) link to the gerrit: https://git.eclipse.org/r/#/c/63841/
(In reply to Remi Schnekenburger from comment #16) > > Just for your information, Christian, I pushed a new version of the > ADL4Eclipse tool today on gerrit, that helps looking at the architecture of > plugins and feature in Papyrus. That tool lets you reverse the architecture > of the current platform or plugin/features in the workspace, creating a UML > view of this architecture. You can then run some analyzes on the result > model. Thanks, yes, this should help a good deal. The bulk of the work is, of course, in poring over the problems and deciding what to do about them. But this should make it easier to keep track of the issues, for sure.
In any case, the scope of the effort is such that it really has to be staged. So, I am proceeding from the bottom (infra.core.*) up. It would be good to actually implement refactorings in a staged manner, too. The core level refactorings will be most disruptive to the team's parallel development in git, so it would be nice to get those out of the way first, which is why I have a draft gerrit in progress as discussed in comment 13.
As I have noted in the Wiki page, I am running into various refactoring problems caused by sloppiness in API controls on our bundle activators. Every bundle activator has the same name and is exported as public API. That really needs to change: these must be internal and their use restricted to the bundle that they belong to only.
A new update of the gerrit change 63777 expands the joy by moving UI APIs from the org.eclipse.papyrus.infra.core bundle into org.eclipse.papyrus.infra.ui. This includes * moving the 'papyrusDiagram' and 'papyrusContentOutline' extension points into the org.eclipse.papyrus.infra.ui namespace * moving various UI-related services such as EditorLifeycleManager, SaveLayoutBeforeClose, and the IMultiDiagramEditor, itself, into the org.eclipse.papyrus.infra.ui bundle This necessitates not only widespread refactorings on the moved APIs, but also concomitant move of other APIs in other bundles because they cannot plausibly use these moved APIs from their new home in org.eclipse.papyrus.infra.ui and/or they cannot reasonably also be moved to the UI bundle and/or they must be used by bundles that now have no UI dependency: * the DI/sash-windows EMF model is moved out of the infra.core.sasheditor.di bundle into a new model-only org.eclipse.papyrus.infra.sashwindows.di bundle (which symbolic name incidentally now better reflects the contained Java package names) * the edit advices dealing with the IPageManager (e.g., for closing pages when diagrams are deleted) are moved from the org.eclipse.papyrus.infra.emf bundle into org.eclipse.papyrus.infra.ui * the MultiDiagramEditorGefDelegate (which has a GEF 3 dependency) is moved from the org.eclipse.papyrus.infra.core.sasheditor bundle to a new org.eclipse.papyrus.infra.gmfdiag.gef bundle. Its usage for an adapter of ActionRegistry type is extracted out of the CoreMultiDiagramEditor class into a new external adapter-factory in the infra.gmfdiag.gef bundle Tests all still pass (inasmuch as they do in the nightly master builds) and ad hoc tests find no regressions in creation of new models and diagrams and simple editing scenarios in the explorer, diagrams, and properties. I would expect this to be one of the biggest stages of the refactoring, as so many components use so many of these UI APIs from the infra.core bundle. I do not look forward to rebasing this change.
New Gerrit change created: https://git.eclipse.org/r/63777
> As I have noted in the Wiki page, I am running into various refactoring problems caused by sloppiness in API controls on our bundle activators. Every bundle activator has the same name and is exported as public API. That really needs to change: these must be internal and their use restricted to the bundle that they belong to only. Since we don't use the Activators (In 99% of the bundles), we could even remove them entirely. They are only used to give a simple access to the Logger (And PLUGIN_ID constant)
(In reply to Camille Letavernier from comment #22) > > Since we don't use the Activators (In 99% of the bundles), we could even > remove them entirely. They are only used to give a simple access to the > Logger (And PLUGIN_ID constant) Agreed. The Activators should be replaced by a LogUtil class that passes calls through to a LogHelper using the appropriate plug-in ID (we don't want all logs to use a foreign ID, right?) and that LogUtil should be private to the plug-in. It's really the insertion of the Activator into the unneeded bundle lifecycle hooks that is the potential performance problem, I think? Usually the LogUtil class would only be loaded when the first exception happens.
New Gerrit change created: https://git.eclipse.org/r/64168
Hello, Once it has been done / or during the move phase, it could be good to ask for the creation of dedicated git repository for for instance papyrus core plugins. I would also to know if we could also create a dedicated repo for papyrus-emf-facet that do not really change overtime in papyrus. By doing so, we could reduce also the time of the build: we will never build again papyrus emf facte if we do not touch them. We could add a job on hudson to triggerpapyrus core in case of change in papyrus-emffacte.
The size of the repository does not affect the build time. Split repositories only affect developers (Development times) by making their life harder
(In reply to Francois Le Fevre from comment #25) > Hello, > Once it has been done / or during the move phase, it could be good to ask > for the creation of dedicated git repository for for instance papyrus core > plugins. No. The Papyrus Main plug-ins should all be in one repository. Building each component individually and test each component individually are goals. Managing them separately in git repositories is not a goal. Note that the refactorings that I am actually implementing cover only the Main and Extras components that are in the papyrus.git repository. Any components that are taken out into their own repository will not be included in refactorings, so they will break until they are migrated following the Migration Guide that will be published with each refactoring.
Hey, I belongs to people that have pushed to continue to refactor the architecture of Papyrus. I do not agree with the remark that splitting project into separate projects with their own git repository make harder the life of developers. This is the main strategy of software developement: Separation Of Concern. Many projects of Eclipse have switched to this view. perhaps they make the life harder for the final builder, but not for the developer. To my point of view, we should have also a dedicated git reposiotry that holds only the main parent pom, with perhaps some shared scripts for papyrus components. Thanks for providing the migration guide, it will be very usefull for the migration but also to share the guidelines: for instance, I have baddly copy/paste the Activator pattern to have the loger. It seems it was a bad idea. I will switch to our proposition as soon as possible. Thanks a lot for this huge effort and the time you all take to explain the situation and the decision.
New Gerrit change created: https://git.eclipse.org/r/64516
(In reply to Eclipse Genie from comment #29) > New Gerrit change created: https://git.eclipse.org/r/64516 This third Gerrit change now completes the essential UI refactorings for the Infra Layer bundles. The preceding two changes are rebased again onto the latest Master. The Migration Guide for these refactorings is ready to go. It would be great to be able to review and merge these changes this week.
Christian when you say "the migration guide is ready to go", is there a place to look at it? I have an additional question relative to this new modular architecture. I am not sure, it is the place to discuss about it. What about: - adding Maven nature to all plugins? [1] We have ready spoken about it: Christian has made a good report on this interest to go on it. - adding intermediate pom to group togther functionnal units ? for instance for nattable, elementtype [2]. It will allow to have a more visible architecture. I would like we have the matching between the architecvture and the repository layout. - create the following repositories -- papyrus-doc move all doc in it? [3], it will reduce the git clone --depth 1 -- papyrus-extra move all extraplugins in it ? [4] I could do some actions with your agreement. [1]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=464852 [2]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=470576 [3]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=470547 [4]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=486034
(In reply to Francois Le Fevre from comment #31) > Christian > when you say "the migration guide is ready to go", is there a place to look > at it? I have a markdown document on my machine that is ready to be transformed to wikimedia for the Papyrus Wiki and to PDF for easy consumption. I just don't want to publish it until the refactorings are actually pushed, because otherwise it might cause confusion. Perhaps there is a way that it could be posted on the Eclipse Wiki in some kind of a draft status that is not visible to users that aren't logged in or aren't editing the wiki? > I have an additional question relative to this new modular architecture. > I am not sure, it is the place to discuss about it. > > What about: > - adding Maven nature to all plugins? [1] We have ready spoken about it: > Christian has made a good report on this interest to go on it. Yes, we should do this, but it's orthogonal to the purpose at hand which is purely an API partitioning/modularity/packaging concern. > - adding intermediate pom to group togther functionnal units ? for instance > for nattable, elementtype [2]. It will allow to have a more visible > architecture. I would like we have the matching between the architecvture > and the repository layout. > - create the following repositories > -- papyrus-doc move all doc in it? [3], it will reduce the git clone --depth > 1 > -- papyrus-extra move all extraplugins in it ? [4] > > I could do some actions with your agreement. Again, I think these are all good discussions to have but in a different scope than this bug, which is focused on the API.
OK, I doc understand this ticket is focused on API, we will discuss the other points in their owned tickets. For the migration guide why not publish it, directly in the code in order to enhance the developer documentation. If so, it cold be inside the main papyrus plugin. For SysML, we have tried to gather information in order to build a dedicated web site for developers. We have used the mecanism of maven site to do it. We add documentation under a fodler named src/site/xdoc or src/site/markdown, in order to generate the corresponding html, pdf. We have a protype here www.eclipse.org/papyrus-sysml/
(In reply to Francois Le Fevre from comment #33) > > For the migration guide why not publish it, directly in the code in order to > enhance the developer documentation. If so, it cold be inside the main > papyrus plugin. Yes, that's certainly a possibility. The wiki is probably an easier place to manage contributions/edits, and I would link to that in the Papyrus Developer Guide in the org.eclipse.papyrus.doc bundle.
François raised a good question in code review: Do we want all UI-oriented bundles in Papyrus to include a "ui" segment in the plug-in ID? I would recommend that for consistency with every other Eclipse project. The next question, if the first is agreed "yes", would be how to formulate these UI-bundle names. Would the pattern be org.eclipse.papyrus.ui.<layer>.<specific...> or org.eclipse.papyrus.<layer>.ui.<specific...> or org.eclipse.papyrus.<layer>.<specific...>.ui[.<more>] which is to say, would the headless/UI partitioning be a primary, layer-wise, or low-level architectural dimension?
For Diagrams, Tables and other views, we agreed (Back in 0.9/Juno) that the language was first (org.eclipse.papyrus.uml.*, oep.sysml.*, ...), then the technology (.diagram, .table, ...) then the specifics So that would be either org.eclipse.papyrus.<layer>.ui.<specific> or oep.<layer>.<specific>.ui (I prefer the later) That would also make sense for Diagrams if we split the Runtime part from the GEF3.x dependencies (oep.uml.diagram.clazz vs oep.uml.diagram.clazz.ui) Now, while this obviously makes sense for new or split bundles, I'm not sure if that's a good idea for existing UI bundles that don't contain the *.ui segment. Certainly for consistency, but this introduces more changes that may not be absolutely required. So... I don't know for this case (e.g. the tables will mostly be unaffected by the refactoring, so do we really want to rename them all? That includes changing URIs to Table configurations and such, meaning that the user models will need to be migrated, etc. Seems a lot of pain for a very minor gain). The same goes for the current "views" layer, which is obviously a UI layer already, and may not need to go through a complete renaming (Which might break a lot of Facets/Customs and Properties view URIs)
(In reply to Camille Letavernier from comment #36) > For Diagrams, Tables and other views, we agreed (Back in 0.9/Juno) that the > language was first (org.eclipse.papyrus.uml.*, oep.sysml.*, ...), then the > technology (.diagram, .table, ...) then the specifics Works for me. > So that would be either org.eclipse.papyrus.<layer>.ui.<specific> or > oep.<layer>.<specific>.ui (I prefer the later) > > That would also make sense for Diagrams if we split the Runtime part from > the GEF3.x dependencies (oep.uml.diagram.clazz vs oep.uml.diagram.clazz.ui) > > Now, while this obviously makes sense for new or split bundles, I'm not sure > if that's a good idea for existing UI bundles that don't contain the *.ui > segment. Certainly for consistency, but this introduces more changes that > may not be absolutely required. So... I don't know for this case (e.g. the Yes, perhaps best not to change these existing names without a good API reason. > The same goes for the current "views" layer, which is obviously a UI layer > already, and may not need to go through a complete renaming (Which might > break a lot of Facets/Customs and Properties view URIs) There was actually one case in the "views" layer that I would like to change: org.eclipse.papyrus.view.properties.model This is required by several "infra" layer plug-ins, and is really a core model for the Papyrus tooling, so it would be nice to rename it as org.eclipse.papyrus.infra.properties (without the .model, which is conventionally omitted in EMF model bundles) Responses to that?
> There was actually one case in the "views" layer that I would like to change: Yes, I noticed this one as well when looking at the views layer. +1
New Gerrit change created: https://git.eclipse.org/r/64823
New Gerrit change created: https://git.eclipse.org/r/64929
Gerrit change https://git.eclipse.org/r/64516 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=929e9738301b35cef5cc1ab00f47047671940bd5
Gerrit change https://git.eclipse.org/r/64823 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=02b052a140cd3c0499700afd5b8a1fdd31782a71
Gerrit change https://git.eclipse.org/r/64929 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=90c9b9830e0d837ce176dd8c673adf75ef262b72
Gerrit change https://git.eclipse.org/r/63777 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=b089eab1fca586752027404cc398a173237337f8
Gerrit change https://git.eclipse.org/r/64168 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=652333238a0a1651c1b69a4563b72961250c5398
The five Gerrit patches implementing the proposed refactorings in the Infra Layer for the M5 milestone are pushed to master. A first draft of the Papyrus 2.0 Migration Guide covers the details, to help Papyrus extenders to adopt these changes: https://wiki.eclipse.org/Papyrus/Migration_Guide/Neon
Created attachment 259365 [details] Successful update of properties bundles The attached image shows a successful update of the renamed Properties Model bundles. The p2.inf instructions let the p2 engine understand the renaming, so the org.eclipse.papyrus.infra.properties* bundles correctly replaced the org.eclipse.papyrus.views.properties.model* bundles in an update from the nightly build repository. And using the p2 UI to roll back the install to the previous bundles works, too. So, all in all, this refactoring doesn't impede smooth update for end users.
> The attached image shows a successful update of the renamed Properties Model bundles. The p2.inf instructions let the p2 engine understand the renaming, so the org.eclipse.papyrus.infra.properties* bundles correctly replaced the org.eclipse.papyrus.views.properties.model* bundles in an update from the nightly build repository. If you had installed the Papyrus UML feature, then p2.inf would probably not be necessary anyway. P2 properly handles the "included" elements (Features + Plugins), for additions, updates and removals What is not properly handled is the dependencies between plug-ins from different features. So for example if you installed an extra feature of Papyrus and let it pull all the dependencies it needs, it would fetch the latest version. Then if you updated this extra feature, it would consider that all its dependencies are resolved, and wouldn't update Papyrus plug-ins again. Local bundles would also add to the chaos (e.g. If you updated Papyrus to the refactored branch without updating Git), but then I'm not sure p2.inf would be used anyway So a relevant scenario would be: - Don't install Papyrus - Create a plug-in depending on Papyrus 1.1.0 (With a dependency to oep.views.properties) - Install this plug-in and let it pull all the dependencies it needs (That would include views.properties and views.properties.model plus a few others) - Change this plug-in to depend on Papyrus 1.2.0/2.0.0 (Or add an explicit dependency to oep.infra.properties, as I don't think the version numbers have been changed yet) - Update this plug-in Since Papyrus in this scenario is not installed, P2 will not try to update it (Unless new dependencies are required, in which case it will only update/install these new dependencies). This causes much more chaotic updates (And a more relevant test case :) )
> So a relevant scenario would be: I've done that and it works as well :)
(In reply to Camille Letavernier from comment #49) > > So a relevant scenario would be: > > I've done that and it works as well :) That was fast! I was just about to do the same experiment. Thanks for saving me the trouble.
New Gerrit change created: https://git.eclipse.org/r/65120
(In reply to Eclipse Genie from comment #51) > New Gerrit change created: https://git.eclipse.org/r/65120 This is a first step to enforcing headless API bundles: a test suite that includes all of the tests that can, and henceforth must be able to, run in "headless mode". A new @Headless annotation for a bundle's AllTests suite class asserts that the tests included in it run in headless mode. Suites that are thus annotated are collected automatically in the AllHeadlessTests super-suite, which makes it easy to run all headless tests (and which, without all of the UI overhead, doesn't take long at all to run). Thus, this new suite is actually a good candidate for execution in the Gerrit builds!
Gerrit change https://git.eclipse.org/r/65120 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=90f1030305fe3f47111740d37a54e3fabf20bf0d
org.eclipse.papyrus.infra.viewpoints.policy is using icons from org.eclipse.papyrus.infra.viewpoints.configuration.edit (See Bug 486708) @Christian: Are you aware of this point? Do you intend to change that during the refactoring?
(In reply to Benoit Maggi from comment #54) > org.eclipse.papyrus.infra.viewpoints.policy is using icons from > org.eclipse.papyrus.infra.viewpoints.configuration.edit > (See Bug 486708) > > @Christian: Are you aware of this point? Do you intend to change that during > the refactoring? No, I wasn't aware of this. I have been fixing a number of cases where Infra Layer bundles pull images out of UML Layer bundles, which of course totally doesn't work in an UML-less deployment. However, the situation that you have is contained within the viewpoint bundles, so it's not in the scope of this refactoring. So, no, I am not planning to do anything about it.
New Gerrit change created: https://git.eclipse.org/r/66171
Gerrit change https://git.eclipse.org/r/66171 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=ecd4928b327f5561364c5068c9ff5f1668e92d13
New Gerrit change created: https://git.eclipse.org/r/66549
Gerrit change https://git.eclipse.org/r/66549 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=f050d4119a2316b27588076d4fc90152773fc019
New Gerrit change created: https://git.eclipse.org/r/66959
Gerrit change https://git.eclipse.org/r/66959 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=09fde7a4087685b065b7f1e40375686fb9f19f2a
New Gerrit change created: https://git.eclipse.org/r/67303
Gerrit change https://git.eclipse.org/r/67303 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=4e87bc24665e771a67d29242229fddc75ddece72
New Gerrit change created: https://git.eclipse.org/r/67413
Gerrit change https://git.eclipse.org/r/67413 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=c2ccd8d85b0887636bb083b2ee0ad9f7ba57eeb6
New Gerrit change created: https://git.eclipse.org/r/67624
Gerrit change https://git.eclipse.org/r/67624 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=9e6a1135bc8d0712f9d8f1bedd99a5f4fe00077d
New Gerrit change created: https://git.eclipse.org/r/71721
Gerrit change https://git.eclipse.org/r/71721 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=ebb18cdd8a293fee283b45620c02dd3a354660a6
The Papyrus team has done some work in Oxygen to partition the test builds and to break out components into separate repositories. Returning this bug to the pool for re-assessment.
