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 > > > >
