Re: JPMS support, refactored proposal

[Romain Manni-Bucau]

Le jeu. 4 janv. 2024 à 01:23, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2024-01-03 à 21 h 31, Romain Manni-Bucau a écrit :
>
> >> Can you compile this test case with the dependency on the class-path,
> >> without omitting the module-info in the compilation?
> >>
> > This is exactly the case, module-info is injected somehow - a common
> > case is by generating its bytecode but multiple compiler executions is
> > another case.
> >
> I'm talking about the case where developers write their own code,
> including the module-info.java file. You confirm that this test case in
> uncompilable with class-path?
>


Yep


> I presume that "multiple compiler executions" means "compiling only a
> subset of the project". The situation is the same: module-path works,
> class-path does not work unless the module-info.class file is deleted. I
> updated the README with step-by-step instructions for anyone to try:
>
> https://github.com/Geomatys/MavenModulepathBug/tree/modularized-client
>
> Finally, if some developers want to inject a generated module-info.class
> file *after* compilation, then class-path works. But the developers lost
> all compile-time safety regarding module encapsulation. Nothing prevent
> the developers to accidentally use non-exported packages, in which case
> compilation will wrongly succeed but an exception will be thrown at
> runtime when the code attempts an unauthorized access. So no, class-path
> doesn't work for JPMS projects, except by tricking Java with
> module-info.class injection *after* compilation. I would discourage that
> trick because:
>
>   * The whole project loses all compiler verification of package
> accesses, resulting in potentially unexecutable application because
> of code that should not have been allowed to compile.
>   * Errors in the generated module-info.class itself (e.g. missing
> "requires" statements, wrong "provides" statements, etc.) will also
> be unnoticed at compile-time.
>   * Adding a class generation phase is more complicated than handling
> module-info like ordinary source code and letting javac do its job
> (with the added benefit of letting javac do all the verification).
>   * Module-info is rich (requires, transitive requires, static requires,
> exports, qualified exports, opens, qualified opens, uses, provides,
> javadoc, etc.). I don't think that generated code can reflect
> developers intend as accurately than hand-written module-info.
>

This is only true if you are a scala guy (old joke) and compiling is
testing.
You can easily a compiling but not running case and not all statement are
true, just true when biaised from jpms view but look bnd or moditech and
most become no more true.


> Before to argument on each point, let focus on the first one. There is
> no way (to my knowledge) someone can use class-path without scarifying
> compile-time checks of package accesses. However, if someone really
> wants to do that anyway, it will still be possible. But it is not the
> approach that I'm trying to make easy. The approach that I'm trying to
> make easy is the sane way, which is module-info (either .java or .class)
> available at compile time, which mandates the use of module-path (I'm
> talking only of JPMS projects here). The claim that class-path is the
> way to go in JPMS projects is demonstratively false, proven by above
> test case. Class-path in JPMS project is unsafe at best, or doesn't work
> at all otherwise. If I'm wrong, I need to be convinced by test cases.
> Not email arguments, test cases.
>

Please just stip thinking jpms first, think classpath first with jpms
compat, changes the whole perspective.
If i want classpath compat more than jpms why would i do everything with
module and miss my 80% case?


>
> > Now, enhance your example to consume a jar where implicit module name
> > would be invalid for example, how would you compile?
> >
> If the implicit name is wrong, I want a compilation error. Why would I
> want a compilation success followed by a runtime failure? Furthermore,
> this counter example is moot, because by the rules explained in previous
> emails, that JAR file would be placed on the class-path by default since
> it has no module-info and no Automatic-Name manifest attribute. Anyway,
> users can also explicitly request to put any dependency on the class-path.
>

Same there, my lib integrates with a 3rd party, its name is wrong but i
still want this optional integration - not exposed using jpms.


>
> > javadoc:javadoc ->
> >
> https://github.com/apache/maven-javadoc-plugin/blob/master/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L4420
> >
> This link shows that current Javadoc plugin has some JPMS support. The
> compiler plugin also has its own (problematic) support, and each plugin
> does that in a different way. So this link does not mean that there is
> no problem to resolve.
>

Didnt say there is no problem just that all exam

[discuss] extend extensions.xml to lifecycles/packaging and types?

[Romain Manni-Bucau]

Hi all,

Reviewing and trying to follow Martin's thread about JPMS I thought about
the old issue that our build pipelines (plugins chain) is very hard to
customize.
Guillaume added the priority case but the clean solution proposed
originally was to define custom lifecycles (to add frontend, docker builds
for ex) - more or less a custom AbstractLifecycleMappingProvider.

I wonder if we shouldn't extend .mvn/extensions.xml (or root pom
 block) to support to define custom lifecycle mappings there
and potentially explicit new "types" too which would be great for Martin's
work since it would allow to avoid undefined types and implicit jar mapping
in a "strict" mode (to detect typos for ex since it must become open).

So proposal is to extend extension to get more configuration - and coded
extensions can indeed plug themselves there.
The main challenge seems to be to re-evaluate the mappings but looks doable.
High level it is more or less "let the pom/.mvn inject maven components
without coding/by declaration".

Hope it makes sense, let me know if it is worth investigating more or if
the idea is too particular to my old needs.

Best,
Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book

