Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] Notice: Papyrus Bundle Refactorings for Neon M6

Hi, François and team,

I've managed with a couple of tricksy rebases to excise almost all of the files that changed only their line endings, so now this is more representative of the actual refactoring changes:

https://git.eclipse.org/r/#/c/66171/

I hope this is useful.

Christian

On 10 February, 2016 at 07:55:16, Christian Damus (give.a.damus@xxxxxxxxx) wrote:

Hi, François,

Good luck with the Gerrit UI.  Unfortunately, you will find that the change includes almost all of the files in the repository, only changing their line endings.  This would seem to be a result of the addition of a .gitattributes file (why weren’t all of the line endings converted at that time?) and I don’t know what to do about it.

The main outcome of that e-mail thread about POMs, as I understood it then and more recently in discussion with Camille about this build effort, was that we must not use nested Eclipse projects to manage intermediate POMs in the workspace because Egit and other tools can’t cope with that.  Ultimately, the goal is to build each “layer” of Papyrus in a separate Hudson job, pulling in its dependencies as binaries from p2, which I think will require the intermediate POMs anyways.  Our build just doesn’t scale and isn’t properly testable, so we have no viable alternatives.

Access to the POMs for editing is provided by the repository browser in the Git Repositories view of Egit.  New POMs can’t be created there, but I think it isn’t too much to ask developers to interact directly with their computer’s filesystem once on the occasion of creating a new intermediate POM.  Also, it will be quite a simple matter for me to add a context-menu action to the Papyrus Dev Tools that opens the parent POM of a selected pom.xml

Certainly, I can add brief descriptions in the intermediate POMs.

Christian

On 10 February, 2016 at 03:47:51, LE FEVRE FRANCOIS (francois.le-fevre@xxxxxx) wrote:

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

 

Description : PapyrusLogo_SmallFormatwww.eclipse.org/papyrus

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian Damus
Envoyé : mercredi 10 février 2016 01:55
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : [mdt-papyrus.dev] Notice: Papyrus Bundle Refactorings for Neon M6

 

Hi, Team,

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 ArchitectureLayered 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 LayerInfra 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.propertiesbundle 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.typesbundle, 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 framework
  • org.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

 


_______________________________________________
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