commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry
Date Tue, 06 Jun 2017 18:11:45 GMT

> Am 06.06.2017 um 14:00 schrieb Rob Tompkins <chtompki@gmail.com>:
> 
> 
> 
>> On Jun 6, 2017, at 7:48 AM, Benedikt Ritter <britter@apache.org> wrote:
>> 
>> Hi Rob,
>> 
>>> Am 05.06.2017 um 15:50 schrieb Rob Tompkins <chtompki@gmail.com>:
>>> 
>>> 
>>>> On Jun 5, 2017, at 4:34 AM, Benedikt Ritter <britter@apache.org> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>>> Am 03.06.2017 um 18:54 schrieb Rob Tompkins <chtompki@gmail.com <mailto:chtompki@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 <chtompki@gmail.com>
wrote:
>>>>>> 
>>>>>> 
>>>>>>> On May 24, 2017, at 11:11 AM, Stephen Colebourne <scolebourne@joda.org>
wrote:
>>>>>>> 
>>>>>>> On 24 May 2017 at 15:55, Rob Tompkins <chtompki@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-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:dev-unsubscribe@commons.apache.org>
>>>>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>
>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:dev-unsubscribe@commons.apache.org>
>>>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:dev-unsubscribe@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:dev-unsubscribe@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message