Regarding Tooling

In my quest to find a better solution I stumbled on Gradle (http://www.gradle.org). It uses ANT and Ivy but without the XML. It knows about Maven and Ivy repos and it is open for extension.

Just my $.02

chris

The best code example I can think of is the code we wrote in dm Server to do resolver-driven provisioning. You can find the latest incarnation of this here: http://bit.ly/pJDOA

Regards,

Rob

Do you have pointers or links to get started on the Equinox offline resolver?

I want to start as a standalone Java app to explore. And later on, I may build a plug-in to integrate that with other build/installation toolings.

We haven't made a huge amount of progress on integrating the resolver into a build tool simply because the demand was not as great as we imagined. If you are looking for an offline OSGi resolver, you can use the Equinox resolver offline. Its actually pretty easy to get going with the resolver in Equinox.

Rob

Before it is avaiable, is this function available as part of spring dm, Felix, or Equinox ? That can be accessed as a Java API or a standalone tool?

Stanley

If pom.xml is the only place where I declare my dependencies, it has to be possible to add SpringSource EBR to the Maven Indexes of m2eclipse. Otherwise I think adding dependency declarations by hand is too cumbersome. I thinke there is already a request for this in JIRA.

I see at least two much more fundamental problem areas which must be tackled prior to ever being able to have a satisfying set of tools for all of us:

1. Compatibility of dependency meta models

Before deciding whether we better store dependency meta data in OSGi manifests, pom.xml or ivy.xml it is necessary to understand the differences between their dependency meta models, see if there exists a one-to-one correspondence between all of them and if not, decide which meta model (not tooling) should be the standard dependency meta model for Java development in the future.

In OSGi alone the question if we think in packages (Import-Package) or in bundles (Require-Bundle) when it comes to dependencies is not yet answered. The question which approach to use cannot easily be answered because both have pros and cons. The pragmatic solution to combine both (Import-Bundle) by introducing a new header as done in dm Server is understandable, but it just blurs the two concepts without answering the underlying theoretical question, which concept is better (from a meta model point of view, not from a programmer's view, who wants to write as few lines as possible).

2. Bundle vendor chaos

We cannot solve organizational problems with technical solutions. If I could not register a domain and provide an authoritative DNS server, I could not guarantee that everybody who wants to see my website, can actually see my website. If we could not use globally unique IP addresses, not even the best algorithm could help us to establish an internet.

If I want to use commons-logging with OSGi and am spoilt for choice between tons of different bundles packaged by different vendors which basically provide the same functionality, I need not be surprised, when at some point I will run into dependency resolutions problems because two bundles I want to use have a different conception about resolving their dependency to commons-logging. Of course, at this point "Import-Package" seems to be the most robust and flexible solution to cope with that mess. But the mess is not removed, it's just covered a little.

We should not weaken the strictness of the dependency resolution mechanism by using a fuzzy notion like "package" (a package name is not yet a specification for which implementations are interchangeable). But we should increase the strictness by introducing authoritative bundle vendors/repositories. This is an organizational challenge, not a technical. We have a convention for package names so that packages are related to top level domains. If we use the same convention for bundle names, we could give every domain owner the possibility to define the authoritative repositories for bundles belonging to the respective domain.

org.apache could for example appoint the SpringSource Enterprise Bundle Repository as the authoritative repository for commons-logging. Or they provide their own repository, which is easily found by everyone who wants to use commons-logging by basically using the same mechanism as DNS. In such a world, "Require-Bundle" would not break things because everyone would use the same bundles.

I highly appreciate SpringSource's active and pragmatic approach, but would like to see even more interaction with the community before introducing non-standard concepts like "Import-Bundle" or by completely reimplementing tools for which a de facto standard exists because in a global perspective, this makes the Java world more complex again, eating up the improvements definitely made in a local perspective.

you are right. There are some Bundlor packages inside STS and we'll bundle BundlorEclipse with STS very timely. But – as Rob and Adrian – pointed out, BundlorEclipse will be available under the EPL-license as a separate installable set of Eclipse plugins. Stay tuned for more on the Bundlor Eclipse integration.

Regards,

Christian