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.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 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
Layered Architecture