Re: [discuss] extend extensions.xml to lifecycles/packaging and types?

[Christoph Läubrich]

Isn't it already possible to "extend" the lifecycle by simply putting 
plugin + execution into root pom?


Main problem for me is that currently packaging == type == lifecycle, 
otherwise one could simply have an "empty" lifecycle + whatever 
packaging and simply bind anything you want tin pom.xml e.g.




   jar
  empty (would default to packaging if not 
given, where empty is just a lifecycle with no mappings)

  
   

  org.apache.maven.plugins
  maven-jar-plugin
  

... define all your custom bindings here ...



Am 04.01.24 um 09:37 schrieb Romain Manni-Bucau:

Hi all,

Reviewing and trying to follow Martin's thread about JPMS I thought about
the old issue that our build pipelines (plugins chain) is very hard to
customize.
Guillaume added the priority case but the clean solution proposed
originally was to define custom lifecycles (to add frontend, docker builds
for ex) - more or less a custom AbstractLifecycleMappingProvider.

I wonder if we shouldn't extend .mvn/extensions.xml (or root pom
 block) to support to define custom lifecycle mappings there
and potentially explicit new "types" too which would be great for Martin's
work since it would allow to avoid undefined types and implicit jar mapping
in a "strict" mode (to detect typos for ex since it must become open).

So proposal is to extend extension to get more configuration - and coded
extensions can indeed plug themselves there.
The main challenge seems to be to re-evaluate the mappings but looks doable.
High level it is more or less "let the pom/.mvn inject maven components
without coding/by declaration".

Hope it makes sense, let me know if it is worth investigating more or if
the idea is too particular to my old needs.

Best,
Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book




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

Re: JPMS support, refactored proposal

[Martin Desruisseaux]

Le 2024-01-04 à 09 h 21, Romain Manni-Bucau a écrit :

Please just stip thinking jpms first, think classpath first with jpms 
compat, changes the whole perspective. If i want classpath compat more 
than jpms why would i do everything with module and miss my 80% case?


Because doing everything as JPMS + workarounds (e.g. copying service 
declarations into META-INF) works in both cases (proof: the Apache SIS 
project), while the converse is not true: you cannot compile a JPMS 
project with class-path, except by tricking Java (inject module-info 
*after* compilation, at the cost of sacrificing compile-time checks in 
the whole project).


    Martin

Re: JPMS support, refactored proposal

[Romain Manni-Bucau]

Le jeu. 4 janv. 2024 à 10:20, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2024-01-04 à 09 h 21, Romain Manni-Bucau a écrit :
>
> > Please just stip thinking jpms first, think classpath first with jpms
> > compat, changes the whole perspective. If i want classpath compat more
> > than jpms why would i do everything with module and miss my 80% case?
> >
> Because doing everything as JPMS + workarounds (e.g. copying service
> declarations into META-INF) works in both cases (proof: the Apache SIS
> project), while the converse is not true: you cannot compile a JPMS
> project with class-path, except by tricking Java (inject module-info
> *after* compilation, at the cost of sacrificing compile-time checks in
> the whole project).
>

You also explained this is not true since you cannot compile part of the
code linked to optional deps which go against JPMS so status quo there and
no single silver bullet.
You will also note the compile time check is a very low check in this area
compared to any runtime (tests) so this is a sacrifice which is generally
very acceptable until you are JPMS first which is still quite rare - I
don't want we emphasis JPMS more than its adoption, this is not because
tools are not ready that it is not adopted just because the programming
model is not nice enough, the ecosystem is far to have adopted it and it
does not bring much to dev, so please don't assume JPMS is the way to go
*yet* - hopefully it can be enhanced in the future on java platform but it
is way outside build scope IMHO.

So overall doing anything JPMS + workaround works in 80% of cases, doing
anything classpath + workarounds for JPMS works in 90% of cases or
something like that so it is literally a dev/community preference IMHO and
you can't impose one or the other with technical points (depends how much
you use optional deps, the existing code base, the compilation base also,
etc...).
Let's just make it all working as smoothly both ways.


>
>  Martin
>
>

Re: [discuss] extend extensions.xml to lifecycles/packaging and types?

[Romain Manni-Bucau]

Hi Christoph,

commented inline

Le jeu. 4 janv. 2024 à 10:19, Christoph Läubrich  a
écrit :

> Isn't it already possible to "extend" the lifecycle by simply putting
> plugin + execution into root pom?
>

Kind of but it requires a lot of abstraction and inheritance abuse IMHO.
For a single module you are very right but for a 10+ project where 5+
modules will use the same kind of build it will require a pom in the middle
leading to werid structures like root/services/x/pom.xml root/lib/x/pom.xml
so composition would be better there - but you're right, not a blocker to
build the final deliverables.


>
> Main problem for me is that currently packaging == type == lifecycle,
> otherwise one could simply have an "empty" lifecycle + whatever
> packaging and simply bind anything you want tin pom.xml e.g.
>
>
> 
> jar
>empty (would default to packaging if not
> given, where empty is just a lifecycle with no mappings)
>
> 
>  
>org.apache.maven.plugins
>maven-jar-plugin
>
> 
>  ... define all your custom bindings here ...
>
>
almost, you still need to associate phase(s) to each plugin to be able to
run "mvn compile" "mvn test" or alike until we have an alias notion in
pom/extensions.xml (= say "mvn foo" means run these plugins but it is the
lifecycle somehow).



