Home » Eclipse Projects » Equinox » Express Requires/Includes in P2 Metadata or Feature.xml?
| Express Requires/Includes in P2 Metadata or Feature.xml? [message #130805] |
Wed, 06 May 2009 15:50  |
Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
Hello Again,
First of all, many thanks to Simon and Andrew for sticking with me through
all of my metadata generation issues in previous threads! I have done
quite a bit of prototyping, and I have figured out most of my issues with
P2 and generating metadata and features. I only have a few questions
left, and this is one of them. ;)
Let's say I have a configuration feature whose sole purpose is to
contribute root files, much like the "rcp.configuration" CU in the main
Eclipse build that Andrew described in detail. Let's also say that I
would like more than one product to "include" this configuration feature.
Let's also say that more than one of these products can co-exist at a time
in a given profile. To make this example concrete, let's say I am
supporting two embedded devices in one IDE, and they both include a bunch
of hardware-specific files, but they both include the exact same
"compiler" that is installed via the same configuration feature.
OK, so my question is - how do I declare this dependency on the
configuration feature? Ideally, my configuration feature is not going to
install a feature into my eclipse installation, its sole purpose is to
provide a binary artifact on the update site and an entry in the metadata
describing the touchpoint to install these files. This is exactly how the
"rcp.configuration" feature works in the Eclipse install. As far as I can
see, the way the "rcp.configuration" feature is included in the
installation is simply by declaring a "requires" *in the metadata only* in
the "org.eclipse.sdk.ide" feature. There is nothing declared in the
feature.xml file of the "org.eclipse.sdk.ide" feature that mentions the
"rcp.configuration" feature.
So, this seems to be an option. But I don't think it will work for me.
What happens if there were a second product/feature that declared exactly
the same thing - for example, an "org.eclipse.sdk.augmented.ide"? And
what if they were meant to co-exist? Wouldn't uninstalling one undo all
of the configuration that was done in "rcp.configuration" potentially
messing up the other? Or am I wrong about this?
So, the other way I see to do this would be to add an "includes" entry for
the "rcp.configuration" feature right in to the feature.xml of
"org.eclipse.sdk.ide" and "org.eclipse.sdk.augmented.ide". I have tested
this, and P2 handles it nicely. It shows up as a nested feature and will
only uninstall it when the last item that 'includes' it is uninstalled.
The problem is, my cool binary-artifact-only configuration feature now has
to become a full-fledged feature complete with a feature.xml, at least at
build time, in order for me to build all of the other features that
'include' it. This is a bit of a pain. I also found that I don't
actually need to install a real feature for the configuration feature, and
P2 will still show it as a nested feature based on the CUs only. This all
works great (apart from the build-tim dependency issue) but feels a little
bit wrong because I am saying Feature A include Feature B, but no real
feature is installed for Feature B - only a bunch of external files.
Anyway, if anyone is still following...how should I handle this situation?
Is there a way to achieve this in metadata-only?
Mark.
|
|
|
| Re: Express Requires/Includes in P2 Metadata or Feature.xml? [message #130818 is a reply to message #130805] |
Wed, 06 May 2009 18:47  |
| Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
Mark Melvin wrote:
> Hello Again,
> First of all, many thanks to Simon and Andrew for sticking with me through
> all of my metadata generation issues in previous threads! I have done
> quite a bit of prototyping, and I have figured out most of my issues with
> P2 and generating metadata and features. I only have a few questions
> left, and this is one of them. ;)
> Let's say I have a configuration feature whose sole purpose is to
> contribute root files, much like the "rcp.configuration" CU in the main
> Eclipse build that Andrew described in detail. Let's also say that I
> would like more than one product to "include" this configuration feature.
> Let's also say that more than one of these products can co-exist at a time
> in a given profile. To make this example concrete, let's say I am
> supporting two embedded devices in one IDE, and they both include a bunch
> of hardware-specific files, but they both include the exact same
> "compiler" that is installed via the same configuration feature.
> OK, so my question is - how do I declare this dependency on the
> configuration feature? Ideally, my configuration feature is not going to
> install a feature into my eclipse installation, its sole purpose is to
> provide a binary artifact on the update site and an entry in the metadata
> describing the touchpoint to install these files. This is exactly how the
> "rcp.configuration" feature works in the Eclipse install. As far as I can
> see, the way the "rcp.configuration" feature is included in the
> installation is simply by declaring a "requires" *in the metadata only* in
> the "org.eclipse.sdk.ide" feature. There is nothing declared in the
> feature.xml file of the "org.eclipse.sdk.ide" feature that mentions the
> "rcp.configuration" feature.
> So, this seems to be an option. But I don't think it will work for me.
> What happens if there were a second product/feature that declared exactly
> the same thing - for example, an "org.eclipse.sdk.augmented.ide"? And
> what if they were meant to co-exist? Wouldn't uninstalling one undo all
> of the configuration that was done in "rcp.configuration" potentially
> messing up the other? Or am I wrong about this?
> So, the other way I see to do this would be to add an "includes" entry for
> the "rcp.configuration" feature right in to the feature.xml of
> "org.eclipse.sdk.ide" and "org.eclipse.sdk.augmented.ide". I have tested
> this, and P2 handles it nicely. It shows up as a nested feature and will
> only uninstall it when the last item that 'includes' it is uninstalled.
> The problem is, my cool binary-artifact-only configuration feature now has
> to become a full-fledged feature complete with a feature.xml, at least at
> build time, in order for me to build all of the other features that
> 'include' it. This is a bit of a pain. I also found that I don't
> actually need to install a real feature for the configuration feature, and
> P2 will still show it as a nested feature based on the CUs only. This all
> works great (apart from the build-tim dependency issue) but feels a little
> bit wrong because I am saying Feature A include Feature B, but no real
> feature is installed for Feature B - only a bunch of external files.
> Anyway, if anyone is still following...how should I handle this situation?
> Is there a way to achieve this in metadata-only?
> Mark.
OK, it turns out that this *is* possible in metadata only and I have run a
bunch of tests to reproduce the behavior. Nice. I still have a couple
unknowns though.
It seems that I still will have a build-time dependency in the metadata.
I'll need to know what the latest version of the configuration feature is
to inject it into the p2.inf, or use a broad range and manually update the
version requirements in all of my p2.inf files. I guess it is no
different than maintaining inter-feature dependency versions...
How does Eclipse handle this? It may in Andrew's previous post but I'd
have to go back and parse it out.
Second, is there any way to disallow a configuration feature to be
installed by itself, outside of something that requires it? For instance,
if I have the following:
my.feature.group.A
+- <requires> configuration.feature.group.A
It is possible to install newer or incompatible version of
"configuration.feature.group.A" by either installing a newer version of
something *else* that requires it, or by showing all CU's (turning off
groups) in the UI and simply selecting it by itself. This can result in a
mess.
Are there provisions to make a CU hidden from the UI entirely unless it is
being included as part of a larger install? This won't address the
problem of ending up with something like this:
my.feature.group.A
+- <requires> configuration.feature.group.A v1.0
my.feature.group.B
+- <requires> configuration.feature.group.A v1.1
Which basically means I now have two different versions of the same
configuration feature installed, but there may be ways around that I am
not aware of or something I am not doing properly.
Thanks!
Mark.
|
|
|
| Re: Express Requires/Includes in P2 Metadata or Feature.xml? [message #130877 is a reply to message #130818] |
Wed, 06 May 2009 20:37 |
| Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
(I'm going to keep answering my own questions as I figure stuff out for
the benefit of others. I appreciate the help I am getting so please don't
take this as me being impatient...)
> Are there provisions to make a CU hidden from the UI entirely unless it is
> being included as part of a larger install? This won't address the
> problem of ending up with something like this:
> my.feature.group.A
> +- <requires> configuration.feature.group.A v1.0
> my.feature.group.B
> +- <requires> configuration.feature.group.A v1.1
> Which basically means I now have two different versions of the same
> configuration feature installed, but there may be ways around that I am
> not aware of or something I am not doing properly.
I found that to avoid the problem of two different versions of a
particular feature group being installed, I have to set the
"singleton=true" property on the installation unit. Thus, in my p2.inf, I
need to do this:
singleton=true
OR
units.0.singleton=true
Now to figure out how to hide/prevent installation of arbitrary IUs if
they are intended to be nested within other features only!
Mark.
|
|
|
| Re: Express Requires/Includes in P2 Metadata or Feature.xml? [message #131030 is a reply to message #130877] |
Mon, 11 May 2009 14:31 |
 Andrew Niefer
Messages: 990
Registered: July 2009 |
Senior Member |
|
|
Mark Melvin wrote:
> Hello Again,
>
> As far as I can see, the way the "rcp.configuration" feature
> is included in the installation is simply by declaring a "requires" *in
> the metadata only* in the "org.eclipse.sdk.ide" feature. There is
> nothing declared in the feature.xml file of the "org.eclipse.sdk.ide"
> feature that mentions the "rcp.configuration" feature.
We don't have a 'org.eclipse.sdk.ide' feature, so I'm not sure where
you're seeing this. We do have a 'org.eclipse.sdk.ide' product file
(sdk.product). This .product file does include
'org.eclipse.rcp.configuration' as an included feature in the product.
Our other 'org.eclipse.platform.ide' (platform.product) and
'org.eclipse.rcp.id' (typo here?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=275657) also both include
the configuration feature.
> The problem is, my cool binary-artifact-only configuration
> feature now has to become a full-fledged feature complete with a
> feature.xml, at least at build time, in order for me to build all of
> the other features that 'include' it. This is a bit of a pain.
Yes, we do have a build-time feature.xml for rcp.configuration that
includes nothing, there is no runtime artifact for this feature because
the build.properties file for the feature does not have a "bin.includes"
property. The feature.xml here only serves as a convenient mechanism
for generating the metadata. There is a (generated) p2.inf for this
feature.
> It seems that I still will have a build-time dependency in the
> metadata. I'll need to know what the latest version of the
> configuration feature is to inject it into the p2.inf, or use a broad
> range and manually update the version requirements in all of my p2.inf
> files. I guess it is no different than maintaining inter-feature
> dependency versions...
Our products say nothing about which version of rcp.configuration to
include. Currently, when the publisher goes to include
rcp.configuration into the product, there is no advice telling it which
version to use, so it does a query on the build repo and uses the latest
version IU that it finds.
This works because we introduced the dependency by including the
rcp.configuration feature in the .product file, not by using a p2.inf file.
> Now to figure out how to hide/prevent installation of arbitrary IUs if
> they are intended to be nested within other features only!
You could perhaps use p2.inf to introduce on your configuration IU some
arbitrary requirement that you also provide on your containing feature:
my.feature.group.A
- <provides> my.namespace.configuree
- <requires> configuration.feature.group
configuration.feature.group
- <requires> my.namespace.configuree
-Andrew
|
|
|
| Re: Express Requires/Includes in P2 Metadata or Feature.xml? [message #131146 is a reply to message #131030] |
Mon, 11 May 2009 19:27 |
| Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
Andrew Niefer wrote:
> Mark Melvin wrote:
> > Hello Again,
> >
> > As far as I can see, the way the "rcp.configuration" feature
> > is included in the installation is simply by declaring a "requires" *in
> > the metadata only* in the "org.eclipse.sdk.ide" feature. There is
> > nothing declared in the feature.xml file of the "org.eclipse.sdk.ide"
> > feature that mentions the "rcp.configuration" feature.
> We don't have a 'org.eclipse.sdk.ide' feature, so I'm not sure where
> you're seeing this. We do have a 'org.eclipse.sdk.ide' product file
> (sdk.product). This .product file does include
> 'org.eclipse.rcp.configuration' as an included feature in the product.
Sorry - I meant "org.eclipse.sdk".
> Our other 'org.eclipse.platform.ide' (platform.product) and
> 'org.eclipse.rcp.id' (typo here?
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=275657) also both include
> the configuration feature.
> > The problem is, my cool binary-artifact-only configuration
> > feature now has to become a full-fledged feature complete with a
> > feature.xml, at least at build time, in order for me to build all of
> > the other features that 'include' it. This is a bit of a pain.
> Yes, we do have a build-time feature.xml for rcp.configuration that
> includes nothing, there is no runtime artifact for this feature because
> the build.properties file for the feature does not have a "bin.includes"
> property. The feature.xml here only serves as a convenient mechanism
> for generating the metadata. There is a (generated) p2.inf for this
> feature.
Right. I understand how this bit works now.
> > It seems that I still will have a build-time dependency in the
> > metadata. I'll need to know what the latest version of the
> > configuration feature is to inject it into the p2.inf, or use a broad
> > range and manually update the version requirements in all of my p2.inf
> > files. I guess it is no different than maintaining inter-feature
> > dependency versions...
> Our products say nothing about which version of rcp.configuration to
> include. Currently, when the publisher goes to include
> rcp.configuration into the product, there is no advice telling it which
> version to use, so it does a query on the build repo and uses the latest
> version IU that it finds.
> This works because we introduced the dependency by including the
> rcp.configuration feature in the .product file, not by using a p2.inf file.
This is still a source of confusion for me. I have managed to declare my
dependencies in the p2.inf file only and that works with fixed version
dependencies. But I don't use .product files to drive my build. Is there
any way I can get the magical version replacement via p2.inf and Ant
publisher/generator tasks only?
>> Now to figure out how to hide/prevent installation of arbitrary IUs if
>> they are intended to be nested within other features only!
> You could perhaps use p2.inf to introduce on your configuration IU some
> arbitrary requirement that you also provide on your containing feature:
> my.feature.group.A
> - <provides> my.namespace.configuree
> - <requires> configuration.feature.group
> configuration.feature.group
> - <requires> my.namespace.configuree
I have figured this bit out by making the IUs I want to hide *not* a group
and that seems to work fine.
Mark.
|
|
|
Goto Forum:
Current Time: Thu Apr 25 06:19:11 GMT 2024
Powered by FUDForum. Page generated in 0.03308 seconds |
] 
Search
Help
Register
Login
Home
