Clean up poms, simplify parentage, eliminate project pom so dependencies...

[codefromthecrypt]

... are locked to jclouds project

[codefromthecrypt]

p.s. I added a commit to clarify why groupIds are specified in the lab poms and what should happen when they graduate.

[codefromthecrypt]

@iocanel if you don't mind, take a look at the latest commits and let me know if they are ok. I'd prefer to progress the osgi stuff rather than leave it broken, but I'd also rather release rc.3 then get blocked on old stuff. Lemme know if anything needs to change. I'm out to lunch for a bit.

[demobox]

good point. I'll remove and update the commit

I'll raise a PR to make the same change back in master. Bon appetit!

[codefromthecrypt]

ok. current commit is up to date with latest comments. any last words?

[codefromthecrypt]

punting this as I'm out of time today.

[demobox]

@iocanel Does this look OK to you from the OSGi perspective?

[iocanel]

@demobox: As I commented above, the maven-bundle-plugin will translate * imports to package imports that are referred from the source. Of course not all required packages are referenced by the source.

For example, a class loaded by Class.forName will not be tracked by the maven bundle plugin, so it needs to be added explicitly to the package imports. Also, in some cases a library (e.g. guice) might make use of Thread Context ClassLoader to load classes. So even if the bundle itself is not using the classes, it still needs visibility to them.

From what I remember some of the compute providers/apis I tested on OSGi had a runtime dependency on org.jclouds.rest.intrnal and org.jclouds.compute.internal and so they have been explicitly added to the imports. I am not sure if this is still the case or if it applies to ALL compute providers/apis.

So, I'm not sure its a great idea to remove them. Given the low adoption of the lab projects its no biggie.

[demobox]

So, I'm not sure its a great idea to remove them. Given the low adoption of the lab projects its no biggie.

@adriancole Try and see or leave them and carry out a "proper" cleanup effort where we test these later..?

[codefromthecrypt]

Unless someone is willing to make test cases for our

On Saturday, April 6, 2013, Andrew Phillips wrote:

So, I'm not sure its a great idea to remove them. Given the low adoption of the lab projects its no biggie.

@adriancole https://github.com/adriancole Try and see or leave them and carry out a "proper" cleanup effort where we test these later..?

— Reply to this email directly or view it on GitHubhttps://github.com/jclouds/jclouds-labs/pull/27#issuecomment-15996328 .

[jclouds]

Unless someone is willing to make test cases for our osgi stanzas without a massive pax project, I recommend changes here until they are proven not to operate.

On Saturday, April 6, 2013, Adrian Cole wrote:

Unless someone is willing to make test cases for our

On Saturday, April 6, 2013, Andrew Phillips wrote:

So, I'm not sure its a great idea to remove them. Given the low adoption of the lab projects its no biggie.

@adriancole https://github.com/adriancole Try and see or leave them and carry out a "proper" cleanup effort where we test these later..?

— Reply to this email directly or view it on GitHub< https://github.com/jclouds/jclouds-labs/pull/27#issuecomment-15996328> .

— Reply to this email directly or view it on GitHubhttps://github.com/jclouds/jclouds-labs/pull/27#issuecomment-15997573 .

[codefromthecrypt]

I'm just going to close this as it wasted a lot of our time yesterday. The individual labs projects can fix and test their osgi config. In the mean time, closing this stops the bleeding of a prolonged theoretical discussion.

[codefromthecrypt]

the only universally desirable changes in this branch are currently in pull requests against 1.6.x. The new change wrt notes is in https://github.com/jclouds/jclouds-labs/pull/34