>
>
> Am 04.01.24 um 09:37 schrieb Romain Manni-Bucau:
> > Hi all,
> >
> > Reviewing and trying to follow Martin's thread about JPMS I thought about
> > the old issue that our build pipelines (plugins chain) is very hard to
> > customize.
> > Guillaume added the priority case but the clean solution proposed
> > originally was to define custom lifecycles (to add frontend, docker
> builds
> > for ex) - more or less a custom AbstractLifecycleMappingProvider.
> >
> > I wonder if we shouldn't extend .mvn/extensions.xml (or root pom
> >  block) to support to define custom lifecycle mappings there
> > and potentially explicit new "types" too which would be great for
> Martin's
> > work since it would allow to avoid undefined types and implicit jar
> mapping
> > in a "strict" mode (to detect typos for ex since it must become open).
> >
> > So proposal is to extend extension to get more configuration - and coded
> > extensions can indeed plug themselves there.
> > The main challenge seems to be to re-evaluate the mappings but looks
> doable.
> > High level it is more or less "let the pom/.mvn inject maven components
> > without coding/by declaration".
> >
> > Hope it makes sense, let me know if it is worth investigating more or if
> > the idea is too particular to my old needs.
> >
> > Best,
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [discuss] extend extensions.xml to lifecycles/packaging and types?

[Christoph Läubrich]

> Kind of but it requires a lot of abstraction and inheritance abuse IMHO.

Not completely sure, but of course all would need to inherit the same 
parent, maybe one can allow to "import" pom with plugin configuration as 
an alternative, but for extension.xml it is the same you need to copy it 
over to all child projects of course.


> almost, you still need to associate phase(s) to each plugin

Plugins can have a default phase that is chosen if not specified, still 
a lifecycle mapping would require that as well, so lifeycle mapping (as 
xml component xml) is just a little bit different syntax then?


Am 04.01.24 um 10:32 schrieb Romain Manni-Bucau:

Hi Christoph,

commented inline

Le jeu. 4 janv. 2024 à 10:19, Christoph Läubrich  a
écrit :


Isn't it already possible to "extend" the lifecycle by simply putting
plugin + execution into root pom?



Kind of but it requires a lot of abstraction and inheritance abuse IMHO.
For a single module you are very right but for a 10+ project where 5+
modules will use the same kind of build it will require a pom in the middle
leading to werid structures like root/services/x/pom.xml root/lib/x/pom.xml
so composition would be better there - but you're right, not a blocker to
build the final deliverables.




Main problem for me is that currently packaging == type == lifecycle,
otherwise one could simply have an "empty" lifecycle + whatever
packaging and simply bind anything you want tin pom.xml e.g.



 jar
empty (would default to packaging if not
given, where empty is just a lifecycle with no mappings)

 
  
org.apache.maven.plugins
maven-jar-plugin

 
  ... define all your custom bindings here ...



almost, you still need to associate phase(s) to each plugin to be able to
run "mvn compile" "mvn test" or alike until we have an alias notion in
pom/extensions.xml (= say "mvn foo" means run these plugins but it is the
lifecycle somehow).






Am 04.01.24 um 09:37 schrieb Romain Manni-Bucau:

Hi all,

Reviewing and trying to follow Martin's thread about JPMS I thought about
the old issue that our build pipelines (plugins chain) is very hard to
customize.
Guillaume added the priority case but the clean solution proposed
originally was to define custom lifecycles (to add frontend, docker

builds

for ex) - more or less a custom AbstractLifecycleMappingProvider.

I wonder if we shouldn't extend .mvn/extensions.xml (or root pom
 block) to support to define custom lifecycle mappings there
and potentially explicit new "types" too which would be great for

Martin's

work since it would allow to avoid undefined types and implicit jar

mapping

in a "strict" mode (to detect typos for ex since it must become open).

So proposal is to extend extension to get more configuration - and coded
extensions can indeed plug themselves there.
The main challenge seems to be to re-evaluate the mappings but looks

doable.

High level it is more or less "let the pom/.mvn inject maven components
without coding/by declaration".

Hope it makes sense, let me know if it is worth investigating more or if
the idea is too particular to my old needs.

Best,
Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github <

https://github.com/rmannibucau> |

LinkedIn  | Book
<

https://www.packtpub.com/application-development/java-ee-8-high-performance





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






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

Re: JPMS support, refactored proposal

[Martin Desruisseaux]

Le 2024-01-04 à 10 h 27, Romain Manni-Bucau a écrit :

You also explained this is not true since you cannot compile part of 
the code linked to optional depswhich go against JPMS



No, optional dependencies in JPMS are handled by "static requires".


You will also note the compile time check is a very low check in this 
area compared to any runtime (tests) so this is a sacrifice which is 
generally very acceptable


This statement is highly questionable. But anyway, this is an 
unnecessary sacrifice as it requires going the hard way (trick Java).



the ecosystem is far to have adopted it and it does not bring much to 
dev, so please don't assume JPMS is the way to go *yet*.


