Hi, again,
Sorry for the build churn these last couple of days. It should all be settled, now.
As it turns out, Maven is quite happy to have a module reference as its parent a different module than the one that references it as a child, when Maven is building the whole world (as in our Gerrit builds). This was the case for two plug-in projects:
- org.eclipse.papyrus.infra.gmfdiag.css.debug: referenced its parent as .. (the infra-gmfdiag-css component build) but referenced by /releng/dev as a sub-module
- org.eclipse.papyrus.customization: references its parent as .. (the customization component build) but referenced by /releng/extra as a sub-module
So, while this is okay in an all-in-one build, it broke the Developer and Extras builds in a very puzzling way: each of these plug-in projects failed to resolve dependencies that obviously were present in a referenced p2 repository, and which Tycho/Maven found in that repository. I still don’t know why this was a problem, but it is now fixed by “correcting” the parent-POM references of these two plug-ins.
One consequence of all of this is that you will find that the org.eclipse.papyrus.infra.gmfdiag.css.debug plug-in project has been moved to the /plugins/developer directory in the Git repository.
Cheers,
Christian
Hi, team,
As promised earlier this week, the second wave of refactorings for
Neon is now submitted. See an overview below, as sent out
before, and more specific migration details on the wiki:
https://wiki.eclipse.org/Papyrus/Migration_Guide/Neon
There have been a few commits just this morning (EST) since the
last time I rebased this change, so perhaps there will be a bit of
churn in the builds today. I’ll keep on top of it until the
build seems to be stable (or, as stable as it can be with 53
recurring failures).
On 9 February, 2016 at 19:55:25, Christian
Damus (give.a.damus@xxxxxxxxx)
wrote:
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
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
|