Hi Christian,
Thanks for this email that summarizes all work done.
I will look deeper at the gerrit.
But I don’t know if it will be accepted by papyrus Core team since they have agreed not to introduce intermediate poms.
We had a lot of internal meeting but also open discussion (https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/msg02471.html )
Nevertheless I totally agree with your proposition since I and Benoit are trying to push this new vision over one year. (constrainsts: https://git.eclipse.org/r/#/c/41167/
Elementtypes: https://git.eclipse.org/r/#/c/50501/ or nattable: https://git.eclipse.org/r/#/c/51699/ )
Just a small first remark, could you please add the project description of new project directly in the pom in the <description> section?
Francois
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de SCHNEKENBURGER Remi 211865
Envoyé : mercredi 10 février 2016 09:28
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : [PROVENANCE INTERNET] Re: [mdt-papyrus.dev] Notice: Papyrus Bundle Refactorings for Neon M6
Hi Christian,
Thanks for this update! There should not be issues with committers plan for this week.
Concerning the palette, the major part of the framework is located in UML layer, which is an historical issue. Almost everything from the palette is agnostic of the UML language, especially now with the paletteconfiguration framework that relies on the element types. The palette configuration has a kind of dependency to UML because of the ‘requiredProfile’ field in the metamodel, but this field should be replaced by a ‘filter’ as defined by the filter plugin, in the infra layer.
For the specific case of the xml based palette and this css contribution, we unfortunately have no replacement for post actions targeting notation objects for now. The xml based palette providers should be deprecated in 2.0, as the Papyrus toolsmiths should rather rely on the palette configuration model than xml (better workflow and integration than the xml palette). So for the css plugin, I think it is good to move it to UML, as all the framework of XML palette is in UML layer, but I think palette configuration plugins should be located in gmfdiag.common. What is your opinion?
FYI, I could not read the pictures from your message, I don’t know if Eclipse mailing lists are doing some kind of filtering.
Regards,
Rémi
-------------------------------------------------------
Rémi SCHNEKENBURGER
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
www.eclipse.org/papyrus
This is advanced notice of a new large-scale refactoring readying to be merged into the master branch for this Neon M6 milestone. I am aiming for a Friday morning (GMT–5) submission to give it the day here to shake out and, I hope, not disrupt everybody else’s plans for this week. Please speak up if you have questions or concerns.
The Gerrit review 66171 currently in progress aims to complete the remediation of invalid (“upward-directed”) dependencies between plug-ins in the various “layers” of the Papyrus Architecture. In particular, we will now have an acyclic graph of dependencies (there were all kinds of cycles in the Mars release) like so:
Layered Architecture
These relationships are, of course, aggregations of dependencies that are expressed between individual bundles. Also, the “Infra Layer” is further subdivided, roughly so:
Infra Layer
Projects Moved
To prepare for Hudson builds per component, the entire Main Plug-ins tree in the git repository is reworked as a hierarchical Maven build (so is the Main Features tree, but that has no impact on your workspace). Several plug-in projects are moved around in the directory tree, including (highlighted items are also renamed):
Project Moved | Moved From | Moved To |
org.eclipse.papyrus.eclipse.project.editors | infra | infra/editor |
org.eclipse.papyrus.infra.constraints[.*] | infra | infra/constraints |
org.eclipse.papyrus.infra.tools | infra | infra/core |
org.eclipse.papyrus.infra.filters[.*] | infra | infra/filters |
org.eclipse.papyrus.infra.gmfdiag.css.palette | infra/gmfdiag | uml/diagram |
org.eclipse.papyrus.infra.hyperlink | infra | infra/misc |
org.eclipse.papyrus.infra.psf | infra | infra/misc |
org.eclipse.papyrus.infra.sync | infra | infra/misc |
org.eclipse.papyrus.infra.newchild[.*] | infra | infra/newchild |
org.eclipse.papyrus.infra.onefile | infra | infra/onefile |
org.eclipse.papyrus.infra.onefile.ui | infra | infra/ui |
org.eclipse.papyrus.infra.extendedtypes[.*] | infra | infra/xtypes |
org.eclipse.papyrus.infra.ui[.*] | infra | infra/ui |
org.eclipse.papyrus.infra.widgets[.*] | infra/widget | infra/ui |
Projects Added
The following plug-in projects are added to support the refactoring effort:
Project Added | Comments |
org.eclipse.papyrus.infra.emf.gmf | this provides APIs that build on the “super-EMF” capabilities of the GMF Run-time core APIs, not related to notation or the diagram editors. Some APIs are moved out of the Papyrus Diagram Layer into here that are not diagram-oriented and are required by Infra Layer code |
org.eclipse.papyrus.infra.nattable.gmfdiag | some diagram-oriented APIs (in particular, copy/paste strategies) were moved out of the infra.nattable.common bundle to rid that one of dependencies on the Diagram Layer |
org.eclipse.papyrus.infra.properties.ui | the org.eclipse.papyrus.views.properties bundle doesn’t actually implement a view, as such, because the Properties View is provided by Eclipse (this isn’t like the Model Explorer and Model Validation views). Also, most of the APIs are the framework for dynamic XWT-based editing that is also re-used by the Welcome Page. Accordingly, the vast majority of the APIs in this views.properties bundle are moved into infra.properties.ui . The old bundle remains for management of workspace preferences for custom property view enablement |
org.eclipse.papyrus.uml.service.types.ui | a bunch of edit-helper advices for the UML metamodel that interact with the user through UI dialogs and such are moved into this bundle from the org.eclipse.papyrus.uml.service.types bundle, which now is headless. Accordingly, the registration of those advices are moved from the model in the old bundle into a new model in the new bundle |
org.eclipse.papyrus.uml.service.types.ui.tests | a new test fragment that removes tests of the UI-dependent advices from the headless test bundle |
Projects (and Bundles) Renamed
A few bundles are renamed, in some cases as part of their move from one Papyrus architectural layer to another:
org.eclipse.papyrus.infra.gmfdiag.css.palette
becomes org.eclipse.papyrus.uml.diagram.css.palette
because the CSS styles that it provides ride along on the overtly UML Profile–oriented palette provider frameworkorg.eclipse.papyrus.infra.services.resourceloading.preferences
becomes org.eclipse.papyrus.infra.services.resourceloading.ui
because preference pages are only a special case of UI and this bundle had to be blown up by extracting non-UI APIs out of it, anyways
Hierarchical Maven Build
For the Main Plug-ins and Features, the Maven module structure is now strictly hierarchical: every module’s parent is its parent directory, except that the root POMs are all still in the releng/
folder: the releng/main/pom.xml
calls into three modules, thus:
<modules>
<
module>../../plugins</module>
<
module>../../features/papyrus-main-features</module>
<
module>site</module>
<
/modules>
All of the root- and intermediate-level modules (those that have the POM packaging type) have the version number 0.0.1
. This serves two purposes: it clearly signals that they do not generate an Eclipse installable artifact and it distinguishes them from any bundle or feature projects that happen to have the same name. These version won’t have to be maintained henceforward. All modules are in (and inherit from their parent) the org.eclipse.papyrus
group.
Migration
Not as many APIs are actually broken in this phase of the refactoring as in the first phase in the Neon M5 milestone. Most updates were accommodated by pulling APIs from a higher layer to a lower layer in the stack and deprecating the originals. So, the remnant APIs self-document the appropriate migration strategies.
However, it is still necessary to break some APIs, such as for the headless/UI partitioning where UI-oriented APIs simply cannot co-reside with headless APIs and for pushing up APIs that belong in higher layers (stubs cannot sensibly remain behind). All active projects in the main Papyrus git repository are refactored to adapt to these changes. For details of how to migrate any other code, the Migration Guide on the wiki will be updated when this Gerrit review is submitted. An announcement will be made on the mailing list at that time.
After this phase of refactoring is complete, I shall be turning my attention to updating the management of bundle and feature versions, including:
- provisioning tooling (PDE, Oomph) for analysis of version numbering problems
- (with the help of the previous item) updating bundle and feature numbers from 1.2 to 2.0 as appropriate for the refactorings done so far
- adopting Eclipse’s best practices concerning dependency version ranges and re-exports
Thanks for your attention,
Christian