I'm not forcing anyone to use JPMS. I'm trying to make it easy for those 
who want.


 * Want class-path compatibility only? Compile on class-path.
 * Want JPMS compatibility only? Compile on module-path.
 * Want JPMS + class-path compatibility? Compile on module-path +
   workarounds. There is no sane alternative.



doing anything classpath + workarounds for JPMS works in 90% of cases

No, this approach requires tricking Java and is unsafe, for no gain in 
the end result compared to the simple and sane way. Furthermore, it does 
not work at all (uncompilable) for the common case where the developer 
wants to write module-info.java himself. It does not cover 90% of cases, 
it is more like 1%.


    Martin

Re: JPMS support, refactored proposal

[Romain Manni-Bucau]

Le jeu. 4 janv. 2024 à 10:54, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2024-01-04 à 10 h 27, Romain Manni-Bucau a écrit :
>
> > You also explained this is not true since you cannot compile part of
> > the code linked to optional depswhich go against JPMS
> >
> No, optional dependencies in JPMS are handled by "static requires".
>

As explained in previous post it is not always possible cause JPMS enforces
constraints which are not always respected.


>
>
> > You will also note the compile time check is a very low check in this
> > area compared to any runtime (tests) so this is a sacrifice which is
> > generally very acceptable
> >
> This statement is highly questionable. But anyway, this is an
> unnecessary sacrifice as it requires going the hard way (trick Java).
>
>
> > the ecosystem is far to have adopted it and it does not bring much to
> > dev, so please don't assume JPMS is the way to go *yet*.
> >
> I'm not forcing anyone to use JPMS. I'm trying to make it easy for those
> who want.
>
>   * Want class-path compatibility only? Compile on class-path.
>   * Want JPMS compatibility only? Compile on module-path.
>   * Want JPMS + class-path compatibility? Compile on module-path +
> workarounds. There is no sane alternative.
>
>
> > doing anything classpath + workarounds for JPMS works in 90% of cases
> >
> No, this approach requires tricking Java and is unsafe, for no gain in
> the end result compared to the simple and sane way. Furthermore, it does
> not work at all (uncompilable) for the common case where the developer
> wants to write module-info.java himself. It does not cover 90% of cases,
> it is more like 1%.
>

Your vision I guess, mine is the opposite from what I saw in OSS land so
let's not move forward in the discussion while both cases are covered we
will be fine.


>
>  Martin
>
>

Re: [discuss] extend extensions.xml to lifecycles/packaging and types?

[Romain Manni-Bucau]

Le jeu. 4 janv. 2024 à 10:37, Christoph Läubrich  a
écrit :

>  > Kind of but it requires a lot of abstraction and inheritance abuse IMHO.
>
> Not completely sure, but of course all would need to inherit the same
> parent, maybe one can allow to "import" pom with plugin configuration as
> an alternative, but for extension.xml it is the same you need to copy it
> over to all child projects of course.
>

Why? extension is global for the project so no copy needed.


>
>  > almost, you still need to associate phase(s) to each plugin
>
> Plugins can have a default phase that is chosen if not specified, still
> a lifecycle mapping would require that as well, so lifeycle mapping (as
> xml component xml) is just a little bit different syntax then?
>

You can get a phase if it exists, not sure if you make it empty - was my
point


>
> Am 04.01.24 um 10:32 schrieb Romain Manni-Bucau:
> > Hi Christoph,
> >
> > commented inline
> >
> > Le jeu. 4 janv. 2024 à 10:19, Christoph Läubrich  a
> > écrit :
> >
> >> Isn't it already possible to "extend" the lifecycle by simply putting
> >> plugin + execution into root pom?
> >>
> >
> > Kind of but it requires a lot of abstraction and inheritance abuse IMHO.
> > For a single module you are very right but for a 10+ project where 5+
> > modules will use the same kind of build it will require a pom in the
> middle
> > leading to werid structures like root/services/x/pom.xml
> root/lib/x/pom.xml
> > so composition would be better there - but you're right, not a blocker to
> > build the final deliverables.
> >
> >
> >>
> >> Main problem for me is that currently packaging == type == lifecycle,
> >> otherwise one could simply have an "empty" lifecycle + whatever
> >> packaging and simply bind anything you want tin pom.xml e.g.
> >>
> >>
> >> 
> >>  jar
> >> empty (would default to packaging if not
> >> given, where empty is just a lifecycle with no mappings)
> >> 
> >>  
> >>   
> >> org.apache.maven.plugins
> >> maven-jar-plugin
> >> 
> >>  
> >>   ... define all your custom bindings here ...
> >>
> >>
> > almost, you still need to associate phase(s) to each plugin to be able to
> > run "mvn compile" "mvn test" or alike until we have an alias notion in
> > pom/extensions.xml (= say "mvn foo" means run these plugins but it is the
> > lifecycle somehow).
> >
> >
> >
> >>
> >>
> >> Am 04.01.24 um 09:37 schrieb Romain Manni-Bucau:
> >>> Hi all,
> >>>
> >>> Reviewing and trying to follow Martin's thread about JPMS I thought
> about
> >>> the old issue that our build pipelines (plugins chain) is very hard to
> >>> customize.
> >>> Guillaume added the priority case but the clean solution proposed
> >>> originally was to define custom lifecycles (to add frontend, docker
> >> builds
> >>> for ex) - more or less a custom AbstractLifecycleMappingProvider.
> >>>
> >>> I wonder if we shouldn't extend .mvn/extensions.xml (or root pom
> >>>  block) to support to define custom lifecycle mappings
> there
> >>> and potentially explicit new "types" too which would be great for
> >> Martin's
> >>> work since it would allow to avoid undefined types and implicit jar
> >> mapping
> >>> in a "strict" mode (to detect typos for ex since it must become open).
> >>>
> >>> So proposal is to extend extension to get more configuration - and
> coded
> >>> extensions can indeed plug themselves there.
> >>> The main challenge seems to be to re-evaluate the mappings but looks
> >> doable.
> >>> High level it is more or less "let the pom/.mvn inject maven components
> >>> without coding/by declaration".
> >>>
> >>> Hope it makes sense, let me know if it is worth investigating more or
> if
> >>> the idea is too particular to my old needs.
> >>>
> >>> Best,
> >>> Romain Manni-Bucau
> >>> @rmannibucau  |  Blog
> >>>  | Old Blog
> >>>  | Github <
> >> https://github.com/rmannibucau> |
> >>> LinkedIn  | Book
> >>> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: JPMS support, refactored proposal

