Bundlor maven integration and maven dependency attributes

Right now it doesn't look like bundlor (either in STS or the bundlor mavne plugin) will read the maven dependency versions and scope to augment the imports it will throw into the MANIFEST.MF. (Right?)

Does it make sense that if that information was available it would do so? Ideally it could grab version ranges and look at the dependency scope to see if the dependency was optional and modify the import in MANFEST.MF for things coming out of there to be of the version range and possibly optional.

I'm sure this would get very complicated if/when multiple dependencies might supply the same package, and I'm sure there are other issues I've not thought of yet in my 10 mins of dreaming.

But is this a viable story to enter into JIRA?

"As a developer using maven (in both STS and from the command line), I want Bundlor to tack on version ranges and the optional flag to my MANIFEST.MF package imports from the version ranges and scope supplied by the maven dependency from which the package comes."

Hey there Scott. I never want to discourage a user from opening a story, so all stories are viable for opening. It's good to have the record even if the story is discarded. I'll point you at a couple of existing issues that you might vote/comment on.

https://issuetracker.springsource.com/browse/BNDLR-198
https://issuetracker.springsource.com/browse/BNDLR-225

I will say however, that I'm not a huge fan of doing it :) The issue is this. Right now, Bundlor is completely offline. It doesn't require any of the classes it detects to be on the classpath to run. We've had a number of requests for this kind of functionality (verifying resolution against the collection of dependencies and more. Just check out the JIRA for more examples.) but it changes the nature of what Bundlor is.

My gut implementation of this features goes like this:

1. Enumerate the list of dependencies
2. Open each dependency and get it's manifest out
3. Find out the packages that are exported and the versions that they are exported at
4. Go back to POM and get a version range
4a. Bundlor enforces closed version ranges, most maven POMs do not
4b. POM version ranges are not compatible with OSGi version ranges
5. Ensure that the range exported in the dependency is actually within the range imported in the POM
6. Merge the package listing and version ranges associated with those packages (from the POM) into the template in memory

So, there are a couple of big stumbling blocks (4a, 4b) and it takes Bundlor towards an online model (also the multiple contributors problem that you mentioned earlier). So as I said, I'm not a huge fan. That being said, I'm a reasonable guy and I'm open to being convinced. Maven users make up a large bit of the Bundlor community and I want to make life easier for them.

So how would you solve problems 4a and 4b and is the added complexity of adding this feature going to be offset by a large enough group of users being able to benefit from it?

Thanks for the reply, and the detailed info, Ben. Can you be a little more explicit about the statement that "POM version ranges are not compatible with OSGi version ranges"?

It could very well be my inexperience with fringe cases, but I thought both supported the same format: [] for inclusive boundaries, () for exclusive boundaries, comma separating the version ranges, and for single versions there are no [] or ().

So if the maven dependency was "[1.0,2.0)" can't this be used directly in OSGi?

One thing I've noticed is that the EBR jars are all 3-point versions (x.y.z) even when their original, non-OSGi counterparts are not. Is that one of the incompatibilities you are referring to? If so, maybe bundlor could be strict here because it would perchance be hitting something that wasn't OSGi-ready anyway.

Having stated that, this would conflict with the [again possibly exception case] need to have JARs that are put into the bundle-classpath itself rather than being used as 3rd party dependencies, but I've not seen a way to automate this anyway either thru maven or STS (tho I could very well be missing that). So maybe Bundlor only does its magic here with the imports for stuff that has the maven scope "provided"?

BTW, since this post didn't generate a whole lot of participation, I'll assume I'm dealing with a fringe use case. I want to see if we can get the beginnings of a solid story here and I'll JIRA it, but then we can let it die or live based on community involvement.

Thanks,
Scott