Well, I think we just need to be more deliberate about what we decide that we want to package into any given distribution, whether RCP or setup, and go with that. In the case of the Designer bundles, we had various stages of confusion about which bundles were needed (and the set that actually were needed changed over time), whether we wanted more Designer capability from their features, etc. In the end, both the RCP and setup distribution methods are based on the p2 Director installing software, and that will *always* include required dependencies. So, the decision about third-party content to include will always be what additional content to add, either as select bundles or as features. And in the case of additional bundles, we have learned that we had best add them as dependencies of some pertinent Papyrus-RT feature because the RCP is entirely feature-based. Consequently, we should never have to add individual bundles to the setups, either.
On 19 October, 2016 at 16:53:59, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
I see. So, if I understand correctly, for future
additions to the setup models, as a rule of thumb, one should first
try *not* to add bundle requirements to the setup models, at least
for the simple case where we have explicit bundle dependencies on
APIs declared in MANIFEST files and no additional tooling or other
type of dependency is required, is that right?
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
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
|