[Martin Desruisseaux]

Le 2024-01-04 à 11 h 31, Romain Manni-Bucau a écrit :


No, optional dependencies in JPMS are handled by "static requires".

As explained in previous post it is not always possible cause JPMS 
enforces constraints which are not always respected.



I don't understand what you mean. Test case please.



Your vision I guess, mine is the opposite from what I saw in OSS land.

It is not a vision, it is a fact. I provided a test case. If I'm wrong, 
prove it with a test case please.


    Martin

Re: JPMS support, refactored proposal

[Romain Manni-Bucau]

Le jeu. 4 janv. 2024 à 11:42, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2024-01-04 à 11 h 31, Romain Manni-Bucau a écrit :
>
> >> No, optional dependencies in JPMS are handled by "static requires".
> >>
> > As explained in previous post it is not always possible cause JPMS
> > enforces constraints which are not always respected.
> >
> I don't understand what you mean. Test case please.
>

Just take the previous example you even explained yourself with an invalid
JPMS name, this is still a valid case today.


>
>
> > Your vision I guess, mine is the opposite from what I saw in OSS land.
> >
> It is not a vision, it is a fact. I provided a test case. If I'm wrong,
> prove it with a test case please.
>
>  Martin
>
>

Re: JPMS support, refactored proposal

[Martin Desruisseaux]

Le 2024-01-04 à 12 h 49, Romain Manni-Bucau a écrit :

Just take the previous example you even explained yourself with an 
invalid JPMS name, this is still a valid case today.


Module names are like any other symbol names (classes, methods, etc.). 
If a module name is invalid, we want the same compilation error as 
invalid class name or invalid method name. Why would we want the 
compiler to silently ignore errors that are certain to cause runtime 
exception? If you are aware of a valid case, please show it with a test 
case (an application compiled with invalid module name, and still 
executable as JPMS).


    Martin

Re: [discuss] extend extensions.xml to lifecycles/packaging and types?

[Christoph Läubrich]

> Why? extension is global for the project so no copy needed.

If you want to use it in different project I'm not aware how you can 
share extension.xml between them ... but a pom deployed somewhere can be 
reused (in pom.xml) also extension/extensions.xml cant contain any 
configuration)


> You can get a phase if it exists, not sure if you make it empty
> - was my point

I see, well maybe it would better be named "empty-jar" and defines al 
phases of the usual jar except that it does not bind any plugins by 
default, or maybe thinking more about it maybe one should not use any 
name but a simple list e.g.



   jar
  clean,custom,package,install (would default to 
lifecycle of packaging if not given)

  

would define an (empty) lifecycle that has the phase 
clean,custom,package,install only and now you know the order one can 
bind plugins there...





Am 04.01.24 um 11:32 schrieb Romain Manni-Bucau:

Le jeu. 4 janv. 2024 à 10:37, Christoph Läubrich  a
écrit :


  > Kind of but it requires a lot of abstraction and inheritance abuse IMHO.

Not completely sure, but of course all would need to inherit the same
parent, maybe one can allow to "import" pom with plugin configuration as
an alternative, but for extension.xml it is the same you need to copy it
over to all child projects of course.



Why? extension is global for the project so no copy needed.




  > almost, you still need to associate phase(s) to each plugin

Plugins can have a default phase that is chosen if not specified, still
a lifecycle mapping would require that as well, so lifeycle mapping (as
xml component xml) is just a little bit different syntax then?



You can get a phase if it exists, not sure if you make it empty - was my
point




Am 04.01.24 um 10:32 schrieb Romain Manni-Bucau:

Hi Christoph,

commented inline

Le jeu. 4 janv. 2024 à 10:19, Christoph Läubrich  a
écrit :


Isn't it already possible to "extend" the lifecycle by simply putting
plugin + execution into root pom?



