> On Apr 9, 2019, at 1:11 PM, sebb <seb...@gmail.com> wrote: > > On Tue, 9 Apr 2019 at 17:06, Rob Tompkins <chtom...@gmail.com > <mailto:chtom...@gmail.com>> wrote: >> >> >> >>> On Apr 9, 2019, at 11:57 AM, sebb <seb...@gmail.com> wrote: >>> >>> On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann <jochen.wiedm...@gmail.com> >>> wrote: >>>> >>>> On Tue, Apr 9, 2019 at 3:51 PM sebb <seb...@gmail.com> wrote: >>>> >>>>> We already have a process for ensuring that Maven coords and package >>>>> names are changed when API breaks. >>>>> Do we really want to have yet another name that has to be maintained? >>>> >>>> What's the alternative? >>> >>> As I already wrote, use the gid + aid to generate a suitable name. >> >> We already do this for OSGI here’s the [lang] example: >> https://github.com/apache/commons-lang/blob/master/pom.xml#L581 >> <https://github.com/apache/commons-lang/blob/master/pom.xml#L581> >> <https://github.com/apache/commons-lang/blob/master/pom.xml#L581 >> <https://github.com/apache/commons-lang/blob/master/pom.xml#L581>> combined >> with https://github.com/apache/commons-parent/blob/master/pom.xml#L1743 >> <https://github.com/apache/commons-parent/blob/master/pom.xml#L1743> >> <https://github.com/apache/commons-parent/blob/master/pom.xml#L1743 >> <https://github.com/apache/commons-parent/blob/master/pom.xml#L1743>> > > I think 'org.apache.commons' should probably be: ${project.groupId} in CP. > Otherwise projects that are still on a different groupId may get a > duplicate conflicting name if they move to o.a.c as the groupId.
I’m a +1 to that idea, but it is worth noting that we do have antiquated groupId’s that look like “commons-<packageId>” in the project. They would have to be changed at their next release. -Rob > >> >> >> >>> >>>> >>>>> Being able to define the module name independently is all very well, >>>>> but it does not solve the problem of ensuring that the module name is >>>>> correct, and remains correct when code is updated. >>>> >>>> That is, IMO, a problem, which can (and will) be solved later. >>> >>> Which may involve reverting the work already done. >>> >>>> Jochen >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: 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>
