> On Jun 6, 2017, at 7:48 AM, Benedikt Ritter <brit...@apache.org> wrote:
>
> Hi Rob,
>
>> Am 05.06.2017 um 15:50 schrieb Rob Tompkins <chtom...@gmail.com>:
>>
>>
>>> On Jun 5, 2017, at 4:34 AM, Benedikt Ritter <brit...@apache.org> wrote:
>>>
>>> Hi,
>>>
>>>> Am 03.06.2017 um 18:54 schrieb Rob Tompkins <chtom...@gmail.com
>>>> <mailto:chtom...@gmail.com>>:
>>>>
>>>> This should be done now with the entries being “commons.module.name”
>>>
>>> I’d recommend using dashes in the second part of the name, since my
>>> understanding of points is to declare name spaces. So I’d suggest to use
>>> commons.automatic-module-name and not commons.automatic.module.name.
>>
>> I’m ok with re-namespacing. I’ll try to get to that after I push out the
>> file upload 1.3.3 release.
>
> Please make sure that this actually works and generates the desired MANIFEST
> entry. As I’ve said in my comment to one of the commits, I don’t understand
> who this is supposed to work without changing and releasing parent pom.
I was just trying to get ahead of the implied release of the parent Pom. I
agree that they do nothing until the consuming component up versions into the
new parent. Maybe that's too much pre-usefulness work?
>
> Cheers,
> Benedikt
>
>>
>> -Rob
>>
>>>
>>> Benedikt
>>>
>>>>
>>>> Cheers,
>>>> -Rob
>>>>
>>>>> On May 24, 2017, at 11:31 AM, Rob Tompkins <chtom...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>> On May 24, 2017, at 11:11 AM, Stephen Colebourne <scolebou...@joda.org>
>>>>>> wrote:
>>>>>>
>>>>>> On 24 May 2017 at 15:55, Rob Tompkins <chtom...@gmail.com> wrote:
>>>>>>> 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.
>>>>>>
>>>>>> As I said upthread, there is an argument to only add it to components
>>>>>> once they have been checked to see if they are valid for use as a
>>>>>> module.
>>>>>
>>>>> Right.
>>>>>
>>>>>>
>>>>>> That said, I'm willing to go with it as an approach because AFAICT if
>>>>>> a component isn't a good modular citizen, the Automatic-Module-Name
>>>>>> MANIFEST entry won't do much harm.
>>>>>
>>>>> Yes.
>>>>>
>>>>>>
>>>>>> Of course, strictly speaking we don't know if Automatic-Module-Name
>>>>>> will be part of the final JDK 9, as private discussions are currently
>>>>>> ongoing between the key players. Since it will cause no harm if
>>>>>> wrongly present, I'm OK with this too,
>>>>>>
>>>>>> If you are going to do it, I'd suggest using ${commons.module-name},
>>>>>
>>>>> Makes sense to me there. I’m not the best at coming up with names. :-)
>>>>>
>>>>>> as you will be adding the official module name for the component. That
>>>>>> it is only used as the automatic module name right now is a detail.
>>>>>
>>>>> I will start chipping away at this tomorrow or Friday, assuming that
>>>>> there aren’t any objections between now and then.
>>>>>
>>>>> -Rob
>>>>>
>>>>>>
>>>>>> Stephen
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
