Bundles listed in runbundles should not be considered in build order calculation

[njbartlett]

If a bundle is listed in -runbundles it appears to be considered in the build order calculations. This can result in a CircularDependencyException when in fact no circular dependency exists.

For example I have bundles A and B, where B has a compilation dependency on A. My launcher is defined on bundle A because it is my "main" bundle, and I add B to the -runbundles for A because I want to include B when running the application.

To do this "properly" I have to create another bundle project that I just use as a launcher. This seems a little heavyweight, and is further reason IMHO to have separate and multiple launcher scripts, rather than including all launch information in bnd.bnd.

[pkriens]

But A and B (belonging to the same project) should automatically be included runbundles? Why add them?

I am not sure I agree with you on the launch scripts. Though a general lanch feature is interesting the problem is that it becomes very hard to automate in the offline build. You then need to parameterize what launch script is required, increasing complexity.

I can see the use from the UI to explore and play, but I think we need to address this differently, the offline model is best as it is today I think. Maybe we need to introduce x.launch files that are actually bnd files. You can easily create a temporary Project on such a file, these launch files can then override -runbundles etc.

Another way is to make it easy to switch between launch configurations and save old configs in the same file. E.g. -runbundles-0. However, I think it is very important there is a primary launch configuration that is the choice during offline builds.

[njbartlett]

No, A and B are in separate projects.

An override-based model would work for me. Ideally the launch files would augment or merge with the -runbundles from the project rather than override entirely.

Even for the offline build you will need some way to address multiple platforms, e.g. selecting the platform-specific SWT fragment when launching an Eclipse RCP app.

[pkriens]

I think that platforms subtleties must be handled in -runpath/-runbundles with conditionals. And even better, with bundles that run on all platforms.

Anyway ... you propose to break the project build into two phases :-( Before we know it we have the maven 89 phases ... There clearly is a circular dependency between A and B but you want to treat a compile/build dependency different than a run/test dependency. It can be done but it will complexify a lot of things, among one thing the ant files.

[njbartlett]

I don't see this as a circular dependency. For compile/build, A has no dependency on B. But for running, you have a third entity -- the launch configuration -- which depends on both A and B, and all the other optional bundles you might want to include in the runtime.

I will probably adopt the launch file concept as you described. The offline run/test for A would continue to just run A plus its dependencies. These launch configuration files could really be created anywhere, and it would be helpful if there were a way to use bnd to launch these configurations from the command line, but it's not necessary to make this part of the main build.

[pkriens]

What you indicate is that the dependency is more detailed than bnd assumes. However, bnd was consciously made it simple because in other build systems that shall not be mentioned they created more and more details, resulting in over 80 different possibiltiies. Though this is more flexible, it usually ends up becoming highly complex so few can follow what's happening. Not so much for bnd itself, but mostly for any tool (like ant) that collaborates. So for bnd a project has a set of dependencies and for simplicity it does not discriminate between the subtleties between buildpath, testpath, dependson, and runpath. Not optimal, but awfully simple. And the work around is quite simple and clean.

So I do not disagree, but I fear the slippery slope ...

[njbartlett]

Closing this issue, because I have adopted the launch file approach (".bndrun" files).