I have this in my products (cnf/build.bnd), might be helpful.
# To include source and debug information in the Eclipse build but NOT in the
# gradle build, uncomment the following lines:
-sources: ${if;${gestalt;batch};false;true}
Ferry
On 23/04/17 17:36, David Jencks wrote:
I mean OSGI-OPT.
The source jars for released versions are at maven central, but I was debugging
trunk, and the source jars aren’t built automatically (and, actually I thought
of adding source to the bundle and didn’t think of building the source jar).
Wrong list — but would dragging/dropping a source jar into the bndtools “local”
repo add it to the existing bundle?
I still think that having one artifact rather than two is more convenient, even
if bndtools finds a source jar next to any bundle you drag and drop into a
repository.
thanks
david jencks
On Apr 23, 2017, at 7:21 AM, Thomas Watson <[email protected]> wrote:
I think including source is fine.
Did you mean OSGI-OPT instead of OSGI-INF. The spec recommends OSGI-OPT be
used to include source.
I am concerned that bndtools makes it hard for one such as you to debug our
code. If it is hard for you then it is impossible for the masses. This
seems like a pretty big usability issue in bndtools. Are not the source
jars published to maven central for the tools to find?
Tom.
On Sun, Apr 23, 2017 at 2:13 AM, David Jencks <[email protected]>
wrote:
Working on FELIX-5618 I couldn’t figure out a way to debug DS in bndtools
without modifying the DS bundle to include sources. This is certainly the
easiest way to get the sources visible in a bndtools environment. After
this experience I’d like to include the sources for DS in OSGI-INF as
recommended by Peter et al. I’d like to include the sources in the util
jar as well, I think then the extender base classes will show up in the DS
bundle.
Any objections?
thanks
david jencks
--
Ferry Huberts
