There are three reasons that come to my mind. First, that bundle dependencies only express what the particular bundle needs of API from another, but that doesn’t account for related tooling and capabilities that also support the use cases. For example, it often happens that a product will plug in to extension points in the core/headless APIs of something, but that isn’t actually useful to the user unless the UI part of that something is also included. But there’s no actual implementation-level dependency on those UI bundles. In general, bundle dependencies only resolve to bundles; nothing will infer from them that any feature(s) containing those bundles should be installed, so we usually have to add those features explicitly in a setup or product definition.
Then there are the cases where we have to account for missing dependencies: for example, many things in Papyrus (and therefore Papyrus-RT) won’t work if the element-types in the UML Types bundle aren’t installed, but that’s a dependency on models that few (if any) bundles actually declare in their manifests. So, the integrating application (e.g., RCP, setup, etc.) has to make sure that it is accounted for. There are better ways to fix this, but sometimes the fix would be in an external component.
And last, it may be that we want to make sure that a particular version of some dependency is used for RCP/packaging/user-experience reasons even though the application code as such can work with a much wider range. So, declaring that dependency explicitly with the required version isn’t actually redundant.
I don’t know how many of these cases actually apply to how many of the things in our setups and RCP.
Cheers,
Christian
On 19 October, 2016 at 14:29:45, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
Ok, but there is one thing that I don't understand.
If we remove all oep.designer.* plugins from the setup models and
they still show up in the installation, then that suggests that
Oomph picks up dependencies, presumably from the MANIFEST files,
no? But if this is the case, then why would it be necessary to
specify *any* features and plugins at all in the setup models? Why
would some dependencies be implicitly brought in and not others?
Hi,
Okay, so we still have a
confusion regarding why these Designer plugins were added to the
Oomph tester setup in the first place. I thought that we had some
good explanation for why they were originally added... :(
So I went ahead and tested
this myself, and continued the removal that Christian made in
patch-set 5 (compared to patch-set 4) for https://git.eclipse.org/r/#/c/83321/ by also removing
the explicit dependency on the two remaining Designer plugins from
the end-user setup file in preparation for the 0.8 release, leaving
no explicit dependencies to the Designer plugins in the setup file
itself.
And as I have suspected
now for a while, this resulted in that the relevant Designer
plugins are installed anyway. When checking the "Plugins" tab in
the "Installation Details" dialog, there are still four Designer
plugins installed, since we already have implicit dependencies from
the Papyrus-RT plugins that actually need these plugins from
Designer. No need at all for having any explicit dependencies in
Oomph setup file, and thus no need for the dependencies from the
RCP feature either.
The screen shot shows the
four remaining Designer related plugins that we still have some
(implicit) dependencies in the latest 0.8 (nightly) build. This is
the same set of plugins that you get when you install using
patch-set 5 (which still have the two remaining ones,
org.eclipse.papyrus.designer.languages.common.base and
org.eclipse.papyrus.designer.languages.cpp.library, explicitly
defined in the setup file).
I must apologize for
causing so much confusion regarding this, since I really thought
that these Designer dependencies existed explicitly in the Oomph
tester-setup file for some good reason. I should have checked this
much earlier myself, before pushing so hard on trying to align the
tester setup with the RCP (and causing all the additional confusion
that forced us to add them to the RCP feature where they don't even
belong).
I mean, we have exactly
the same kind of behavior with the RSARTE import feature, which
have implicit dependencies on the RSA import in Papyrus. We never
explicitly specify that we also need the plugins from the RSA
import, but only bring the RSARTE import into the setup file, and
all this it implicitly depends on gets installed. I would expect
the same when it comes to the Designer plugins as well.
Not sure how much more
"cleaning up" of these dependencies we have time for prior to the
0.8 release. But for the Oomph end-user setup file (which as I
understand is not gating the 0.8 release) we should be able to
remove those remaining ones as well.
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|
