Re: [cross-project-issues-dev] dependencies, build and P2

[Miles Parker <milesparker@xxxxxxxxx>]

I've been arguing for simplifying things, but I think I can make a good argument for separate feature requirements. Features are not just  "a collection of bundles". They can have cross-cutting issues connected with how they are used. This means that sometimes it is reasonable to have a feature that is a superset of all of it's bundle requirements. My assumption is that you always want to have the bare minimum of requirements in plugins. That's just sound de-coupling. But with features you need to define the pieces that are needed to make your tool function correctly or well. Examples:

1. I have a bunch of plugins that generate code for an explicit runtime target. Now, none of the plugins that do the generation or related IDE tooling actually have dependencies on the runtime target, but it makes no sense to have that feature without also including the target.

2. I have a dependency on BIRT but I'm really just using some of the chart UI portion in order to make the plugin compile. However, to actually use the behavior I need to make sure a bunch of other BIRT stuff is included.

3. Because of licensing restrictions, I don't want to introduce a bundle dependency in a specific plugin and because it is loaded dynamically, I don't need to. But I do need to know it is there in order to make sure that the feature will actually function for the user.

And then of course there is the issue of wanting to be able to package up various distributions and products and using feature dependencies is often a good way of doing that.

Package requirements are a real issue WRT to the org.apache and logging stuff which is where we always seem to run into issues. In my experience the only way to avoid probably there is to make them package dependencies, which as Thomas says means that they need to be specified *somewhere*. 

On Dec 19, 2010, at 1:40 AM, Thomas Hallgren wrote:

> I'm also questioning the use of feature requirements. I can see one (somewhat far fetched) use of it and that is when all bundle inter-dependencies are expressed as packages rather than bundles. By adding feature requirements, one can encourage that those packages are provided by certain bundles. I say encourage because there's no way to guarantee that this actually happens when other bundles also provide the same packages.
> 
> In the old days, a feature requirement was interpreted as 'non-greedy', i.e. the thing had to be present in the install in order to install your feature but there would be no attempt to install it. Unless they were met, the installation would fail immediately. For some reason that interpretation is no longer valid. The feature requirements are greedy so their role is IMO very questionable.
> 
> - thomas
> 
> On 2010-12-19 10:29, Gunnar Wagenknecht wrote:
>> Am 19.12.2010 09:19, schrieb Eike Stepper:
>>> I see that there are plugin and feature dependencies possible. Would
>>> you say that the plugin dependcies are a relict from times before p2?
>> Frankly, I'm constantly asking myself the same question. They definitely
>> existed before p2. As far as I remember the old update manager used
>> those dependencies. p2 should't need them as it is capable of collecting
>> all the dependencies by using the meta-data produced from the bundle
>> manifests.
>> 
>> -Gunnar
>> 
> 
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev