> Am 06.06.2017 um 14:00 schrieb Rob Tompkins <chtom...@gmail.com>:
>
>
>
>> 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?
Since we haven’t agreed upon a property name (my proposal is
commons.automatic-module-name), I doubt that it may have been premature :-)
We still have that problem that I don’t know how to modify parent pom so that
the manifest entry is opt-in...
Regards,
Benedikt
>
>>
>> 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
>> <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>
