stempler / bnd-platform

Build OSGi bundles and Eclipse Update Sites from existing JARs, e.g. from Maven repositories (Plugin for Gradle)
Apache License 2.0
79 stars 30 forks source link

Make it possible to publish platform bundles with maven-publish plugin #15

Closed fuemf closed 9 months ago

fuemf commented 7 years ago

Hi, I use the bnd-platform plugin to create bundles from non bundle dependencies. My idea is to publish these "bundleized" artifacts to our maven repository, so they can be used in other projects. However this is quite difficult as I found no way to know the targetFileName at configuration time. My build so far:

apply plugin: 'maven-publish'
apply plugin: 'org.standardout.bnd-platform'

platform {
    bundle(group: 'org.apache.lucene', name: 'lucene-core', version: '4.10.4') {
        bnd {
            instruction 'Export-Package', "org.apache.lucene.*"
        }
    }
}

publishToMavenLocal.dependsOn bundles
publishing {
    publications {
        // is there a better way to get the plattform bundles?
        configurations.platform.dependencies.each { dep ->
            create("mavenJava${dep.name}", MavenPublication){
                groupId dep.group
                artifactId dep.name
                version "${dep.version}.bnd"

                // how to get the transformed artifact file here ?
            }
        }
    }
}
fuemf commented 7 years ago

BTW, I found a workaround to my problem, but it is not the most elegant. It is possible to define the actual artifact file on execution time only.

I use this task to do it

task configurePublications(dependsOn: 'bundles') <<  {
    project.platform.artifacts.values().each { bundleArt ->
        if (!bundleArt.isSource() && bundleArt instanceof org.standardout.gradle.plugin.platform.internal.ResolvedBundleArtifact) {
            publishing.publications."mavenJava${bundleArt.name}".artifact("${buildDir}/plugins/${bundleArt.targetFileName}")
        }
    }
}
ascertrobw commented 7 years ago

Interesting - had the same issue, but came to different workaround our side

subprojects {
...
    publishing {
        publications {
            bundle(MavenPublication) {
                //TODO - bit fugly. Wonder if there's better way to define the artifact produced by BND!
                artifact file("$buildDir/plugins/$project.name" + "_" + "$project.version" + ".jar")
                //TODO - what if a subproj produces multiple artifacts? Poss not that advisable, but could happen
            }
        }
    }  
...
 }

The above relies on the fact that all our bundling subbprojects set a version = in their build.gradle, and that only one BND artifact is produced by each subproject of a consistent name. Works for our model, but possibly not other peoples.

I'm a complete Gradle newbie, so I'm sure yours is tidier!

sradi commented 5 years ago

Hi,

I would also like to combine Maven Publishing with the result of the bundles task. @fuemf 's nice workaround doesn't work for me, as I would like to publish all artifacts, including their transitive dependenies. These are unknown during configuration time.

Maybe it's possible to accomplish this, if the bnd-platform plugin uses Lazy Configuration (https://docs.gradle.org/current/userguide/lazy_configuration.html)?!

stempler commented 5 years ago

Hi,

to create Maven artifacts my approach is to apply my unpuzzle fork to the created update site. It will analyse the dependencies to turn them into into proper Maven dependencies for use also in non-OSGi applications. Not sure if that's also a use case for you, or if you only need artifacts of OSGi bundles w/o proper Maven dependencies.

You can find an example where this is used in the hale studio project build. It uses the built update site (in that case using Maven Tycho). In this example there is also some additional logic present to replace bundles for third party libraries by their original Maven artifacts (which are already present in Maven Central or similar), as the use case here is to use the artifacts outside OSGi and we like to use the original dependencies there to avoid duplicates on the classpath.

Hope that helps

github-actions[bot] commented 10 months ago

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in two weeks if no further activity occurs. Thank you for your contributions.

github-actions[bot] commented 9 months ago

This issue has been automatically closed due to inactivity. If it is still valid, please post a comment.