Hi Pierre This sounds like a great plan.
Regarding generation of a POM: Is this needed for Maven Central deployment ? You mentioned the repository, this brings me to an idea I’ll start discussing in a separate thread. Regards Felix > Am 08.02.2015 um 20:19 schrieb Pierre De Rop <[email protected]>: > > Hi Felix, David; > > I confirm that the upcoming Dependency Manager 4.0 is now fully based on > bndtools and gradle, and we are not using maven anymore. I hope that we'll > (try to) make a release soon. > > Now, regarding the SCR project, it could be possible to switch to bndtools > and gradle, but that will require some work. > > If there is a general consensus on doing that move, I could then create a > Jira issue, and attach to it an initial patch. We could then continue to > discuss on the Jira issue, based on the initial patch. > But before that, I first have to do my best to bring to life the new DM4 > release, and we'll then benefit from the bndtools/gradle based DM release > to see what could be reused for SCR. > > I imagine that the work to do would consist in the following: > > - create a bndtools project for SCR, and activate semantic versioning using > our Apache Felix OBR repository > Something like: > > aQute.bnd.deployer.repository.FixedIndexRepo; name=Apache Felix Obr; > locations=http://felix.apache.org/obr/releases.xml > -baseline: * > -baselinerepo: Apache Felix Obr > > - adapt the tests, based of bndtools. We could even gradually change the > integration tests in order to generate the test components xml descriptors > using DS annotations, instead of doing that manually. > - create a release gradle script. That script would do the following: > > * reuse the Apache rat gradle script to check correct license file headers. > * generate a local staging repository, which would contain: > - the scr binary jar (org.apache.felix.scr.jar) > - the bndtools scr source project (org.apache.felix.scr-src.zip) > - the bndtols binary dependencies (org.apache.felix.scr-deps.zip) > > * sign the local repository, by simply using gpg > * generate a pom (could be done by dynamically inspecting bnd dependencies > from gradle, using the aQute.bnd.build.Project library) > * use the same kind of gradle scripts from [3] in order to upload the local > staging repository to our nexus repository. > > cheers; > /Pierre > > [1] http://www.apache.org/dev/release.html > [2] http://books.sonatype.com/nexus-book/reference/gradle.html > [3] > https://github.com/sonatype/nexus-book-examples/tree/master/gradle/simple-project-staging > > > On Sat, Feb 7, 2015 at 5:01 AM, David Jencks <[email protected] >> wrote: > >> Ok, it seems like now all the changes I've made for the last year + are >> getting discussed which is good :-) >> >> I'd like to propose that instead of re-maven-ifying ds we >> gradle-bndtools-ize it instead and drop maven entirely from this >> sub-project. I haven't had time to experiment with this conversion but >> IIUC Pierre has been trying it out in his dependency manager sandbox >> project. Unfortunately I haven't even had time to investigate that. Could >> anyone comment on it? >> >> Based on the speed of the bnd and osgi ct builds I would suspect that it >> would cut the ds build time by about 75%. However I have no concrete >> evidence to support this. >> >> thanks >> david jencks >> >> On Feb 6, 2015, at 3:42 AM, Felix Meschberger <[email protected]> wrote: >> >>> Hi >>> >>> With FELIX-4537 [1] the bundle plugin configuration was moved out into a >> .bnd file. >>> >>> While the format of either pom.xml or .bnd is debatable I think we >> should be having a discussion around this. For now we always had all bundle >> plugin configuration in the pom.xml and I see a clear advantage to that: >> All configuration for the bundle generation is in one place. >>> >>> Apart from this discussion, I think we should switch to using >> package-info.java files with @Version annotations to have the package >> version close to the code it describes. >>> >>> Also, the .bnd file is not really properly set up, unfortunately: >>> >>> * It hard codes many of the configurations of the POM file. If we stick >> with the .bnd these values should referenced with variables — if not >> possible, I fear that would be another argument against the .bnd file… >>> >>> * The bundle must import all exports, this is particularly important >> for the util.function and util.promise packages. >>> >>> I have no hard feelings about whether we keep the .bnd or not. My >> personal impression is just that having two files to configure things makes >> it harder to maintain and bears the danger of duplication of information >> (e.g. the bundle version). So I have slight preference, if you will :-) >>> >>> Regards >>> Felix >>> >>> [1] https://issues.apache.org/jira/browse/FELIX-4537 >>> >> >>
