Le 2024-05-13 à 22 h 52, Piotr P. Karwasz a écrit :
If the CycloneDX Maven plugin learns to use those SBOMs as metadata
source instead of POM files, your problem should be solved.
I'm not familiar with CycloneDX, but I think that if any SBOM is used
with a shaded artifact, then the metadata
+1 (non binding)
Java 17 is sufficient for resolving the compilation error that initially
brought this discussion (HTML heading out of sequence). For that
specific problem, Java 17 or 21 are both fine (but Java 11 was not).
Martin
Hello Siddharth
Le 2023-10-13 à 00 h 02, Siddharth Jain a écrit :
IIUC, this is a separate issue. At minimum we need to make the
behavior of compile vs. testCompile consistent. Currently it is not.
Understood, but what I think is the common point is that Maven currently
uses heuristic rules
Hello Siddharth
I do not have a precise answer to your question, but below is a few notes.
Le 2023-10-12 à 23 h 07, Siddharth Jain a écrit :
I have observed the maven-compiler-plugin behaves differently for test
vs. main compilation.
Which approach did you choose for the tests? One approach
Hello Thorsten
Le 02/08/2023 à 11:47, Thorsten Heit a écrit :
I see your point, but we're not living in a fully modularized Java
world: If you insist on having a Jar reside on the module path only,
this prevents others from using it on applications that are not fully
modularized or that
Hello Garret
Le 01/08/2023 à 18:32, Garret Wilson a écrit :
On 7/26/2023 1:42 PM, Martin Desruisseaux wrote:
… If a dependency is on the classpath, then the dependency is loaded
as an unnamed module, its "module-info" file is ignored and the
services that it contains are not disco
a dependency on the module path versus the class-path. Is there
some way to do that that I have missed?
Thanks,
Martin
Le 26/07/2023 à 18:42, Martin Desruisseaux a écrit :
Hello
If I'm understanding right, Maven put a dependency on the module-path
instead of the class-path
Hello
If I'm understanding right, Maven put a dependency on the module-path
instead of the class-path only if:
1. the dependency is modularized (contains a "module-info" file), and
2. the project using the dependency is itself modularized.
Condition #1 is fine, but #2 is problematic. If a
Le 17/10/2022 à 12:33, Olivier Lamy a écrit :
I wanted to have some opinions on what sort of configurations we could
add but this didn't get much attention :)
(https://issues.apache.org/jira/browse/SUREFIRE-2097) Maybe nobody
really cares of jpms...
On my side I do care a lot about JPMS.
Le 01/12/2018 à 21:17, Robert Scholte a écrit :
> This is a dangerous advice.
>
> Yes, it'll only compile the touched files, but not the source files
> using it. For example method signature changes are not detected and
> you will hit that issue at runtime with a NoSuchMethodException, which
> is
Hello Francesco
Have you tried following configuration? It seems counter-intuitive, but
last time I tried it made compilation much faster (i.e. it seems to have
the opposite effect of what we would expect):
maven-compiler-plugin
false
Le 24/11/2018 à 16:39, Robert Scholte a écrit :
> **If And Only If** you want to make use of single tool invocation for
> all you JPMS modules, then you cannot use Maven, it's architecture
> doesn't support it and any plugin trying to solve this is a hack.
>
But isn't what you are going to do for
Le 24/11/2018 à 15:10, Robert Scholte a écrit :
> Today I started looking at MJAVADOC-449 again and it seems that just
> nobody took serious time to solve this. I've been able to create the
> proper commandline by moving some classpath entries to the modulepath.
> Now it is a matter of
Le 24/11/2018 à 13:53, Robert Scholte a écrit :
> With the Java Platform Modular System you'll clearly see different
> requirements between library and application developers.
>
Indeed (e.g. jlink is for application developers), but the requirements
I'm talking about are for library developers.
Le 24/11/2018 à 13:28, Martin Desruisseaux a écrit :
> The key part is "--module-path".
Sorry I mean "--module-source-path" for the compilation and javadoc
generation parts. Likewise I mean "--source-path" instead of
"--classpath" for compi
Hello Jan
Le 24/11/2018 à 12:12, Jan Lahoda a écrit :
> FWIW, there is StandardJavaFileManager.setLocationForModule:
>
Hello Enrico
Le 24/11/2018 à 12:13, Enrico Olivelli a écrit :
> Have you already shared your thoughts and needs with Apache Maven group ?
>
Yes, on the mailing list. My feeling is that in order to be convincing,
I need to create a prototype showing the feasibility of my proposal.
This is the
Hello Robert
Thanks for your reply.
Le 24/11/2018 à 12:36, Robert Scholte a écrit :
> Let me correct this part: there is *no* need to change the folder
> structure to work with the Java Platform Modular System. The only
> thing you need to do is add a module-info.java to src/main/java and
>
I think differently. In Apache SIS for example, we maintain both a Maven
and Ant project. The root source code directory is a classical Maven
project with pom.xml file [1], but we also maintain a sub-directory with
NetBeans Ant project configuration [2]. The official project
configuration is the
Le 22/09/2018 à 20:39, Robert Scholte a écrit :
> You can't.
>
> The Java 9 multiple module compilation doesn't fit into the Maven model.
>
> For Maven, every deliverable requires its own pom, hence a separate
> Maven module.
>
Or alternatively, we can try to get Maven to evolve. Otherwise we
Hello Robert
Le 11/04/2018 à 18:45, Robert Scholte a écrit :
> I am not aware of such problem. Did you create a Jira[1] issue for it?
>
Done: https://issues.apache.org/jira/browse/MCOMPILER-336
Thanks
Martin
-
Hello Robert
Le 11/04/2018 à 18:45, Robert Scholte a écrit :
> I am not aware of such problem. Did you create a Jira[1] issue for it?
>
> There should be no reason to have a workaround, all the information is
> there so Maven is capable to divide jars properly over both paths. If
> you can add a
I also have the case where maven-compiler-plugin puts a dependency in
classpath while it should be in modulepath. Strangely, the plugin does
the correct thing when executed with "mvn _clean_ install" but not when
executing "mvn install" without clean. This issue happen only when the
Hello Jeff
I also wanted to do something similar a while ago. But in my attempt in
a multi-modules project, each modules got a slightly different
timestamp. Building from the root of a project having modules A, B and C
gave me the following timestamps:
A: 20150702.165421-17
B:
Hello all
I'm trying to create a Maven 2 plugin using Ant as described there:
http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html
But I wish to use a different directory layout than the Maven standard
one. More specifically, my .build.xml and .mojos.xml files live elswhere
Hello all
How to add custom entries in a JAR file (in addition to the current file
created by Maven 2)? To be more specific, I would like to add a
RegistrationClassName: org.geotools.openoffice.Registration entry for
an OpenOffice.org add-in.
I'm aware of the following email:
Jason van Zyl a écrit :
I'm just working on the doco so maybe this will help:
http://people.apache.org/~jvanzyl/maven2/guides/mini/guide-manifest.html
Thanks a lot! It is exactly what I was looking for, and it worked
perfectly well!!! Those kind of documentation save days :)
As a side note
27 matches
Mail list logo
