Le 22 oct. 2013 à 17:04, Riccardo Foschia <riccardo.fosc...@meta-level.de> a écrit :
> Hi IvyDE developers, > > I installed the current trunk version of IvyDE (got it from the update > site for trunk builds. Plugin name is > org.apache.ivyde.feature_2.2.0.beta2-201309081502-hudson-268) and I'm > trying to use the workspace resolver to develop an Eclipse RCP application. > > Because I don't know, if the following phenomenon is a feature or a bug > (the docs don' t tell much about it) I thought to send the problem to > dev list: > > I'm developing two plugins A and B in the same workspace. B depends on > A. I use an IvyDE classpath container instead of the PDE one for both > plugin projects. A has two packages: api (which is exported, i.e. listed > in the plugin's manifest in section "Export-Package") and impl (which is > not exported, i.e. not listed in the plugin's manifest). > > Now it is possible to access classes of package impl of plugin A from > the project of plugin B without getting error markers in Eclipse. After > setting the checkbox "Read OSGi metadata" on the global preferences of > IvyDE I expected that this will cause IvyDE to setup the OSGi visibility > constraints but the code in B that accesses the "hidden" classes from A > is still not marked with an error. If I remove the IvyDE classpath > containers from the plugin projects and use the PDE classpath container > the error markers appear. > > My question is: Is this behaviour of the IvyDE classpath container a bug > or is it a feature that the checkbox "Read OSGi metadata" should not > work with project dependencies, i.e. the workspace resolver? > > IMHO it would be a great feature if "Read OSGi metadata" and the > workspace resolver would work together so that the workspace resolver > automatically sets up the OSGi visibility constraints for "upstream" > projects in the workspace. > > If it's a bug please someone tell me if I should file a bug report and > if I should provide some example code. As I read your use case, it's seems like a bug, indeed. A bug report is welcomed. Nicolas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
