IllegalArgumentException when adding bndtools osgi nature to an existing project

[mvanwely]

Errors occurred during the build. Errors running builder 'Bnd OSGi Builder' on project 'workflow'. java.lang.IllegalArgumentException: No Workspace found from: C:\Depot\ANG\prod\framework

My workspace was created under C:\Docs'nSettings\ however my repository is downloaded to C:\Depot. Within my eclipse workspace I've imported existing projects which live under C:\Depot. As a result bndtools builder fails to run because it cannot find the workspace.

[njbartlett]

Unfortunately bndtools currently cannot support projects that are not located in the Eclipse workspace. Fixing this will require an enhancement to bnd.

[mvanwely]

Is this enhancement planned for development in the near future? Is it something I could tackle with a couple days development?

[njbartlett]

Well, as I said it would be an enhancement to Bnd rather than Bndtools. I don't own Bnd so it would be best to raise this bug on Bnd's bugtracker at http://github.com/bnd/bnd

However just as an indication, the problem is that Bnd assumes the cnf project -- and indeed all of the project directories -- are located within the same parent directory. If you're going to start distributing projects across the filesystem then you need to create some kind of map of the workspace that tells it where the actual directories are. This would probably need to be passed into Bnd as a command line option (because it doesn't know yet where its configuration lives!)

To be honest, I think Peter will be quite reluctant to implement any functionality like this. But it's best to discuss with him.

[magnet]

This issue has beaten me as well.

I'll add this comment here and open the issue in Bnd's tracker.

When using EGit, the location of the project is not likely to be the Eclipse workspace, because that would imply the workspace is itself the git repository, or that there is one git repository per bundle (which would be nice if there was support for Git submodules in EGit).

With that in mind, when we require the cnf/ directory in the parent directory of the bundle, the parent directory (in a multi-bundle Git repository) is within the Git repository. And I'd rather avoid putting the cnf/ directory in a Git repository, and even more to copy it in all my Git repositories with bundles using Bnd / Bnd Tools.

Our current workaround is to copy the cnf/ directory on windows, do a symlink on *nix and to add it to git ignore, but it would be nice to be able to pass a Java property (for instance) pointing to the cnf directory. Bnd Tools could by default provide $eclipse_workspace/cnf to Bnd.

[pkriens]

bnd is already prepared to handle the cnf directory in different places (though there might be some places where I am cheating). It would be quite easy in bndtools to support this model. However, no such luck for offline tools like ant. This will mean to reverting to environment variables and handling of absolute path names. Keeping the eclipse build synchronized then with the offline build will become painful. Absolute path names are evil, they heavily complicate offline builds.

It is a key goal for bnd to provide the identical results in Eclipse, local offline build, and remove offline build in bamboo or hudson. Making the cnf directory go anywhere is going to be very error prone.

A solution could be to allow bnd to recognize its own link files (due to the absence of link files in WIndows). That is, instead of having a cnf directory you could make it a file that contains the relative path to the real cnf directory? Would that work?

[magnet]

@Peter that would definitely improve the situation compared to our current workaround.

[pkriens]

After some thinking I also have some other approach that would better fit my requirements. I could look upwards in the directory tree until I find a cnf directory with a build.bnd in there, would that work for you?

Alternatively, you could also have a cnf directory where the build.bnd includes another central file? Did you try that?

[magnet]

Looking up in directories wouldn't work in my case. For instance, BndTools wants the cnf directory in the Eclipse workspace (say ~/workspace) so if I don't clone my Git repositories within the workspace (which seems like a bad idea), the cnf directory won't be in an ancestor directory.

The include solution would work, but can it use system properties like $user.home ?

The best way would seem to mix the two: have the cnf workspace in my home directory (~/cnf) so it's likely to be "above" my projects, and have BndTools' cnf directory (~/worskspace/cnf/build.bnd) include ~/cnf/build.bnd

[pkriens]

Why is cloning your projects in the workspace a bad idea? In the OSGi (>130 projects, >1200 bundles) in a single git repository, works extremely well. Despite the size, git is incredibly fast. Having a single repo makes life considerably easier. All people working on the OSGi specs, reference impls, or test suites just clone the repo and they have a consistent Eclipse workspace. If projects are added or removed, people all get updated. With a per-project-git everybody needs to handle (and thus know) the whole space.

However, even if you do git-per-project, cloning them in a workspace seems very logical? Why do you want them somewhere else?

The problem with home directories is that they share all the bad habits of hard coded path names. You create a dependency that is different for each system you run your build on. The only thing I know that works reliably is relative paths ...

I am not avoiding work, I am just trying to see if we can find a solution that works for you without introducing a potential for build errors that I've worked so hard in bnd to prevent.

[magnet]

Some reasons why I don't find the one-git-repo-for-all-bundles inside the Eclipse workspace is that:

• I use several workspaces
• the same project could be in several workspaces, but on the same Git local repository. Making workspaces point to each other is painful
• I generally try to let Eclipse manage its workspace directory because of the black magic some plugins do on it, that may affect subdirectories (including Git repos)

The ideal solution would be to have one Git repository per bundle, and if needed (as in some of our projects, because they are dependent for a full build), aggregating them using Git submodules. Unfortunately, JGit/EGit do not support submodules properly yet. So I could have the bundle repo cloned into my workspace, but I could not import the parent Git repository in Eclipse.

The reason I want multi-bundle repositories is that we often have a multi-module Maven POM which triggers builds for the submodules (ie, the bundles) and deploys/packages everything nicely in the end. Our clients want to build the product themselves and we can't tell them to clone 100 repositories / bundle, and package/install them in a given order... Maven multimodules POMs handle this nicely.

Also, don't try too much for me ;). I'm mostly posting here to say that I've come across this problem and it could put off newcomers.

[njbartlett]

I think the simplest way to support this -- if it's going to be supported at all -- would be to create a command line option or system property that tells Bnd where the cnf directory is.

In Bndtools I can pass this in when calling Bnd, and in Ant it could be supported via the task attributes.

[pkriens]

Can we first try out how it works with a using an include in cnf/build.bnd? The repo is a parameter set with the plugins so it should be easy to point it to somewhere else?

If that works, each project needs a cnf directory but it will only be a small boilerplate.

[mvanwely]

Thanks for considering a change for this issue. Anything that allows an external Eclipse projects to be managed by bnd and bndtool in would help us. I've been comparing other OSGi tools and runtimes with bias towards bnd however this issue is gating me from adopting it as it would require a large number of developers to make a number of changes to their dev environments. Let me know if I can help in any way.

[pkriens]

In the latest release of bnd (1.37.0) I've added a little experiment. If the cnf directory in the parent directory of the project directory is a text file, it is read and used as an indirection to another workspace directory. This process can be repeated.

uber/
    cnf/
         build.bnd
    group/
        my.project.ws/
             .git/
                  ...
              cnf   -> "../.."
              my.project/
                 bnd.bnd

This will make the my.project use the workspace cnf directory from the uber directory.

I've done some basic tests but have no idea how this will work in practice ... so please try and provide feedback.