Hi David > Am 07.02.2015 um 05:01 schrieb David Jencks <[email protected]>: > > Ok, it seems like now all the changes I've made for the last year + are > getting discussed which is good :-)
Sorry, for chiming in this late and having had your work virtually ignored … Really. > > 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. Now, that sounds like a good idea as well. At the end of the day, I think it really doesn’t matter whether we use a pure Maven build or a pure Gradle/BND build. The more important point is that it is „pure“ and even more important is that information is not replicated across multiple files. So, I am in favour of trying it out. Regards Felix > > 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 >> >
