Add ee packages
Add permission files
Check import/export version matches
Do not warn for not export/private when include-resource is used
Check in bnd if somebody uses META-INF in lower case
Check for imports
Add Spring parser to bld
Check bnd in Eclipse and non Windows envs.
Add site for Eclipse Downloads
Check if Component set/unset methods are really thread safe when used with dynamic?

OSGi Run is not recognized

When you do Run As from the top menu bar, it can not find the current project, only works in context.

Shortcuts are not matched when you repeat run

Do not use ee.* files in the -runbundles

Do not quit the framework optionally so you can inspect the framework

Make setup/teardown ... to once in JUnit runner


Get signing to work, needed for the build

Make a validation of a project: does it contain build.xml?

> I just talked to Richard and I get the problem now :-( It is tricky.  
> The key problem is that you use private API in an exported API. I  
> guess I can check for this in bnd, have to do some thinking if this  
> would not be a common pattern. Though this seems to be bad practice, I  
> am not sure it is always wrong.
I get your point. There might be some private API imports that are actually never used.
In such case we maybe don't want to make the developer's life harder.
Maybe the default behaviour of BND should be to issue an error message and stop compilation ;
and such error message could be deactivated by correctly setting a "ignore-export-consistency" 
configuration flag ?
> Would you mind if I wrote a blog about this? It is really a tricky  
> issue that is hard to see.
With pleasure ! I would be glad if this could prevent others to have the same bug. 
Cheers,
Sylvain 


Done
Check that a -runbundles= a;version=project generates an error if there is no project
Test why in a sub build that when the Private-Package overlaps the export, you get a split package warning

