enhance genesis-flava8 to use Automatic-Module-Name ?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

enhance genesis-flava8 to use Automatic-Module-Name ?

Mark Struberg
hi!

I think half-loud about enhancing flava8 to use the maven-jar plugin to automatically provide a module name.
It defaults to the artifact-id but can be tweaked by each module to include a Automatic-Module-Name: entry in manifest.mf.

The reason why I do not like the module-info.class is that this often breaks backward compat with many java8 projects. And there are still WAY many companies using java8 only...

wdyt?

LieGrue,
strub

Reply | Threaded
Open this post in threaded view
|

Re: enhance genesis-flava8 to use Automatic-Module-Name ?

Romain Manni-Bucau
There are a few things to take into account I think:

1. Maybe let's drop genesis completely
2. Module info is a pain but still the only way to be jlink compatible, automatic name just enables compilation

I'd be to have a classified artifact with module info if we can otherwise automatic name is ok.

Le ven. 13 mars 2020 à 11:26, Mark Struberg <[hidden email]> a écrit :
hi!

I think half-loud about enhancing flava8 to use the maven-jar plugin to automatically provide a module name.
It defaults to the artifact-id but can be tweaked by each module to include a Automatic-Module-Name: entry in manifest.mf.

The reason why I do not like the module-info.class is that this often breaks backward compat with many java8 projects. And there are still WAY many companies using java8 only...

wdyt?

LieGrue,
strub

Reply | Threaded
Open this post in threaded view
|

Re: enhance genesis-flava8 to use Automatic-Module-Name ?

Mark Struberg
I'd leave genesis-flava for now. We can get rid of it for jakarta.* maybe.

JPMS has completely failed imo. The adoption rate in the industry is near zero.
Companies who need a module system use OSGi. The others use flat classpath. The isolation is a joke. Security wise it's useless.
So the only real benefit we'd have is out-of-the-box compilation with java14.
And for that the MANIFEST.MF entry is enough afaiu.

LieGrue,
strub



Am 13.03.2020 um 11:50 schrieb Romain Manni-Bucau <[hidden email]>:

There are a few things to take into account I think:

1. Maybe let's drop genesis completely
2. Module info is a pain but still the only way to be jlink compatible, automatic name just enables compilation

I'd be to have a classified artifact with module info if we can otherwise automatic name is ok.

Le ven. 13 mars 2020 à 11:26, Mark Struberg <[hidden email]> a écrit :
hi!

I think half-loud about enhancing flava8 to use the maven-jar plugin to automatically provide a module name.
It defaults to the artifact-id but can be tweaked by each module to include a Automatic-Module-Name: entry in manifest.mf.

The reason why I do not like the module-info.class is that this often breaks backward compat with many java8 projects. And there are still WAY many companies using java8 only...

wdyt?

LieGrue,
strub


Reply | Threaded
Open this post in threaded view
|

Re: enhance genesis-flava8 to use Automatic-Module-Name ?

Mark Struberg
Btw, anyone has a clue what the module name for the cdi-2.0 api is?

Did not find anything in the published official jar...
Am I just blind?

LieGrue,
strub

Am 13.03.2020 um 12:31 schrieb Mark Struberg <[hidden email]>:

I'd leave genesis-flava for now. We can get rid of it for jakarta.* maybe.

JPMS has completely failed imo. The adoption rate in the industry is near zero.
Companies who need a module system use OSGi. The others use flat classpath. The isolation is a joke. Security wise it's useless.
So the only real benefit we'd have is out-of-the-box compilation with java14.
And for that the MANIFEST.MF entry is enough afaiu.

LieGrue,
strub



Am 13.03.2020 um 11:50 schrieb Romain Manni-Bucau <[hidden email]>:

There are a few things to take into account I think:

1. Maybe let's drop genesis completely
2. Module info is a pain but still the only way to be jlink compatible, automatic name just enables compilation

I'd be to have a classified artifact with module info if we can otherwise automatic name is ok.

Le ven. 13 mars 2020 à 11:26, Mark Struberg <[hidden email]> a écrit :
hi!

I think half-loud about enhancing flava8 to use the maven-jar plugin to automatically provide a module name.
It defaults to the artifact-id but can be tweaked by each module to include a Automatic-Module-Name: entry in manifest.mf.

The reason why I do not like the module-info.class is that this often breaks backward compat with many java8 projects. And there are still WAY many companies using java8 only...

wdyt?

LieGrue,
strub



Reply | Threaded
Open this post in threaded view
|

Re: enhance genesis-flava8 to use Automatic-Module-Name ?

