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 <garydgreg...@gmail.com> wrote:
> On May 18, 2017 12:09 PM, "Benedikt Ritter" <brit...@apache.org> 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: 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

Reply via email to