Kind of but it requires a lot of abstraction and inheritance abuse IMHO.
For a single module you are very right but for a 10+ project where 5+
modules will use the same kind of build it will require a pom in the

middle

leading to werid structures like root/services/x/pom.xml

root/lib/x/pom.xml

so composition would be better there - but you're right, not a blocker to
build the final deliverables.




Main problem for me is that currently packaging == type == lifecycle,
otherwise one could simply have an "empty" lifecycle + whatever
packaging and simply bind anything you want tin pom.xml e.g.



  jar
 empty (would default to packaging if not
given, where empty is just a lifecycle with no mappings)
 
  
   
 org.apache.maven.plugins
 maven-jar-plugin
 
  
   ... define all your custom bindings here ...



almost, you still need to associate phase(s) to each plugin to be able to
run "mvn compile" "mvn test" or alike until we have an alias notion in
pom/extensions.xml (= say "mvn foo" means run these plugins but it is the
lifecycle somehow).






Am 04.01.24 um 09:37 schrieb Romain Manni-Bucau:

Hi all,

Reviewing and trying to follow Martin's thread about JPMS I thought

about

the old issue that our build pipelines (plugins chain) is very hard to
customize.
Guillaume added the priority case but the clean solution proposed
originally was to define custom lifecycles (to add frontend, docker

builds

for ex) - more or less a custom AbstractLifecycleMappingProvider.

I wonder if we shouldn't extend .mvn/extensions.xml (or root pom
 block) to support to define custom lifecycle mappings

there

and potentially explicit new "types" too which would be great for

Martin's

work since it would allow to avoid undefined types and implicit jar

mapping

in a "strict" mode (to detect typos for ex since it must become open).

So proposal is to extend extension to get more configuration - and

coded

extensions can indeed plug themselves there.
The main challenge seems to be to re-evaluate the mappings but looks

doable.

High level it is more or less "let the pom/.mvn inject maven components
without coding/by declaration".

Hope it makes sense, let me know if it is worth investigating more or

if

the idea is too particular to my old needs.

Best,
Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github <

https://github.com/rmannibucau> |

LinkedIn  | Book
<



https://www.packtpub.com/application-development/java-ee-8-high-performance





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






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additio

Re: [discuss] extend extensions.xml to lifecycles/packaging and types?

[Romain Manni-Bucau]

Le jeu. 4 janv. 2024 à 13:17, Christoph Läubrich  a
écrit :

>  > Why? extension is global for the project so no copy needed.
>
> If you want to use it in different project I'm not aware how you can
> share extension.xml between them ... but a pom deployed somewhere can be
> reused (in pom.xml) also extension/extensions.xml cant contain any
> configuration)
>

s/project/modules/ ;)


>
>  > You can get a phase if it exists, not sure if you make it empty
>  > - was my point
>
> I see, well maybe it would better be named "empty-jar" and defines al
> phases of the usual jar except that it does not bind any plugins by
> default, or maybe thinking more about it maybe one should not use any
> name but a simple list e.g.
>
> 
> jar
>clean,custom,package,install (would default to
> lifecycle of packaging if not given)
>
>
> would define an (empty) lifecycle that has the phase
> clean,custom,package,install only and now you know the order one can
> bind plugins there...
>

This is more or less the idea except you define the chain in extensions.xml
to let be reused by submodules.
Inline you will need an aggregator pom and I'm not sure how well it will
sit in a packaging=pom pom defining it for children.


