Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Gary Gregory]

On May 18, 2017 12:09 PM, "Benedikt Ritter"  wrote:

Hi,

here is my proposal on how to get the Automatic-Module-Name entry into our
MANIFEST files. This change has to be made only in commons parent. This is
the change:

Index: pom.xml
===
--- pom.xml (revision 1795551)
+++ pom.xml (working copy)
@@ -601,6 +601,7 @@
   ${implementation.build}
   ${maven.compiler.source}
   ${maven.compiler.target}
+  ${commons.osgi.symbolicName}
 
   
 


For Commons Lang this will create:

   Automatic-Module-Name: org.apache.commons.lang3


WDYT?


Seems reasonable enough.

Gary

Benedikt
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Stephen Colebourne]

Is reusing ${commons.osgi.symbolicName} a good idea?
It seems to me that each project should have to opt-in to this
attribute, so I'd add a new ${commons.automatic.moduile.name}
variable.

One reason is that the attribute should only be added if the project
is suitable for use as a module (eg. no packages that clash with any
other module, doesn't force cycles in dependencies). I'm not convinced
that all commons projects are valid yet.

The second reason is that we will ultimately need to add a real
module-info.java file to each module. The Automatic-Module-Name
attribute is temporary while the commons projects are worked through
and released. When there is a module-info.java file, we definitely
don't want the Automatic-Module-Name attribute (although it does no
harm, it would look bad).

The opt-in approach is slightly more work, but better in the long run I think.

WDYT?
Stephen


On 18 May 2017 at 20:21, Gary Gregory  wrote:
> On May 18, 2017 12:09 PM, "Benedikt Ritter"  wrote:
>
> Hi,
>
> here is my proposal on how to get the Automatic-Module-Name entry into our
> MANIFEST files. This change has to be made only in commons parent. This is
> the change:
>
> Index: pom.xml
> ===
> --- pom.xml (revision 1795551)
> +++ pom.xml (working copy)
> @@ -601,6 +601,7 @@
>${implementation.build} Implementation-Build>
>${maven.compiler.source} Source-JDK>
>${maven.compiler.target} Target-JDK>
> +  ${commons.osgi.symbolicName} Automatic-Module-Name>
>  
>
>  
>
>
> For Commons Lang this will create:
>
>Automatic-Module-Name: org.apache.commons.lang3
>
>
> WDYT?
>
>
> Seems reasonable enough.
>
> Gary
>
> Benedikt
> -
> 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

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Benedikt Ritter]

Hello Stephen,

> Am 19.05.2017 um 04:52 schrieb Stephen Colebourne :
> 
> Is reusing ${commons.osgi.symbolicName} a good idea?

I thought it is, because this way we will automatically have the additional 
entry after we update a component to the new parent pom version. :o)

> It seems to me that each project should have to opt-in to this
> attribute, so I'd add a new ${commons.automatic.moduile.name}
> variable.

I’d go with ${commons.automatic-module-name}.

> 
> One reason is that the attribute should only be added if the project
> is suitable for use as a module (eg. no packages that clash with any
> other module, doesn't force cycles in dependencies). I'm not convinced
> that all commons projects are valid yet.

Okay, how do we find out whether a component is valid?

> 
> The second reason is that we will ultimately need to add a real
> module-info.java file to each module. The Automatic-Module-Name
> attribute is temporary while the commons projects are worked through
> and released. When there is a module-info.java file, we definitely
> don't want the Automatic-Module-Name attribute (although it does no
> harm, it would look bad).
> 
> The opt-in approach is slightly more work, but better in the long run I think.

I’ll try to come up with something when I have the time again.

Thank you!
Benedikt

