Re: [e4-dev] Dependency Preference and Versioning

["Neil Bartlett" <njbartlett@xxxxxxxxx>]

Remy pointed me at this thread in reference to my statements on the
RCP newsgroup. Forgive me for picking a random message to reply to...
I have just subscribed to the list so I don't have Boris' message in
my inbox.

Boris wrote:
> > Another issue that we need to consider is the non-Java parts that go
> > into a bundle and are not contained in a package. Isn't the rule that
> > you need to use Require-Bundle if you depend on things like extension
> > points?

PDE would have you believe this is the case, but it is not. You can
declare extensions in a bundle without any sort of dependency
relationship existing between that bundle and the one that declares
the extpoint - just ignore PDE's suggestion to add the dependency. Of
course, if the extpoint requires you to implement an interface then
you must have a dependency on that interface, but it can be expressed
just as well with Import-Package as it can with Require-Bundle.
*Typically* that interface will exist in the same bundle that declared
the extpoint, which is why PDE suggests adding the dependency. But it
could exist in a third bundle.

PDE should offer to add the dependency using I-P instead of R-B, but
this is one of the ways in which PDE still favours R-B in my opinion.

I have nothing useful to say at the moment about other kind of
non-Java dependencies such as interpreted language source code etc.

Regards,
Neil


2009/1/14 Thomas Watson <tjwatson@xxxxxxxxxx>:
> We have been discussing a similar topic within OSGi. What would be nice to
> have is a generic provide/requires mechanism that can be used to express
> these types of dependencies (non-java package dependencies). Another example
> of this issue is the SWT bundle. It cannot function without one of its
> platform specific fragments installed. But there currently is no declared
> dependency form the swt host bundle and its platform specific fragments.
> This means an SWT host will resolve and all other bundles that require
> org.eclipse.swt will be resolved and think they can function, but they will
> undoubtedly fail.
>
> Wouldn't it be nice if the fragment could specify that it provides the
> native code support for SWT and the SWT host could declare a requirement for
> a native code provider.
>
> Tom
>
>
>
> Boris Bokowski ---01/14/2009 11:24:26 AM---Another issue that we need to
> consider is the non-Java parts that go into a bundle and are not contained
> in a package. Isn't th
>
>
> From:
> Boris Bokowski <Boris_Bokowski@xxxxxxxxxx>
> To:
> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
> Date:
> 01/14/2009 11:24 AM
> Subject:
> Re: [e4-dev] Dependency Preference and Versioning
> ________________________________
>
>
> Another issue that we need to consider is the non-Java parts that go into a
> bundle and are not contained in a package. Isn't the rule that you need to
> use Require-Bundle if you depend on things like extension points?
>
> Also, making everything keyed off packages is very Java-centric - what
> happens when I write a bundle containing JavaScript code?
>
> Boris
>
> Chris Aniszczyk wrote on 01/14/2009 09:26:02 AM:
>
>> Have we had a 'sins of our past' discussion around dependency
>> preferences? For example, since we are starting anew in e4, should
>> we prefer Import-Package over Require-Bundle everywhere to promote
>> looser coupling? Furthermore, do we want to prevent people from re-
>> exporting dependencies?
>>
>> For versioning... if we prefer package-level versioning... do we
>> want to evolve versions on a per-package basis or simply have
>> package versions match bundle versions?
>>
>> I'm only bringing this issue up as we have a chance to revisit the
>> way we do dependencies and version things. I know there's many cases
>> currently in the SDK where we have regretted either re-exporting a
>> bundle (e.g., org.eclipse.ui mess) or versioning something improperly.
>>
>> Thoughts?
>>
>> Cheers,
>>
>> ~ Chris
>>
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
>>
>> https://dev.eclipse.org/mailman/listinfo/e4-dev_______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>