Improving Maven-Repositories

23 views
Skip to first unread message

Marc Schlegel

unread,
Jul 17, 2017, 5:18:47 AM7/17/17
to bndtools-users
Hello everyone

I was currently updating one of my Bnd workspaces which used the MavenBndRepository to the BndPomRepository. This was motivated by the following reasons
  • I can use placeholders for versions, which is very convenient for projects which release all artifacts with the same version (e.g. CXF)
  • the POM format is widely known (besides being verbose)
  • BndPomRepository pulls in transitive dependencies so I don't have to specify to much (we get to that point later)
Having ported most of the dependencies is my workspace I start seeing several problems
  • lots of duplicate artifacts because the ones pulled in transitively provide no OSGi-metadata, so I have to add some wrapped dependency
  • non-osgi-artifacts in my repository
I knew I will have some trouble with transitive dependencies when I decided to go for the BndPomRepository but I did not expect it to be such a pita. I was just hoping I dont have to specify as much dependencies because my MavenBndRepository file has 200+ entries (I do some testing there with jax-ws, jax-rs, jsf which are just big ball of muds)


Enough whining, I would like to discuss some ideas.

MavenBndRepository

Adding the possibility to specify placeholders, for example like Gradle does

ext {
    versionScala = '2.12.1'
}

subprojects {
    dependencies {
        compile group:'org.scala-lang', name:'scala-library', version: versionScala
  }
...
}

BndPomRepository

Filter artifacts without OSGi-metadata.

Not sure if Bnd already has this information after downloading an artifact, but if it does, the Repositories View could provide a filter which only shows valid OSGi bundles. This filter could also be applied to the buildpath-selection in the bnd-editor.
Personally I would disable all non-osgi-artifacts, so they dont pollute the repo but I guess there are some use-cases where you would need those (wrapping).



Thoughts?
regards
Marc
Reply all
Reply to author
Forward
0 new messages