Open paulbakker opened 9 years ago
+1
Without the provided fix only classes directly located in com.gs.collections.api
and com.gs.collections.impl
package can be used in other OSGi Bundles.
The "reactor-bus" (using gs-collections) bundle requires for example:
com.gs.collections.api.block.procedure,
com.gs.collections.api.list,
com.gs.collections.impl.list.mutable,
com.gs.collections.impl.map.mutable
Unfortunately, we still can't take pull requests in this repository. We've recently opened up Eclipse Collections where we'll be able to accept contributions. Eclipse Collections 7.0.0 is nearly identical to GS Collections 7.0.0 but with "com.gs.collections" changed to "org.eclipse.collections". It's also released under the EDL and EPL.
If you need this fix in GS Collections to use with existing projects that depend on it, I could backport the fix.
Is there a reason for the fork from GS to Eclipse collections? Is this due to differing licenses? Are the two codebases likely to diverge?
We'll work on new features in Eclipse Collections. We'll probably just port critical fixes to GS Collections.
On Tue, Jan 5, 2016 at 6:42 PM bigkahuna1uk notifications@github.com wrote:
Is there a reason for the fork from GS to Eclipse collections? Is this due to differing licenses? Are the two codebases likely to diverge?
— Reply to this email directly or view it on GitHub https://github.com/goldmansachs/gs-collections/pull/17#issuecomment-169170361 .
The instructions to generate OSGi Export-Package headers are not correct yet. The bundles don't resolve in an OSGi framework. This pull request fixes that.