> 
> WDYT?
> Stephen
> 
> 
> On 18 May 2017 at 20:21, Gary Gregory  wrote:
>> On May 18, 2017 12:09 PM, "Benedikt Ritter"  wrote:
>> 
>> Hi,
>> 
>> here is my proposal on how to get the Automatic-Module-Name entry into our
>> MANIFEST files. This change has to be made only in commons parent. This is
>> the change:
>> 
>> Index: pom.xml
>> ===
>> --- pom.xml (revision 1795551)
>> +++ pom.xml (working copy)
>> @@ -601,6 +601,7 @@
>>   ${implementation.build}> Implementation-Build>
>>   ${maven.compiler.source}> Source-JDK>
>>   ${maven.compiler.target}> Target-JDK>
>> +  ${commons.osgi.symbolicName}> Automatic-Module-Name>
>> 
>>   
>> 
>> 
>> 
>> For Commons Lang this will create:
>> 
>>   Automatic-Module-Name: org.apache.commons.lang3
>> 
>> 
>> WDYT?
>> 
>> 
>> Seems reasonable enough.
>> 
>> Gary
>> 
>> Benedikt
>> -
>> 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
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Benedikt Ritter]

Hello again,

> Am 21.05.2017 um 10:50 schrieb Benedikt Ritter :
> 
> Hello Stephen,
> 
>> Am 19.05.2017 um 04:52 schrieb Stephen Colebourne > >:
>> 
>> Is reusing ${commons.osgi.symbolicName} a good idea?
> 
> I thought it is, because this way we will automatically have the additional 
> entry after we update a component to the new parent pom version. :o)
> 
>> It seems to me that each project should have to opt-in to this
>> attribute, so I'd add a new ${commons.automatic.moduile.name}
>> variable.
> 
> I’d go with ${commons.automatic-module-name}.
> 
>> 
>> One reason is that the attribute should only be added if the project
>> is suitable for use as a module (eg. no packages that clash with any
>> other module, doesn't force cycles in dependencies). I'm not convinced
>> that all commons projects are valid yet.
> 
> Okay, how do we find out whether a component is valid?
> 
>> 
>> The second reason is that we will ultimately need to add a real
>> module-info.java file to each module. The Automatic-Module-Name
>> attribute is temporary while the commons projects are worked through
>> and released. When there is a module-info.java file, we definitely
>> don't want the Automatic-Module-Name attribute (although it does no
>> harm, it would look bad).
>> 
>> The opt-in approach is slightly more work, but better in the long run I 
>> think.
> 
> I’ll try to come up with something when I have the time again.

This is not as straight forward as I thought. Simply adding 

${commons.automatic-module-name}

Does not work, since this will add an empty entry to the resulting manifest 
file, if a component does not specify the commons.automatic-module-name 
property.

Then I thought we have to add it to a profile. But how do we activate the 
profile? Profile activation can only be made based on system properties, not on 
build properties.

Does anybody have an idea how to add this to commons parent?

Benedikt

> 
> Thank you!
> Benedikt
> 
>> 
>> WDYT?
>> Stephen
>> 
>> 
>> On 18 May 2017 at 20:21, Gary Gregory  wrote:
>>> On May 18, 2017 12:09 PM, "Benedikt Ritter"  wrote:
>>> 
>>> Hi,
>>> 
>>> here is my proposal on how to get the Automatic-Module-Name entry into our
>>> MANIFEST files. This change has to be made only in commons parent. This is
>>> the change:
>>> 
>>> Index: pom.xml
>>> ===
>>> --- pom.xml (revision 1795551)
>>> +++ pom.xml (working copy)
>>> @@ -601,6 +601,7 @@
>>>  ${implementation.build}>> Implementation-Build>
>>>  ${maven.compiler.source}>> Source-JDK>
>>>  ${maven.compiler.target}>> Target-JDK>
>>> +  ${commons.osgi.symbolicName}>> Automatic-Module-Name>
>>>
>>>  
>>>
>>> 
>>> 
>>> For Commons Lang this will create:
>>> 
>>>  Automatic-Module-Name: org.apache.commons.lang3
>>> 
>>> 
>>> WDYT?
>>> 
>>> 
>>> Seems reasonable enough.
>>> 
>>> Gary
>>> 
>>> Benedikt
>>> -
>>> 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 
> 
> For additional commands, e-mail: dev-h...@commons.apache.org 
> 

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Stephen Colebourne]

