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 >> >>
