> On May 23, 2017, at 7:26 PM, Benedikt Ritter <brit...@apache.org> wrote: > > Hi, > >> Am 22.05.2017 um 09:19 schrieb sebb <seb...@gmail.com>: >> >> On 22 May 2017 at 13:14, Rob Tompkins <chtom...@gmail.com >> <mailto:chtom...@gmail.com>> wrote: >>> >>>> On May 22, 2017, at 8:10 AM, Stephen Colebourne <scolebou...@joda.org> >>>> wrote: >>>> >>>> On 22 May 2017 at 12:51, Rob Tompkins <chtom...@gmail.com> wrote: >>>>> You could, in the parent, declare in the properties section beside the >>>>> declaration of “commons.osgi.symbolicName”, another property pointing to >>>>> that as >>>>> >>>>> <commons.automatic-module-name>${commons.osgi.symbolicName}</commons.automatic-module-name> >>>>> >>>>> and then allow people to override that in their local poms. That way you >>>>> wouldn’t get the blank lines. >>>> >>>> True, but I want to ensure that we only add it to components where it >>>> is valid (and we have manually checked it is valid). Which I think >>>> requires us to do it in each subproject. >>> >>> We might be able to contrive something using antrun after compile that >>> predicates on the property being populated, but that feels extra hacky. >> >> It's possible to have a profile depend on the presence of a file. >> >> So just create an empty file when the property is available for use. > > Please no more profile activation based on files being present. This is just > confusing and a dirty hack IMHO.
We should simply add that entry, "commons.automatic-module-name," to every component pom’s properties section now, and then when the next parent migration happens, the changes will express naturally. It might be worth adding a comment on the property in each pom? I’d be happy to do that between now and Monday. Thoughts? > >> >>>> Stephen >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> <mailto:dev-unsubscr...@commons.apache.org> >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> <mailto:dev-h...@commons.apache.org> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> <mailto:dev-unsubscr...@commons.apache.org> >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> <mailto:dev-h...@commons.apache.org> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> <mailto:dev-unsubscr...@commons.apache.org> >> For additional commands, e-mail: dev-h...@commons.apache.org >> <mailto:dev-h...@commons.apache.org> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