On 22 May 2017 at 00:32, Benedikt Ritter  wrote:
> This is not as straight forward as I thought. Simply adding
>
> ${commons.automatic-module-name}
>
> Does not work, since this will add an empty entry to the resulting manifest 
> file, if a component does not specify the commons.automatic-module-name 
> property.

I must have misunderstood the docs:
https://maven.apache.org/shared/maven-archiver/examples/manifestEntries.html
which implied to me that a missing property would cause the manifest
entry to be omitted.

> Then I thought we have to add it to a profile. But how do we activate the 
> profile? Profile activation can only be made based on system properties, not 
> on build properties.
>
> Does anybody have an idea how to add this to commons parent?

Nope

Stephen

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Rob Tompkins]

> On May 21, 2017, at 7:32 PM, Benedikt Ritter  wrote:
> 
> Hello again,
> 
>> Am 21.05.2017 um 10:50 schrieb Benedikt Ritter :
>> 
>> Hello Stephen,
>> 
>>> Am 19.05.2017 um 04:52 schrieb Stephen Colebourne >> >:
>>> 
>>> Is reusing ${commons.osgi.symbolicName} a good idea?
>> 
>> I thought it is, because this way we will automatically have the additional 
>> entry after we update a component to the new parent pom version. :o)
>> 
>>> It seems to me that each project should have to opt-in to this
>>> attribute, so I'd add a new ${commons.automatic.moduile.name}
>>> variable.
>> 
>> I’d go with ${commons.automatic-module-name}.
>> 
>>> 
>>> One reason is that the attribute should only be added if the project
>>> is suitable for use as a module (eg. no packages that clash with any
>>> other module, doesn't force cycles in dependencies). I'm not convinced
>>> that all commons projects are valid yet.
>> 
>> Okay, how do we find out whether a component is valid?
>> 
>>> 
>>> The second reason is that we will ultimately need to add a real
>>> module-info.java file to each module. The Automatic-Module-Name
>>> attribute is temporary while the commons projects are worked through
>>> and released. When there is a module-info.java file, we definitely
>>> don't want the Automatic-Module-Name attribute (although it does no
>>> harm, it would look bad).
>>> 
>>> The opt-in approach is slightly more work, but better in the long run I 
>>> think.
>> 
>> I’ll try to come up with something when I have the time again.
> 
> This is not as straight forward as I thought. Simply adding 
> 
> ${commons.automatic-module-name}

You could, in the parent, declare in the properties section beside the 
declaration of “commons.osgi.symbolicName”, another property pointing to that as

${commons.osgi.symbolicName}

and then allow people to override that in their local poms. That way you 
wouldn’t get the blank lines.

> 
> Does not work, since this will add an empty entry to the resulting manifest 
> file, if a component does not specify the commons.automatic-module-name 
> property.
> 
> Then I thought we have to add it to a profile. But how do we activate the 
> profile? Profile activation can only be made based on system properties, not 
> on build properties.
> 
> Does anybody have an idea how to add this to commons parent?
> 
> Benedikt
> 
>> 
>> Thank you!
>> Benedikt
>> 
>>> 
>>> WDYT?
>>> Stephen
>>> 
>>> 
>>> On 18 May 2017 at 20:21, Gary Gregory  wrote:
 On May 18, 2017 12:09 PM, "Benedikt Ritter"  wrote:
 
 Hi,
 
 here is my proposal on how to get the Automatic-Module-Name entry into our
 MANIFEST files. This change has to be made only in commons parent. This is
 the change:
 
 Index: pom.xml
 ===
 --- pom.xml (revision 1795551)
 +++ pom.xml (working copy)
 @@ -601,6 +601,7 @@
 ${implementation.build}>>> Implementation-Build>
 ${maven.compiler.source}>>> Source-JDK>
 ${maven.compiler.target}>>> Target-JDK>
 +  ${commons.osgi.symbolicName}>>> Automatic-Module-Name>
   
 
   
 
 
 For Commons Lang this will create:
 
 Automatic-Module-Name: org.apache.commons.lang3
 
 
 WDYT?
 
 
 Seems reasonable enough.
 
 Gary
 
 Benedikt
 -
 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 
