Support for Import-Package deps?

[r-oldenburg]

Hi there,

this is a great lib and even greater together with wuff as a new build tooling.
Very promising. In my current tests I stumbled across Import-Package dependencies between (Target-Platform)-Bundles.

Unpuzzle currently only create poms with "Require-Bundle" dependencies, correct?
I am sure unpuzzle will be far more usable if Import-Package would also be supported. I would even be willing to help with the implementation.

Regards and thumbs up for your already existing work!

[stempler]

I've started with an implementation of this feature here. The basic functionality works, what's missing (at least for my use case) is tools for identifying and handling conflicts (e.g. when a package is provided by multiple bundles and only one should be used as dependency).

How are the dependencies determined? Rather simple - an index is built over all exported packages of the bundles, which is then used to resolve candidates providing imported packages. This is based on the general assumption, that whatever you throw unpuzzle at is more or less self-contained, only dependencies in the configured sources can be found.

Would be great if you can test it with your projects that rely on Import-Package. Any feedback is welcome, especially any hints on what you think needs to be done for this to make it into a pull request.

[stempler]

@akhikhl
@r-oldenburg

Did a few updates and the current implementation does everything I need so far:

• Dependencies based on Import-Package
• Reports on packages that were not found and cases where multiple bundles provide the same package
• Deal with duplicate bundles (different name but same library)
• Put artifacts in different groups
• Delegate dependencies to existing Maven artifacts on jcenter/MavenCentral/other repositories instead of installing bundles (some configuration needed to do that) and verify if these actually exist in a repository

It's roughly documented in the README. A project using it can be found here if you are interested in an example.

One thing I am unsure about is the handling of localization artifacts in respect to the artifact customization (delegating / changing group, name or version). I did not handle them yet at all in respect to that, mainly because I don't have any in my project. That's probably something to take care of to complete this.

[r-oldenburg]

Hi Simon,
sorry to say, but in the meantime I switched back to tycho as there is also possibilities for feature inclusion in products and p2 sites, etc...
Currently my own project is very consuming, so ... sorry. At the moment I cannot assist.

[stempler]

@r-oldenburg No problem, I just thought if you had a use case that would be a good test.
My own use case is probably a bit different than your original one. I also build my application with Tycho - now I use unpuzzle to make bundles from that application available as Maven dependencies for use in non-OSGi environments.

[guai]

Hi guys.
@stempler, I can test it, this is exactly what I need. I need to extract a subtree of dependencies starting from some list of bundles from my local eclipse installation. Tried to do it myself first by hand, than with simple script but didn't succeeded, this task appeared to be more complex then I thought. All of this versions, ranges, bundle and packages dependencies...
Any manual, how to use this new functionality?

[stempler]

Hi @guai,

if you want to set it up for local testing that should be fairly easy:

1. Clone the fork to your local machine
2. Build and install into your local Maven repository with gradlew install
3. Setup your unpuzzle-project like this (Important to use snapshot version and mavenLocal as first entry):

buildscript {
  repositories {
    mavenLocal()
    jcenter()
  }

  dependencies {
    classpath 'org.akhikhl.unpuzzle:unpuzzle-plugin:0.0.23-SNAPSHOT'
  }
}

apply plugin: 'org.akhikhl.unpuzzle'

...

See also the project where I am using it as an example.

There is no need to provide any specific configuration to use the Import-Package based dependencies, just use unpuzzle like usual.
You should take a look at the README in the section Package based dependencies for more information.
New configuration options are all those added in the artifacts section in the configuration example in the README. They are only necessary if you want to influence how dependencies are mapped to Maven artifacts. See the README for example usage (section Configuration DSL).

[guai]

Not great really. Some bundles become imported into maven with their full versions with build number. But other bundles export them with their short version like 1.2.3 or even 1.2 and therefore maven then cannot collect them all.
Not sure if that can be overcame. Maybe unpuzzle should collect all the paths on which we reached this bundles.
I've returned to my custom script. It can now detect if some list of bundles can be resolved on provided set of files. If it works right of course. Checked with karaf after that - seems fine.
My global goal is to extract one single feature from eclipse and load it into netbeans, and it still can't start even after I've checked them with my script :(

[stempler]

@guai I'm not sure if I get correctly what your problem is. You just want different version numbers for the Maven artifacts generated from your bundles?

[guai]

@stempler, I'm not sure if maven can resolve version ranges in local repo. If it can then maybe version ranges should be added to metainfo, or else I see no way for maven to resolve dependencies correctly other than collect all the versions from all the paths to that particular bundle

[stempler]

@guai I'm not sure where version ranges come into the picture here. My understanding is that unpuzzle generates Maven artifacts from each bundle, with the version defined in the bundle. The dependencies between the Maven artifacts are determined based in Require-Bundle and Import-Package, but the dependency version they point to is the corresponding Maven artifact version, which is a concrete version of an existing artifact (because it was created by unpuzzle).

Sorry if I ask the question again, but I could not determine if your comment was a yes or a no:
Is your problem that you want different version numbers for the Maven artifacts generated from your bundles?

If so, you can achieve that, given that it is possible to derive the desired version numbers from the bundle version numbers, e.g. with something like this in the configuration:

unpuzzle {
  ...

  artifacts {
    all {
      def adaptVersion = { v ->
        // TODO adapt version, e.g. strip qualifier
        v
      }
      version = adaptVersion(version)
    }
  }
}

[guai]

@stempler, I think the problem is not in versions but in Eclipse-BundleShape: dir dependencies, everything else seems to be ok.

[stempler]

@guai I was wondering how unpuzzle handles creating artifacts from those (don't have those in my use cases), but if creating the artifacts works, the rest should work properly as well. Determining the dependencies is done the same way, just that the information comes from the MANIFEST.MF file in the directory, not from inside a Jar.

[guai]

@stempler, I've rechecked once again, there are actually version resolution issues in unpuzzle. You can reproduce it in eclipse mars with EMF Examples installed, try to resolve compile group: 'eclipse-mars', name: 'org.eclipse.emf.examples.library', version: '2.6.0.v20150806-0404' dependencies. There will be two version candidates of org.eclipse.emf.common and two of org.eclipse.emf.ecore. And unpuzzle resolves to wrong ones. My other issues seems not to be connected to unpuzzle.