Le 2025-04-28 à 15 h 31, Piotr Żygieło a écrit :
Isn't this a case of:
https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Collections_and_Arrays:
Indeed, that documentation suggests that the names of the child XML
elements do not matter. I would be inclined to restric
Hello Alexander
I would said that this is a bug. I don't know if the Maven 3 compiler
would be modified, maybe for compatibility reasons. But we can try to
make the Maven 4 compiler stricter.
Martin
Le 2025-04-28 à 14 h 00, Alexander Bubenchikov a écrit :
Hi. The documentation for com
Hello Chen
Le 2024-11-19 à 06 h 52, Chen Zhang a écrit :
I’m curious about the decision-making process for removing parameters
in each release of the Maven Compiler Plugin. Do you have a specific
strategy for evaluating which parameters should be deprecated or
removed? For instance, if you fi
Le 2024-11-12 à 08 h 29, Grégory Jevardat De Fombelle a écrit :
Actually I wanted to use arg files to solve the too long class path on
Windows... I though fork would be enough but there is something else
that I don't understand.
Just for information, the proposed 4.0.0-beta-2 version of the c
Hello
Le 2024-11-11 à 13 h 16, Grégory Jevardat De Fombelle a écrit :
I have difficulties finding documentation on the support of Java arguments
files on the maven compiler plugin.
I'd like to put my long classpath in a file and use it as in javac
documentation for : javac @classpath
I
Le 2024-10-14 à 10 h 45, Stephen Colebourne a écrit :
So you've defined a GAV for Java modules like java.desktop?
Good point. I didn't, but in the proposed approach this is something
that would need to be done (with version number omitted I guess).
Alternatively, it can also be considered ano
Hello Stephen
Le 2024-10-13 à 22 h 57, Stephen Colebourne a écrit :
Problem 1:Services
Already a known problem, as there is no command line flag for
services. This cannot be automatically derived as described above
Already answered in my previous email: this is one of the few cases
where dup
Le 2024-10-12 à 00 h 06, Gary Gregory a écrit :
That's quite the false equivalence: Lambas and records don't force you
to hack JVM start scripts with --add-exports, --add-opens,
--add-modules, --add-reads, and --patch-module...
We are not supposed to add any such option to a start script. The
Le 2024-10-11 à 20 h 21, Gary Gregory a écrit :
I do not need JPMS and I've never had a request for features around it
at work. Our customers care about our products' features and couldn't
care less about JPMS.
We could also said that "customers couldn't care less about lambdas", or
"about
Le 2024-10-11 à 20 h 02, Gary Gregory a écrit :
JPMS feels like something to workaround, not with :(
This is the perception that I hope to change. I happily work with JPMS
everyday, but had to move from Maven to Gradle and tweak Gradle a lot of
that purpose. Let revisit that evaluation after
Le 2024-10-11 à 10 h 21, Stephen Colebourne a écrit :
(…snip…, was about module-info duplicated in main and tests)
This issue remains hugely painful not just in Maven, but across Java.
It is a key part of why JPMS adoption is so painful.
I don't think that adoption is painful because of JPMS
Hello Stephen
Thanks for testing.
Le 2024-10-02 à 00 h 30, Stephen Colebourne a écrit :
At present, the compile phase is asked to compile module-info.java,
but the target/classes directory does not contain module-info.class.
I've no idea where it is going I'm afraid.
Is module-info missing
Hello again Stephen
If you are willing to test the development regarding JPMS, there is the
steps:
* Download Maven 4.0.0-beta4
* Use Maven 4 for building the master branch of
https://github.com/apache/maven-plugin-tools
* Use Maven 4 for building
https://github.com/apache/maven-plugi
Hello Stephen
Just a very quick reply, as I have to go. But I will try to provide more
details tomorrow.
I agree with the problem that you describe, and a massive amount of work
is ongoing for improving Maven support of JPMS, including whitebox
testing. The Maven compiler plugin has already
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 s
+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 canno
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
o put 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
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 dep
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. But
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 implementin
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:
> https://docs.oracle.com/javase/10/docs/api/javax/tools/StandardJavaFileManager.html#setLocationForModule(javax.tools.JavaFileManager.Location,java.lang.String,java.util.Collectio
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 inte
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
> ensu
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 Ma
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 can'
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
-
To
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
useIncrementalC
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: 20150702.16
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
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
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:
http://mail-
41 matches
Mail list logo
