How to use Vector API with Maven Exec Plugin

[Siddharth Jain]

>
>
> Hello,


How can I use the Vector API with maven exec plugin? I compiled my project
with these settings and it worked fine:

org.apache.maven.plugins
maven-compiler-plugin

20
20

--enable-preview
--add-modules
jdk.incubator.vector


20




But when I try to run it using mvn exec:java I get this error:
java.lang.ClassNotFoundException: jdk.incubator.vector.Vector

My exec plugin configuration looks like this: I have tried many variations
but nothing seems to work. Please help!

org.codehaus.mojo
exec-maven-plugin
3.1.0



java




com.mycompany.app.App

--enable-preview 
--add-modules jdk.incubator.vector 

Re: Multi-repo experience

[Romain Manni-Bucau]

Maybe for log4j a major difference will be the versioning. Having a
compatibility matrix is always a pain for end users so several projects
abandonned that to just be a monorelease repo.
Except that it depends who work on what more than anything, technically all
works and none is better than others.

Le sam. 26 août 2023 à 16:03, Hervé Boutemy  a
écrit :

> notice that you call it "multi-repo experience"
> it's in fact more about a topic of component-oriented structure, each
> component having its own release lifecycle. The fact that each component
> has
> his own Git repository is just an implementation detail (in the past, each
> component had its own root directory in Subversion: see [1] for how we
> went
> from svn structure to Git one).
>
> > Would you still go the same route if Maven is founded today?
> yes: Maven is a core, with plugins (and extension) = something we would
> not
> change without loosing critical aspects of Maven
> and the fact that some plugins reuse some shared components is normal
>
> of course, the exact number of plugins and shared components could have
> been
> done with different granularity
>
> And on using Google repo tool and the precise directory organisation when
> checking out everything, it's an implementation detail:
> https://github.com/apache/maven-sources/tree/master
> Changing anything here can be done, it's not critical: what is critical is
> the
> component-oriented approach. Then the granularity chosen for these
> components.
>
> Regards,
>
> Hervé
>
> [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration
>
> Le samedi 26 août 2023, 09:50:28 CEST Hervé Boutemy a écrit :
> > Hi Volkan,
> >
> > Yes, I worked a lot on this aspect fo Maven: the result is summarised
> here
> > https://maven.apache.org/scm.html
> >
> > As you can see, you can get "Maven Full Sources" in one command using
> Google
> > "repo" tool.
> >
> > Please have a llok and we can dive into more details if you need
> >
> > Regards,
> >
> > Hervé
> >
> > Le jeudi 24 août 2023, 12:30:41 CEST Volkan Yazıcı a écrit :
> > > Hello,
> > >
> > > Log4j crew is considering moving to a multi-repo structure. If I am not
> > > mistaken, there are 125 `github.com/apache/maven-*`
> 
> > >  repos, which makes me believe that
> you
> > > have quite a bit of experience with such a construct. I am curious to
> hear
> > > your thoughts on the matter.
> > >
> > > How does it work for you?
> > > What are its advantages?
> > > What are its disadvantages?
> > > What are the things we should be extra cautious about?
> > > Are there any major pillars we need to erect for such a construct to
> work?
> > > Would you still go the same route if Maven is founded today?
> > >
> > > I deliberately don't share in this post our goals with such a
> migration to
> > > avoid manipulating your line of thinking. I can do that later to give
> the
> > > conversation a little bit more context.
> > >
> > > Kind regards.
> >
> > -
> > 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: Multi-repo experience

[Hervé Boutemy]

notice that you call it "multi-repo experience"
it's in fact more about a topic of component-oriented structure, each 
component having its own release lifecycle. The fact that each component has 
his own Git repository is just an implementation detail (in the past, each 
component had its own root directory in Subversion: see [1] for how we went 
from svn structure to Git one).

> Would you still go the same route if Maven is founded today?
yes: Maven is a core, with plugins (and extension) = something we would not 
change without loosing critical aspects of Maven
and the fact that some plugins reuse some shared components is normal

of course, the exact number of plugins and shared components could have been 
done with different granularity

And on using Google repo tool and the precise directory organisation when 
checking out everything, it's an implementation detail:
https://github.com/apache/maven-sources/tree/master
Changing anything here can be done, it's not critical: what is critical is the 
component-oriented approach. Then the granularity chosen for these components.

Regards,

Hervé

[1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration

Le samedi 26 août 2023, 09:50:28 CEST Hervé Boutemy a écrit :
> Hi Volkan,
> 
> Yes, I worked a lot on this aspect fo Maven: the result is summarised here
> https://maven.apache.org/scm.html
> 
> As you can see, you can get "Maven Full Sources" in one command using Google
> "repo" tool.
> 
> Please have a llok and we can dive into more details if you need
> 
> Regards,
> 
> Hervé
> 
> Le jeudi 24 août 2023, 12:30:41 CEST Volkan Yazıcı a écrit :
> > Hello,
> > 
> > Log4j crew is considering moving to a multi-repo structure. If I am not
> > mistaken, there are 125 `github.com/apache/maven-*`
> >  repos, which makes me believe that you
> > have quite a bit of experience with such a construct. I am curious to hear
> > your thoughts on the matter.
> > 
> > How does it work for you?
> > What are its advantages?
> > What are its disadvantages?
> > What are the things we should be extra cautious about?
> > Are there any major pillars we need to erect for such a construct to work?
> > Would you still go the same route if Maven is founded today?
> > 
> > I deliberately don't share in this post our goals with such a migration to
> > avoid manipulating your line of thinking. I can do that later to give the
> > conversation a little bit more context.
> > 
> > Kind regards.
> 
> -
> 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

How to fix MNG-7855 (dependencies wrongly put on class-path rather than module-path)?

[Martin Desruisseaux]

Hello all

MNG-7855 [1] is a quasi-blocker issue (at least a major impediment) for 
migration to JPMS. I can try to provide a patch, but I'm not familiar 
with Maven internal and would need guidance. Another issue is that 
fixing this bug probably requires the addition of a new option, which 
would require discussion.


The bug is in the way that dependencies are dispatched between 
class-path and module-path. It is based on the wrong assumption that if 
an application is not modularized, then all its dependencies must be on 
the class-path. This is not true. An application can be classical 
(non-modularized) and still have some or all its dependencies on the 
module-path. For the application, it may make no visible difference. 
However for the dependency itself, the fact that it was declared on the 
class-path or on the module-path can make a big difference. This is 
explained in the issue [1] and a "hello-world" project demonstrating 
that is at [2].


On the Maven discussion mailing list, it has been suggested that the 
workaround is easy (duplicate module-info information into 
META-INF/services/) and that if a library behaves differently depending 
on whether it was specified on the class-path or on the module-path, it 
would be a library bug. I question those claims:


 * A module can declare a lot of service providers (~70 in my case),
   and being forced to keep module-info and META-INF/services/ in sync
   is a risk of inconsistency.
 * META-INF/services/ is not always equivalent to module-info. In some
   cases, there is no easy way to reproduce the same effect (e.g.
   singleton provider instances).
 * Reflection methods do not behave in the same way depending on
   whether the library was declared on the class-path or module-path.
   More generally, the OpenJDK API contains between 100 and 200
   caller-sensitive methods. There is plenty of room for unforeseen
   behavioral differences.
 * If the library wants to load external JAR files dynamically (after
   JVM startup), the ways to do that are totally different: with
   URLClassLoader in a class-path world, but with ModuleLayer in a
   module-path world. The differences are too large for making
   practical to support both.

So workarounds for MNG-7855 are practical only in simple cases, and 
MNG-7855 can become a blocker issue in more complex applications. A 
quick and I think "behaviorally correct" fix would be to drop the check 
about whether the project is modularized or not, i.e. check only if the 
_dependency_ is modularized. This approach was discussed in Gradle as 
well [3]. But because this fix may be backward incompatible if some 
projects rely on the current behavior, we may need to make this change 
an opt-in. So we may need to discuss for a new option.


A better long-term fix would be to allow developers to specify in their 
 block whether they want the dependency to be on the 
class-path or module-path. But that would require a POM model change, so 
for now I would like to contribute to a shorter-term fix with a new 
option if possible.


    Thanks,

        Martin

[1]https://issues.apache.org/jira/browse/MNG-7855
[2]https://github.com/Geomatys/MavenModulepathBug
[3]https://github.com/gradle/gradle/issues/25954

Re: Multi-repo experience

[Hervé Boutemy]

Hi Volkan,

Yes, I worked a lot on this aspect fo Maven: the result is summarised here
https://maven.apache.org/scm.html

As you can see, you can get "Maven Full Sources" in one command using Google 
"repo" tool.

Please have a llok and we can dive into more details if you need

Regards,

Hervé

Le jeudi 24 août 2023, 12:30:41 CEST Volkan Yazıcı a écrit :
> Hello,
> 
> Log4j crew is considering moving to a multi-repo structure. If I am not
> mistaken, there are 125 `github.com/apache/maven-*`
>  repos, which makes me believe that you
> have quite a bit of experience with such a construct. I am curious to hear
> your thoughts on the matter.
> 
> How does it work for you?
> What are its advantages?
> What are its disadvantages?
> What are the things we should be extra cautious about?
> Are there any major pillars we need to erect for such a construct to work?
> Would you still go the same route if Maven is founded today?
> 
> I deliberately don't share in this post our goals with such a migration to
> avoid manipulating your line of thinking. I can do that later to give the
> conversation a little bit more context.
> 
> Kind regards.





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