> On May 21, 2017, at 7:32 PM, Benedikt Ritter <[email protected]> wrote:
>
> Hello again,
>
>> Am 21.05.2017 um 10:50 schrieb Benedikt Ritter <[email protected]>:
>>
>> Hello Stephen,
>>
>>> Am 19.05.2017 um 04:52 schrieb Stephen Colebourne <[email protected]
>>> <mailto:[email protected]>>:
>>>
>>> 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
>
> <Automatic-Module-Name>${commons.automatic-module-name}</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.automatic-module-name>${commons.osgi.symbolicName}</commons.automatic-module-name>
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 <[email protected]> wrote:
>>>> On May 18, 2017 12:09 PM, "Benedikt Ritter" <[email protected]> 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}</
>>>> Implementation-Build>
>>>> <X-Compile-Source-JDK>${maven.compiler.source}</X-Compile-
>>>> Source-JDK>
>>>> <X-Compile-Target-JDK>${maven.compiler.target}</X-Compile-
>>>> Target-JDK>
>>>> + <Automatic-Module-Name>${commons.osgi.symbolicName}</
>>>> Automatic-Module-Name>
>>>> </manifestEntries>
>>>> </archive>
>>>> </configuration>
>>>>
>>>>
>>>> For Commons Lang this will create:
>>>>
>>>> Automatic-Module-Name: org.apache.commons.lang3
>>>>
>>>>
>>>> WDYT?
>>>>
>>>>
>>>> Seems reasonable enough.
>>>>
>>>> Gary
>>>>
>>>> Benedikt
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> <mailto:[email protected]>
>> For additional commands, e-mail: [email protected]
>> <mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
