Add quickfix when bnd/Eclipse source/test folders disagree
bnd settings:
src
bin
testsrc
testbin
(since bnd 2.3.0)
I notice this change puts a limit on the number of total source directories? We currently have a few projects with more than two source directories. Often we create a separate source directory for generated code (from JAXB, protocol buffers and SWIG in the case of our repo). Having separate source directories make it easier to filter out generated code for code coverage and static analysis tools.
Is there a way to implement this without the restriction?
Bnd only supports a single src and a single test folder. So you cannot support more in bndtools.
BJ
On Oct 11, 2014, at 13:00, kmart216 [email protected] wrote:
I notice this change puts a limit on the number of total source directories? We currently have a few projects with more than two source directories. Often we create a separate source directory for generated code (from JAXB, protocol buffers and SWIG in the case of our repo). Having separate source directories make it easier to filter out generated code for code coverage and static analysis tools.
Is there a way to implement this without the restriction?
— Reply to this email directly or view it on GitHub.
Bnd has never supported more than a single src folder. The bnd property "src" can be set to a single directory. It's default value is "src". =
I guess we've been using Bnd in an unsupported way. I guess this makes sense from what I have seen in Bndtools when looking at exported packages, but we have been able to work around it. Unfortunately, the packages for the different source folders are fairly intertwined so i don't think I have a good way to split up into separate projects. The current organization is something like for an API project:
- src
- org.package.a
- org.package.b
- jaxb-gen-src
- org.package.a.types
- org.package.shared.types
I don't want to combine the source folders as having generated and non-generated code would be confusing and I would basically have to disable a lot of Eclipse warnings as the generated code will have a bunch of warnings. Also, we use the different source folders to help filter out generated code from code coverage reporting.
I could split up projects, but then I would have to separately list each export package which makes it hard to maintain instead of using an export statement like org.package.* as I do now. Also, it is nice to be able to give developers a single API JAR to develop against.
Since these are API packages, I don't have the freedom to rename them and make them less intertwined at the moment.
Is there a path that I'm not thinking of that would work better in the Bnd environment?
yeah, put the generated types in a separate bundle
You can put the bundle built from generated sources on the build path of your original bundle and use Export-Package / Private-Package to include the classes into the bundle you distribute downstream. It's a bit of a hassle but it'll give working offline builds. There's a catch however: if your generated code must not depend on the "regular" code. It would work in multiple source folders arrangement but not with separated generation & compilation.