>
>
>
>
> Am 04.01.24 um 11:32 schrieb Romain Manni-Bucau:
> > Le jeu. 4 janv. 2024 à 10:37, Christoph Läubrich  a
> > écrit :
> >
> >>   > Kind of but it requires a lot of abstraction and inheritance abuse
> IMHO.
> >>
> >> Not completely sure, but of course all would need to inherit the same
> >> parent, maybe one can allow to "import" pom with plugin configuration as
> >> an alternative, but for extension.xml it is the same you need to copy it
> >> over to all child projects of course.
> >>
> >
> > Why? extension is global for the project so no copy needed.
> >
> >
> >>
> >>   > almost, you still need to associate phase(s) to each plugin
> >>
> >> Plugins can have a default phase that is chosen if not specified, still
> >> a lifecycle mapping would require that as well, so lifeycle mapping (as
> >> xml component xml) is just a little bit different syntax then?
> >>
> >
> > You can get a phase if it exists, not sure if you make it empty - was my
> > point
> >
> >
> >>
> >> Am 04.01.24 um 10:32 schrieb Romain Manni-Bucau:
> >>> Hi Christoph,
> >>>
> >>> commented inline
> >>>
> >>> Le jeu. 4 janv. 2024 à 10:19, Christoph Läubrich 
> a
> >>> écrit :
> >>>
>  Isn't it already possible to "extend" the lifecycle by simply putting
>  plugin + execution into root pom?
> 
> >>>
> >>> Kind of but it requires a lot of abstraction and inheritance abuse
> IMHO.
> >>> For a single module you are very right but for a 10+ project where 5+
> >>> modules will use the same kind of build it will require a pom in the
> >> middle
> >>> leading to werid structures like root/services/x/pom.xml
> >> root/lib/x/pom.xml
> >>> so composition would be better there - but you're right, not a blocker
> to
> >>> build the final deliverables.
> >>>
> >>>
> 
>  Main problem for me is that currently packaging == type == lifecycle,
>  otherwise one could simply have an "empty" lifecycle + whatever
>  packaging and simply bind anything you want tin pom.xml e.g.
> 
> 
>  
>    jar
>   empty (would default to packaging if not
>  given, where empty is just a lifecycle with no mappings)
>   
>    
> 
>   org.apache.maven.plugins
>   maven-jar-plugin
>   
>    
> ... define all your custom bindings here ...
> 
> 
> >>> almost, you still need to associate phase(s) to each plugin to be able
> to
> >>> run "mvn compile" "mvn test" or alike until we have an alias notion in
> >>> pom/extensions.xml (= say "mvn foo" means run these plugins but it is
> the
> >>> lifecycle somehow).
> >>>
> >>>
> >>>
> 
> 
>  Am 04.01.24 um 09:37 schrieb Romain Manni-Bucau:
> > Hi all,
> >
> > Reviewing and trying to follow Martin's thread about JPMS I thought
> >> about
> > the old issue that our build pipelines (plugins chain) is very hard
> to
> > customize.
> > Guillaume added the priority case but the clean solution proposed
> > originally was to define custom lifecycles (to add frontend, docker
>  builds
> > for ex) - more or less a custom AbstractLifecycleMappingProvider.
> >
> > I wonder if we shouldn't extend .mvn/extensions.xml (or root pom
> >  block) to support to define custom lifecycle mappings
> >> there
> > and potentially explicit new "types" too which would be great for
>  Martin's
> > work since it would allow to avoid undefined types and implicit jar
>  mapping
> > in a "strict" mode (to detect typos for ex since it must become
> open).
> >
> > So proposal is to extend extension to get more configuration - and
> >> coded
> > extensions can indeed plug themselves there.
> > The main challenge seems to

Re: JPMS support, refactored proposal

[Romain Manni-Bucau]

Le jeu. 4 janv. 2024 à 13:05, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2024-01-04 à 12 h 49, Romain Manni-Bucau a écrit :
>
> > Just take the previous example you even explained yourself with an
> > invalid JPMS name, this is still a valid case today.
>
> Module names are like any other symbol names (classes, methods, etc.).
> If a module name is invalid, we want the same compilation error as
> invalid class name or invalid method name. Why would we want the
> compiler to silently ignore errors that are certain to cause runtime
> exception? If you are aware of a valid case, please show it with a test
> case (an application compiled with invalid module name, and still
> executable as JPMS).
>

Cause it just works (and was forking for years). Geronimo specs jar have
this issue for ex and this is not a blocker for lib builders to consume
them, build with them and produce a JPMS friendly jar.


>
>  Martin
>
>

Re: JPMS support, refactored proposal

[Martin Desruisseaux]

Le 2024-01-04 à 14 h 24, Romain Manni-Bucau a écrit :


Cause it just works (and was forking for years). Geronimo specs jar 
have this issue for ex and this is not a blocker for lib builders to 
consume them, build with them and produce a JPMS friendly jar.


Still no test case for proving that it works? Link to the relevant part 
of Geronimo build so we can check what they are doing exactly?


    Martin

Nexus returns 400 Bad Request

[tison]

Hi,

When deploying artifacts to Nexus repository, 400 Bad Request can be
one of the most confusing error code. See [1] as an example.

Sonatype has a page to document some common causes of 400 Bad Request
[2]. But I wonder if we can return an error message (diagnostic) along
with the error code, so that users can get what conditions broken
exactly.

I suppose it has been discussed before. Is there any reference about
this? What is the related components / code I can check for potential
contributions (fixes)?

Best,
tison.

[1] https://issues.apache.org/jira/browse/INFRA-25344
[2] https://central.sonatype.org/faq/400-error/

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

Re: JPMS support, refactored proposal

[Romain Manni-Bucau]

Well it was written that the artifact names were not JPMS compatible, you
can review https://github.com/apache/geronimo-specs but it was just one
example.
Don't get me wrong but indeed you can fix all the world to make it fully
JPMS compatible, this is not what happent since java 9 so I don't consider
that path as something relevant today.

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



Le jeu. 4 janv. 2024 à 14:31, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2024-01-04 à 14 h 24, Romain Manni-Bucau a écrit :
> >
> > Cause it just works (and was forking for years). Geronimo specs jar
> > have this issue for ex and this is not a blocker for lib builders to
> > consume them, build with them and produce a JPMS friendly jar.
> >
> Still no test case for proving that it works? Link to the relevant part
> of Geronimo build so we can check what they are doing exactly?
>
>  Martin
>
>

Re: JPMS support, refactored proposal

[Martin Desruisseaux]

Le 2024-01-04 à 15 h 56, Romain Manni-Bucau a écrit :

Well it was written that the artifact names were not JPMS compatible, 
you can review https://github.com/apache/geronimo-specs but it was 
just one example.


Without link to the specific section, I cannot review if it is related 
to our discussion. Compiling with JAR files on the class-path and 
expecting Java to handle them as JPMS modules later just doesn't work, 
or is tricky and unsafe at best. So Geronimo must be doing something 
else, e.g. maybe they choose to not handle the problematic artifact as a 
JPMS module (which is allowed by the proposal for Maven 4). Projects do 
not need to be 100% modules or 100% class-path, it can be a mix of both. 
But whatever they choose must be consistent at compilation, 
documentation and execution.



