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
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
To change your delivery options, retrieve your password, or unsubscribe from this list, visit