Hi Felix,
On Mon, Feb 9, 2015 at 9:33 AM, Felix Meschberger <[email protected]> wrote: > Hi Pierre > > This sounds like a great plan. > > Regarding generation of a POM: Is this needed for Maven Central deployment > ? > Good question, actually for now I don't know and I have not yet tested the Nexus gradle sample from [1]. My understanding is that if you want to deploy to maven central, then you have to publish your staging release to https://repository.apache.org. And in the Nexus gradle sample from [1], which shows a gradle example on how to publish a staging release to a nexus repository, then it looks like the sample is generating a pom.xml. So I guess that at least you have to do this in order to provide the maven coordinates. Now, if this pom is really necessary, then one easy solution is to simply deduce the maven coordinates from the bundle symbolic name. But, then comes the question: do we also need to generate the dependencies in the pom.xml, and and can we deduce those dependencies from the -buildpath in the bnd.bnd file ? I would be happy if someone else could comment on this ? [1] https://github.com/sonatype/nexus-book-examples/blob/master/gradle/simple-project-staging/build.gradle cheers; /Pierre > > 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 > >>> > >> > >> > >