Romain Manni-Bucau
Don't think there is any official name yet - means we'll probably break any user of the names later. I saw a proposal to use java.cdi but was before jakarta move so not sure today.

Side note: even if I agree jpms is a failure, it will soon be the only way to compile at java rhythm so we should be compliant with it anyway. I'm also thinking to small specs like json*, cdi where doing a jimage can make sense to distribute standalone apps (i'm not speaking of server apps there).

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 13 mars 2020 à 12:48, Mark Struberg <[hidden email]> a écrit :
Btw, anyone has a clue what the module name for the cdi-2.0 api is?

Did not find anything in the published official jar...
Am I just blind?

LieGrue,
strub

Am 13.03.2020 um 12:31 schrieb Mark Struberg <[hidden email]>:

I'd leave genesis-flava for now. We can get rid of it for jakarta.* maybe.

JPMS has completely failed imo. The adoption rate in the industry is near zero.
Companies who need a module system use OSGi. The others use flat classpath. The isolation is a joke. Security wise it's useless.
So the only real benefit we'd have is out-of-the-box compilation with java14.
And for that the MANIFEST.MF entry is enough afaiu.

LieGrue,
strub



Am 13.03.2020 um 11:50 schrieb Romain Manni-Bucau <[hidden email]>:

There are a few things to take into account I think:

1. Maybe let's drop genesis completely
2. Module info is a pain but still the only way to be jlink compatible, automatic name just enables compilation

I'd be to have a classified artifact with module info if we can otherwise automatic name is ok.

Le ven. 13 mars 2020 à 11:26, Mark Struberg <[hidden email]> a écrit :
hi!

I think half-loud about enhancing flava8 to use the maven-jar plugin to automatically provide a module name.
It defaults to the artifact-id but can be tweaked by each module to include a Automatic-Module-Name: entry in manifest.mf.

The reason why I do not like the module-info.class is that this often breaks backward compat with many java8 projects. And there are still WAY many companies using java8 only...

wdyt?

LieGrue,
strub



Reply | Threaded
Open this post in threaded view
|

Re: enhance genesis-flava8 to use Automatic-Module-Name ?

Mark Struberg
Well, it's better than nothing and we are fine off. Btw, even in java14 you can run without it. Just disable jpms via flag.
That's the default in most companies anyway.

With having the automatic module name set we get most benefits without trashing Java8 projects.
Gonna release this now. Please shout if something is still missing/wrong!

LieGrue,
strub


Am 13.03.2020 um 15:02 schrieb Romain Manni-Bucau <[hidden email]>:

Don't think there is any official name yet - means we'll probably break any user of the names later. I saw a proposal to use java.cdi but was before jakarta move so not sure today.

Side note: even if I agree jpms is a failure, it will soon be the only way to compile at java rhythm so we should be compliant with it anyway. I'm also thinking to small specs like json*, cdi where doing a jimage can make sense to distribute standalone apps (i'm not speaking of server apps there).

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 13 mars 2020 à 12:48, Mark Struberg <[hidden email]> a écrit :
Btw, anyone has a clue what the module name for the cdi-2.0 api is?

Did not find anything in the published official jar...
Am I just blind?

LieGrue,
strub

Am 13.03.2020 um 12:31 schrieb Mark Struberg <[hidden email]>:

I'd leave genesis-flava for now. We can get rid of it for jakarta.* maybe.

JPMS has completely failed imo. The adoption rate in the industry is near zero.
Companies who need a module system use OSGi. The others use flat classpath. The isolation is a joke. Security wise it's useless.
So the only real benefit we'd have is out-of-the-box compilation with java14.
And for that the MANIFEST.MF entry is enough afaiu.

LieGrue,
strub



Am 13.03.2020 um 11:50 schrieb Romain Manni-Bucau <[hidden email]>:

There are a few things to take into account I think:

1. Maybe let's drop genesis completely
2. Module info is a pain but still the only way to be jlink compatible, automatic name just enables compilation

I'd be to have a classified artifact with module info if we can otherwise automatic name is ok.

Le ven. 13 mars 2020 à 11:26, Mark Struberg <[hidden email]> a écrit :
hi!

I think half-loud about enhancing flava8 to use the maven-jar plugin to automatically provide a module name.
It defaults to the artifact-id but can be tweaked by each module to include a Automatic-Module-Name: entry in manifest.mf.

The reason why I do not like the module-info.class is that this often breaks backward compat with many java8 projects. And there are still WAY many companies using java8 only...

wdyt?

LieGrue,
strub