>> 
>> 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

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Stephen Colebourne]

On 22 May 2017 at 12:51, Rob Tompkins  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.osgi.symbolicName}
>
> 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.
Stephen

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Rob Tompkins]

> On May 22, 2017, at 8:10 AM, Stephen Colebourne  wrote:
> 
> On 22 May 2017 at 12:51, Rob Tompkins  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.osgi.symbolicName}
>> 
>> 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.

> 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
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[sebb]

On 22 May 2017 at 13:14, Rob Tompkins  wrote:
>
>> On May 22, 2017, at 8:10 AM, Stephen Colebourne  wrote:
>>
>> On 22 May 2017 at 12:51, Rob Tompkins  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.osgi.symbolicName}
>>>
>>> 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.

>> 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
> 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

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Benedikt Ritter]

Hi,

> Am 22.05.2017 um 09:19 schrieb sebb :
> 
> On 22 May 2017 at 13:14, Rob Tompkins  > wrote:
>> 
>>> On May 22, 2017, at 8:10 AM, Stephen Colebourne  
>>> wrote:
>>> 
>>> On 22 May 2017 at 12:51, Rob Tompkins  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.osgi.symbolicName}
 
 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.

> 
>>> 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 
>> 
>> 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 
> 

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Emmanuel Bourg]

Le 24/05/2017 à 01:26, Benedikt Ritter a écrit :

> Please no more profile activation based on files being present. This is just 
> confusing and a dirty hack IMHO.

Or maybe a profile activated by the presence of module-info.java?

Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Rob Tompkins]

> On May 23, 2017, at 7:26 PM, Benedikt Ritter  wrote:
> 
> Hi,
> 
>> Am 22.05.2017 um 09:19 schrieb sebb :
>> 
>> On 22 May 2017 at 13:14, Rob Tompkins > > wrote:
>>> 
 On May 22, 2017, at 8:10 AM, Stephen Colebourne  
 wrote:
 
 On 22 May 2017 at 12:51, Rob Tompkins  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.osgi.symbolicName}
> 
> 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 
 
 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 
>> 
>> 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

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Stephen Colebourne]

On 24 May 2017 at 15:55, Rob Tompkins  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.

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.

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},
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.

Stephen

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Rob Tompkins]

> On May 24, 2017, at 11:11 AM, Stephen Colebourne  wrote:
> 
> On 24 May 2017 at 15:55, Rob Tompkins  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
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Rob Tompkins]

This should be done now with the entries being “commons.module.name”

Cheers,
-Rob

> On May 24, 2017, at 11:31 AM, Rob Tompkins  wrote:
> 
> 
>> On May 24, 2017, at 11:11 AM, Stephen Colebourne  
>> wrote:
>> 
>> On 24 May 2017 at 15:55, Rob Tompkins  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
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Benedikt Ritter]

Hi,

> Am 03.06.2017 um 18:54 schrieb Rob Tompkins :
> 
> 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.

Benedikt

> 
> Cheers,
> -Rob
> 
>> On May 24, 2017, at 11:31 AM, Rob Tompkins  wrote:
>> 
>> 
>>> On May 24, 2017, at 11:11 AM, Stephen Colebourne  
>>> wrote:
>>> 
>>> On 24 May 2017 at 15:55, Rob Tompkins  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
> 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

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Benedikt Ritter]