Don't get me wrong but indeed you can fix all the world to make it 
fully JPMS compatible, this is not what happent since java 9 so I 
don't consider that path as something relevant today.


We already had this discussion. I (and at least one other person on this 
mailing list) think that this is a chicken and egg problem. But anyway, 
even if some peoples think that module-paths are not relevant today, it 
is not a reason for blocking peoples who think that it is relevant.


    Martin



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

Re: JPMS support, refactored proposal

[Romain Manni-Bucau]

Le jeu. 4 janv. 2024 à 16:21, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2024-01-04 à 15 h 56, Romain Manni-Bucau a écrit :
>
> > Well it was written that the artifact names were not JPMS compatible,
> > you can review https://github.com/apache/geronimo-specs but it was
> > just one example.
> >
> Without link to the specific section, I cannot review if it is related
> to our discussion. Compiling with JAR files on the class-path and
> expecting Java to handle them as JPMS modules later just doesn't work,
> or is tricky and unsafe at best. So Geronimo must be doing something
> else, e.g. maybe they choose to not handle the problematic artifact as a
> JPMS module (which is allowed by the proposal for Maven 4). Projects do
> not need to be 100% modules or 100% class-path, it can be a mix of both.
> But whatever they choose must be consistent at compilation,
> documentation and execution.
>


We didnt speak of that but consuming that in a classpath/module friendly
project.


>
> > Don't get me wrong but indeed you can fix all the world to make it
> > fully JPMS compatible, this is not what happent since java 9 so I
> > don't consider that path as something relevant today.
> >
> We already had this discussion. I (and at least one other person on this
> mailing list) think that this is a chicken and egg problem. But anyway,
> even if some peoples think that module-paths are not relevant today, it
> is not a reason for blocking peoples who think that it is relevant.
>

Yep (both ways), this is why nothing is blocked except making it status quo
or reverting current paradigm to priviledge the other one.
This is why I said you I think everyone can be happy if some careness on
core is done - I care less about plugins since it is leaves in release
cycle and can be more instable than core must be.


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

Re: JPMS support, refactored proposal

[Martin Desruisseaux]

Le 2024-01-04 à 17 h 01, Romain Manni-Bucau a écrit :

We didnt speak of that but consuming that in a classpath/module 
friendly project.


This part was answered: build as JPMS + workarounds. The 
counter-argument was that it should be built as class-path + workarounds 
instead, which I tried to demonstrate by test cases that it doesn't 
work. JPMS + workaround is the only sane way (to my knowledge) to build 
a lib that can be consumed on both the classpath and the module-path.


    Martin

Re: JPMS support, refactored proposal

[Romain Manni-Bucau]

...check it out again but you also said "it does not work" so still not, as
soon as one lib is not jpms compatible (not by not being a module but by
not being consummable even with implciit name as explained in this example)
you can't use jpms first but you can always workaround the other way around
so from a theorical standpoint classpath has still a wider area - not
saying it is better to always start with classpath though, don't
overinterpret please.

But anyway we can move forward we don't have to agree on that

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



Le jeu. 4 janv. 2024 à 17:19, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2024-01-04 à 17 h 01, Romain Manni-Bucau a écrit :
>
> > We didnt speak of that but consuming that in a classpath/module
> > friendly project.
> >
> This part was answered: build as JPMS + workarounds. The
> counter-argument was that it should be built as class-path + workarounds
> instead, which I tried to demonstrate by test cases that it doesn't
> work. JPMS + workaround is the only sane way (to my knowledge) to build
> a lib that can be consumed on both the classpath and the module-path.
>
>  Martin
>
>

Re: New year - new challenge - required Maven 3.6.3 as minimal for core Maven Plugins

[Hervé Boutemy]

for the records, "Maven Plugins Compatibility Plan" strategy is stored in
 https://maven.apache.org/developers/compatibility-plan.html

= the doc to refer to and update if necessary after the current discussion

Le vendredi 29 décembre 2023, 14:42:17 CET Slawomir Jaranowski a écrit :
> Hi,
> 
> Last year we mark all Maven versions 3.6.x and older as EOL [1]
> 
> But we still try to support minimal API version for Core Maven Plugins as
> 3.2.5
> 
> I would like to  propose to sich it for at least to 3.6.3
> 
> Reasonable reasons: (for me)
>  - for standard CI build we use Maven 3.6.3 and newer
>  - many of external plugins, like MojoHaus are switched to 3.6.3
>  - we have a hacks in code to try support old version in plugin, like
> in: EnhancedPluginDescriptorBuilder in plugin-tools [2], we can cleanup
> such code
> - I don't believe to someone want to do more fixes for EOL Maven version in
> plugins - so we should be a honest for users
> - and we should go forward
> 
> [1] https://maven.apache.org/docs/history.html
> [2]
> https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-report
> -plugin/src/main/java/org/apache/maven/plugins/plugin/descriptor/EnhancedPlu
> ginDescriptorBuilder.java





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