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 <[email protected]>: > 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 <[email protected]> > To: > E4 Project developer mailing list <[email protected]> > 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 >> [email protected] >> >> https://dev.eclipse.org/mailman/listinfo/e4-dev_______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > > _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