Hello Stephen,

> Am 24.05.2017 um 17:11 schrieb Stephen Colebourne :
> 
> On 24 May 2017 at 15:55, Rob Tompkins  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.

Is there some documentation on how to check validity?

Regards,
Benedikt

> 
> 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.
> 
> 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},
> 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.
> 
> 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
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Stephen Colebourne]

On 5 June 2017 at 09:35, Benedikt Ritter  wrote:
> Is there some documentation on how to check validity?

I'm sure there is info in various places, but I've not seen a checklist.

Off the top of my head:
- all packages under a single super-package that is the module name
- jdeps shows no use of internal APIs in the JDK
- no circular dependencies

Once Java 9 is out properly, we can start adding module-info.java
files and creating some proper dependencies.

Stephen

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Rob Tompkins]

> On Jun 5, 2017, at 4:34 AM, Benedikt Ritter  wrote:
> 
> Hi,
> 
>> Am 03.06.2017 um 18:54 schrieb Rob Tompkins > >:
>> 
>> 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.

-Rob

> 
> Benedikt
> 
>> 
>> Cheers,
>> -Rob
>> 
>>> On May 24, 2017, at 11:31 AM, Rob Tompkins  wrote:
>>> 
>>> 
 On May 24, 2017, at 11:11 AM, Stephen Colebourne  
 wrote:
 
 On 24 May 2017 at 15:55, Rob Tompkins  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 
>> 
>> 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 
> 

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Benedikt Ritter]

Hi Rob,

> Am 05.06.2017 um 15:50 schrieb Rob Tompkins :
> 
> 
>> On Jun 5, 2017, at 4:34 AM, Benedikt Ritter  wrote:
>> 
>> Hi,
>> 
>>> Am 03.06.2017 um 18:54 schrieb Rob Tompkins >> >:
>>> 
>>> 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.

Cheers,
Benedikt

> 
> -Rob
> 
>> 
>> Benedikt
>> 
>>> 
>>> Cheers,
>>> -Rob
>>> 
 On May 24, 2017, at 11:31 AM, Rob Tompkins  wrote:
 
 
> On May 24, 2017, at 11:11 AM, Stephen Colebourne  
> wrote:
> 
> On 24 May 2017 at 15:55, Rob Tompkins  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 
>>> 
>>> 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
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Rob Tompkins]

> On Jun 6, 2017, at 7:48 AM, Benedikt Ritter  wrote:
> 
> Hi Rob,
> 
>> Am 05.06.2017 um 15:50 schrieb Rob Tompkins :
>> 
>> 
>>> On Jun 5, 2017, at 4:34 AM, Benedikt Ritter  wrote:
>>> 
>>> Hi,
>>> 
 Am 03.06.2017 um 18:54 schrieb Rob Tompkins >>> >:
 
 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  wrote:
> 
> 
>> On May 24, 2017, at 11:11 AM, Stephen Colebourne  
>> wrote:
>> 
>> On 24 May 2017 at 15:55, Rob Tompkins  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 
 
 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
> 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

Re: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Benedikt Ritter]

> Am 06.06.2017 um 14:00 schrieb Rob Tompkins :
> 
> 
> 
>> On Jun 6, 2017, at 7:48 AM, Benedikt Ritter  wrote:
>> 
>> Hi Rob,
>> 
>>> Am 05.06.2017 um 15:50 schrieb Rob Tompkins :
>>> 
>>> 
 On Jun 5, 2017, at 4:34 AM, Benedikt Ritter  wrote:
 
 Hi,
 
> Am 03.06.2017 um 18:54 schrieb Rob Tompkins  >:
> 
> 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  wrote:
>> 
>> 
>>> On May 24, 2017, at 11:11 AM, Stephen Colebourne  
>>> wrote:
>>> 
>>> On 24 May 2017 at 15:55, Rob Tompkins  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 
> 
> 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 
>> 
>> 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 
>