My 2 cents. I’ve spent many, many hours trying to make Log4j 2 JPMS compatible.
It is still nowhere near done. While JPMS sounds simple the side effects it has
permeate
everything. If you were to look at the Log4j 2 master branch right now it is a
complete
mess. Adding Java 9 support was bad en
Keep in mind that the pom.xml is language agnostic, it describes
configuration that makes sense for any programming language.
Hence, the pom should not be extended with Java specific features.
Maven supports extensions, with seems like a better fit.
Configuring an extension is not standardized ye
Le vendredi 05 novembre 2021 à 10:01 +0100, Christian Stein a écrit :
> Or as Robert expressed it:
> https://stackoverflow.com/a/43213506/1431016
> Also read his article linked in the answer.
Thank you, I wish I had seen this article sooner
(https://www.sitepoint.com/maven-cannot-generate-module-
Le sam. 6 nov. 2021 à 12:36, Olivier Cailloux
a écrit :
> Le vendredi 05 novembre 2021 à 09:27 +0100, Romain Manni-Bucau a
> écrit :
> > Think JPMS is not different from OSGi in terms of requirement (it is
> > more
> > broken than OSGi and less used only) so not sure why it would pollute
> > the
Le vendredi 05 novembre 2021 à 09:27 +0100, Romain Manni-Bucau a
écrit :
> Think JPMS is not different from OSGi in terms of requirement (it is
> more
> broken than OSGi and less used only) so not sure why it would pollute
> the
> pom, plus depending how you setup your project you don't use the sam
Le vendredi 05 novembre 2021 à 09:12 +0100, Tamás Cservenák a écrit :
> Not in vanilla maven, but just FYI:
> I think all these benefits (along with boundary checks but Maven
> not JPMS sense) are provided by takari lifecycle:
Thank you for this pointer. The “enforcing dependency usage” part
(http
On Fri, Nov 5, 2021 at 7:55 AM Olivier Cailloux
wrote:
> ...
> Armed with this rich information, Maven could auto-generate the module-
> info.java file before compiling the code; auto-generate the alternative
> module-info.java file before compiling and running the tests;
>
...
That's like sayi
Think JPMS is not different from OSGi in terms of requirement (it is more
broken than OSGi and less used only) so not sure why it would pollute the
pom, plus depending how you setup your project you don't use the same thing
so it would hurt maven convention phylosophy IMHO.
So it is good to stick t
Howdy,
Not in vanilla maven, but just FYI:
I think all these benefits (along with boundary checks but Maven not JPMS
sense) are provided by takari lifecycle:
http://takari.io/book/40-lifecycle.html
Thanks
T
On Fri, Nov 5, 2021 at 7:55 AM Olivier Cailloux
wrote:
> Dear Maven developers,
>
> I’d
Dear Maven developers,
I’d like to propose an idea for Maven to help its users better with the
JPMS.
= Goals
As a developer, I’d like to have all the following benefits. It seems
to me that no existing approach provide them all. I assume a single-
module project with some main code and some white
10 matches
Mail list logo
