Using Bndtools in folders outside the Eclipse workspace / working with legacy projects

279 views
Skip to first unread message

Dave

unread,
May 25, 2014, 1:07:51 PM5/25/14
to bndtool...@googlegroups.com
I'm using Bndtools 2.3.0.REL-20140510-023245.

The attached tarball contains the project that was an existing project with the Bndtools project nature added. It used to be a standard Java project that used bnd/Ant. I've stripped most of the original files to make the example as simple as possible. When I add build dependencies they don't seem to show up in the "Bnd Bundle Path" in Eclipse as expected. I end up with a bunch of compiler warnings because the dependencies haven't been met (osgi.core, osgi.cmpn, biz.aQute.bnd.annotation).

Here's the bnd.bnd file also in the attachment:

-buildpath:  \
osgi.cmpn,\
osgi.core,\
biz.aQute.bnd.annotation
Private-Package:  \
example.test

Here's the errors I get:

InvalidSyntaxException cannot be resolved to a type Utilities.java /shared-shell/src/example/test line 70 Java Problem

BundleContext cannot be resolved to a type Utilities.java /shared-shell/src/example/test line 40 Java Problem

The import org.osgi cannot be resolved Utilities.java /shared-shell/src/example/test line 8 Java Problem

ServiceReference cannot be resolved to a type Utilities.java /shared-shell/src/example/test line 53 Java Problem

ServiceReference cannot be resolved to a type Utilities.java /shared-shell/src/example/test line 45 Java Problem

The import org.osgi cannot be resolved Utilities.java /shared-shell/src/example/test line 7 Java Problem

The import org.osgi cannot be resolved Utilities.java /shared-shell/src/example/test line 6 Java Problem

I've seen many post about the location of the cnf project in relationship to the workspace. From what I've read in various posts and bug logs (but could not tell from "official" documentation), you can have the cnf folder anywhere as long as all projects are in sibling folders of the cnf folder (which I have done). Is this still supposed to work?. In my case, I created the cnf folder using Eclipse in a specified location (/Users/dhumeniuk/git/th/those/cnf, as "those" is the root of the repository I'm working in) and the moved the project attached to a sibling folder. I've also went back and created a new project from scratch in the same /Users/dhumeniuk/git/th/those folder and it has the same issues. 

Under Eclipse->Preferences->Bndtools OSGi, I've set debug:build logging to "Full" but I'm not sure what that does, didn't notice any difference.

What can I check to make sure things are set up correctly? Can I run things in a certain mode to get more information. I don't get any errors besides the compiler ones.
example.test.tgz

Dave

unread,
May 25, 2014, 1:26:08 PM5/25/14
to bndtool...@googlegroups.com
If I create a new Eclipse workspace and with a new cnf folder inside the workspace, I am then able to create projects inside the workspace that can be configured and built. It seems that putting everything is not only preferred but required?

I have avoided putting the source workspace in the Eclipse workspace so far because we have in the past have tried to put projects from multiple repos into a single Eclipse workspace (which I know is not possible due to the restrictions of Bndtools) and also because I have run into issues farther in the past where the Eclipse workspace would become corrupted or the code workspace (happened a lot with SVN, especially with earlier versions of Subclipse) would become corrupted and I got tired of having to recreate them both. I guess I'll give putting everything together again another try and see how that works. I'm using Git now which seems to have less issues with things getting corrupted.

Peter Kriens

unread,
May 26, 2014, 3:50:15 AM5/26/14
to bndtool...@googlegroups.com
The best practice is:

/ws
/myws << bnd ws
/.git
/cnf
/build.bnd
/myproject
/bnd.bnd
/otherws
/.git
/cnf
/build.bnd
/otherproject
/bnd.bnd
/metadata/ << Eclipse ws
myws/
.metadata
otherws/
.metadata


In Eclipse you create a workspace in /metadata/myws but you create the projects and this cnf in /ws/myws. I.e. you keep the Eclipse metadata outside the project. You really do not want to commit the metadata but there is also another reason when you use git. git clean -fdx is the perfect way to clean a project since it makes it identical to an offline build image. However, if you have your .metadata directory in the project's workspace you zap that as well, terribly annoying since it contains a lot of personal settings. 

In general bndtools is not that bad in supporting this model, it generally creates the projects in the same directory as the cnf directory. However, you always have to check the project directory when you create a new project.

A big help is the bnd command line. You can install this with jpm (http://jpm4j.org/#!/md/install)

$ [sudo] jpm install bnd@*
$ cd /ws/myws/myproject
$ bnd debug

This will tell you about may common errors, and if it misses one, let me know.

Kind regards,

Peter Kriens


On 25 mei 2014, at 19:26, Dave <dhum...@gmail.com> wrote:

If I create a new Eclipse workspace and with a new cnf folder inside the workspace, I am then able to create projects inside the workspace that can be configured and built. It seems that putting everything is not only preferred but required?

I have avoided putting the source workspace in the Eclipse workspace so far because we have in the past have tried to put projects from multiple repos into a single Eclipse workspace (which I know is not possible due to the restrictions of Bndtools) and also because I have run into issues farther in the past where the Eclipse workspace would become corrupted or the code workspace (happened a lot with SVN, especially with earlier versions of Subclipse) would become corrupted and I got tired of having to recreate them both. I guess I'll give putting everything together again another try and see how that works. I'm using Git now which seems to have less issues with things getting corrupted.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Dave

unread,
May 26, 2014, 1:05:17 PM5/26/14
to bndtool...@googlegroups.com
Okay. I went back to my original set up basically where the Eclipse workspace is separate from my code workspace (with the sibling cnf folder). When I imported everything in, it just worked. Not sure why it didn't work originally, but I'm noticing the I have to sometimes restart Eclipse for changes in the repository to be picked up. I'm using the standard repos that come with Bndtools 2.3 (local, release, bndtools hub and build. I also added another file repo (called OldDeps) while I try to move things over to using Bndtools completely.

If I drag and drop a bundle into the local repo (aQute.bnd.deployer.repository.LocalIndexedRepo), it shows up and looks to be accepted, but then when I have a dependency on that bundle, sometimes it is not found by Bndtools as a build or runtime dependency. If I restart Eclipse, it looks to pick it up. I've since restarted, so I don't remember the exact error message, but it is something like "bundle not found".

derheld42

unread,
Jun 5, 2014, 2:48:01 AM6/5/14
to bndtool...@googlegroups.com
Dave -- the Bndtools menu -> Refresh repos causes repository indexes to be recreated/redownloadedd. This may help fix an issue where it seems like a repo isn't seeing something that you've added.

I have seen a case where sometimes the bnd bundle path isn't reevaluated even when a different repo artifact becomes available, when it should be. I have a fix for this that hasn't made it into the mainline yet. The workaround for this case is to do the refresh repos (to get the indexes up to date), then fake a change to the bnd.bnd file to cause bndtools to reevaluate the buildpath for the project.

Carter

Peter Kriens

unread,
Jun 7, 2014, 12:33:15 PM6/7/14
to bndtool...@googlegroups.com
Good to hear you got a fix for this, it is one of the most annoying aspects currently that you need to kick the bnd.bnd file  (sometimes it also helps to refresh the Bnd container). Looking forward to see this fix.

Kind regards,

Peter Kriens

Reply all
Reply to author
Forward
0 new messages