Hello
Le 2025-05-26 à 22 h 55, Sergey Chernov a écrit :
Just tried the 4.0.0-rc-3 comparing with 3.9.9, it's 4x times slower
(!) on a project of ~900 modules (700 of them are jar).
Regarding performance, some months ago I noticed that Maven contains
loops over elements of a list with a call
Le 2025-05-25 à 19 h 12, Hunter C Payne a écrit :
My experiences with JPMS have been universally been bad.
Your experience of JPMS, or your experience of Maven 3 / Gradle support
of JPMS?
If you are going to do this, you need to make the default for it to be
completely disabled.
As repe
Le 2025-05-25 à 13 h 28, Elliotte Rusty Harold a écrit :
Can you be more specific? Is there some code we need to produce or
compile that we cannot compile with Java 8?
Yes. Maven 4 core and the compiler plugin 4.0.0-beta already got the
following Java 9+ dependencies:
* MODULE_PATH, UPGRAD
Hello all
Le 2025-05-24 à 15 h 33, Elliotte Rusty Harold a écrit :
If you want to upgrade the minimum Java version, you need a better
reason than that. I haven't yet heard a reason strong enough to
convince me. Others have other opinions.
Java 9+ for supporting JPMS. This is needed not only
I agree with Elliotte and his example with parenthesis. I do not
consider "unnecessary parenthesis" as a violation, since they sometime
improve code readability. The last time that I used PMD in a big project
(years ago), we had thousands of warnings reported as "violations" that
we considered
Le 2025-05-17 à 18 h 30, Andy Law a écrit :
How do multi-release and multi-module relate one to another
From the user's point of view, they are orthogonal. We can use
multi-releases or not. We can use multi-modules or not. Those two
features are governed by two independent XML elements inside
Le 2025-05-16 à 15 h 01, Andy Law a écrit :
OK. I see the purpose of the tag now.
To elaborate on the purpose of : we could argue that javac
should be able to discover this information itself by parsing the
module-info file. But a single module can have its source files split in
many direct
Le 2025-05-16 à 14 h 27, Andy Law a écrit :
>> The most natural way is to do parent/moduleX/src/main/java (and
siblings)
>> and handle the compiler plugin in parent to be jpms specific, no
technical
>> blocker, no maven core change needed
> This (^^) just seems so natural, I can’t believe tha
Le 2025-05-15 à 22 h 02, Andy Law a écrit :
I still think that the new folder structure feels “dirty”, and from my
current position of ignorance, it also feels like the element
under actually creates a problem that didn’t really exist.
The goal of this JPMS work is to give more control to
Le 2025-05-15 à 19 h 55, Sergey Chernov a écrit :
Is "src/${scope}-${module}/${lang}" a considerable option?
It wasn't mentioned in previous discussions on GitHub. I just added it
as a 4th proposal in the wiki page.
Martin
Le 2025-05-15 à 20 h 26, Andy Law a écrit :
I confess that I was using “standard” in the context of what I
understand to be the _Maven_ standard, since this is the Maven
developers list
The core issue is that we need a different directory for each module. I
don't see how a new type for JPM
Le 2025-05-15 à 19 h 54, Andy Law a écrit :
Or maybe go the whole hog and define a new type
specifically for jpms and just use the standard layouts underneath that?
Does "standard layouts" means "layout defined by the javac man page"? If
yes, the default layout is just "src/${module}", with
Le 2025-05-15 à 19 h 39, Romain Manni-Bucau a écrit :
I still fail why you need to not respect current maven layout,
Because it doesn't work with multi-release compilation.
you are allowed to enhance plugins to be inter maven modules if you
want - tycho does it for years
it adds layers of
Hello David
The usefulness of multi-modules compilation may be debated, but I don't
think that Maven should impose its view on users. Multi-modules is a
Java feature that exists, is documented, standardized and officially
supported. It does provide some benefits. It may come at the cost of
so
Le 2025-05-15 à 19 h 03, Andy Law a écrit :
I don’t understand why this is so different from an aggregated
project, with ${module} above src, but I may be missing the point
because I’ve not spent any time thinking about JPMS yet.
Because it enables compile-time verification that the compiler
Le 2025-05-15 à 18 h 52, Romain Manni-Bucau a écrit :
I didn't get why we can't get 1 artifact = 1 module so can stick to
current convention.
I presume that you mean "1 subproject = 1 module". It is still possible.
Nothing force users to abandon that model if they like it. "1 artifact =
1 m
Hello all
Currently, the default directory for source code in Maven 4 is:
src/${scope}/${lang}
Where ${scope} is "main" or "test" and ${lang} is "java" or "resources".
However, in the case of a multi-modules JPMS projects, we need to add
the module name somewhere. Notes:
* This change a
Hello
There is two branches that we could merge, but I would like to
double-check on this list before to move ahead.
The first pull request (PR) is replacing Plexus dependency by java.nio
in the maven-clean-plugin. This PR got two reviewers approval, so in my
understanding I could merge, but
+1 (non-binding)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Le 2025-04-15 à 14 h 13, Romain Manni-Bucau a écrit :
Assuming you use javac or a standard compiler as known today, this got
proven fragile multiple times even before jpms
When new parameters are added to javac, developers can use
as a tedious workaround until the compiler plugin is updated.
Le 2025-04-15 à 11 h 53, Romain Manni-Bucau a écrit :
If we add a new mechanism for allowing other plugins to access the
configuration of the Java compiler plugin, it would make plugin
evolution more risky since a change in the parameters could
potentially impact an unknown number of plugins.
Le 2025-04-15 à 08 h 01, Romain Manni-Bucau a écrit :
Depends if exported or not, but if it is an interface or abstract class
just to enable the module itself pluggability and testability you still
need to do some homework.
If the homework are reflection, there is no --add-opens or other optio
Le 2025-04-14 à 19 h 43, Romain Manni-Bucau a écrit :
This is not always true, the common case is to inject a mock of an external
service to test an algorithm or alike.
If the service is a public interface, there is no need to patch a module
for creating mocks.
I'd like all the JPMS to st
Le 2025-04-14 à 17 h 36, Romain Manni-Bucau a écrit :
white/black box tests (or whatever name you use today) are a good example
which show you need at least two files exactly as today ("without jpms")
you play with surefire execution.
The proposed `module-info-patch` is for whitebox testing on
Hello Romain
Le 2025-04-14 à 14 h 28, Romain Manni-Bucau a écrit :
(…snip…)
Doesn't it sound better than a file which looks like a java thing but is
not (content), has no editor support (extension), will need to be supported
by all plugins and still requires its location to be configurable sin
Le 2025-04-14 à 12 h 49, Gary Gregory a écrit :
"The ".txt" extension is because this file is not standard Java
(proposals for better extension are welcome)."
How about ".mvn" or ".maven" to make it clear that this file exists
for Maven's purpose and is not documentation, which is what ".txt"
Hello all
The compiler plugin has a pull request which is ready for the support of
multi-release projects and modular projects defined by the
elements introduced in POM 4.1.0. However, the changes are a bit large
and I'm not sure how to proceed for review, as it would be a lot of work
for re
Le 2025-04-01 à 11 h 07, Gary Gregory a écrit :
I suppose it feels like Java is still being developed in an ivory
tower away from the real world. The constant reinventing the wheel
(logging and http client APIs are obvious examples). I suppose OSGi
vs. JPMS could fall into this category.
The b
Typo:
Le 2025-04-01 à 10 h 17, Martin Desruisseaux a écrit :
It would require the maven-jar-plugin to generate one JAR per Maven
module.
Was intended to be "one JAR per Java module".
Martin
-
To unsubscri
Le 2025-04-01 à 10 h 49, Piotr P. Karwasz a écrit :
The https://github.com/nipafx/module-tooling/ repo seems to be
private. Is there any public place to follow the discussion?
Not as far as I know. The initiator of this discussion wanted to keep it
private, I'm not sure why. This topic has be
Le 2025-04-01 à 08 h 37, Gary Gregory a écrit :
What Piotr describes is sadly the kind of insane setup one must have
to work with JPMS and keeps me saying JPMS is something to work
around, not work with.
I think that what Piotr described is a Maven issue, not a JPMS issue.
The problem is that
Hello Piotr
Le 2025-04-01 à 08 h 20, Piotr P. Karwasz a écrit :
I fail to understand, however, the purpose of the "modular project"
layout.
All modules are compiled in one single calls to `javac`. It is not one
call of `javac` per module. The benefit is that forward references to
dependent
Hello all
JPMS support in the compiler plugin (not yet merged) has reached a point
where it can be used on some real projects. The Maven 3 way to make a
modular project is still supported, but the proposed alternative for
better use of JPMS is described here:
*
https://github.com/Geomatys/
Le 2025-03-26 à 11 h 12, Guillaume Nodet a écrit :
This release contains a few changes, mainly an upgrade to Maven
4.0.0-rc-3 which brought a few incompatible changes in the API and
thus requires this update. This release also updates a few dependencies.
+1, tested with maven-compiler-plugin
Le 2025-03-25 à 13 h 00, Elliotte Rusty Harold a écrit :
Really what we need to do is eliminate modello.
So what about this plan?
* Check-in the generated classes as they are today.
* Remove Modello.
* Try on a branch to change the classes to record.
Martin
Hello
The `org.apache.maven.api.model` package of Maven 4 contains classes
generated automatically from the `maven.mdo` file [1], which describes
the POM. The generated classes are similar to Java records
(unmodifiable, straightforward getter methods, etc.). However, they have
a lot of boiler
Le 2025-03-24 à 20 h 32, Romain Manni-Bucau a écrit :
any reason to move a plugin configuration from plugin to ?
(concretely why do we go that way instead of dropping sources concept
from build)?
Because that configuration is used by many plugins. The same information
is needed by Javadoc pl
Hello all
A development branch of maven-compiler-plugin 4.0 can now support the
property of the new element introduced in Maven 4.
The creation of multi-release JAR files for non-modular projects
should hopefully become easier (support for modular projects will be
added later). Includes/excludes
Le 2025-03-18 à 09 h 57, Romain Manni-Bucau a écrit :
Hmm, processor is not really a scope, more just a qualifier since it
can be used for compile or test scopes and even worse, often
processors are provided scope (maybe as a workaround to avoid optional
but still a thing in current maven pic
Le 2025-03-18 à 08 h 05, Thomas Reinhardt a écrit :
On 17/03/2025 17:03, Matthias Bünger wrote:
I'm not an IDE developer, but Maven user and mixing those two, for me
independend things, will make it more confusing than simpler.
Spot on. Please don't mix those. Because we will end up either with
Le 2025-03-17 à 17 h 03, Matthias Bünger a écrit :
I'm not an IDE developer, but Maven user and mixing those two, for me
independend things, will make it more confusing than simpler.
The usage of introduced in Maven 4 is already implicitly mixing
the scope. The proposal to replace:
modula
Le 2025-03-17 à 13 h 42, Romain Manni-Bucau a écrit :
(about being closely related to which plugin us it):
This is a quite dangerous target cause you will end up with scope =
plugin to keep it useable.
Not necessarily. This is only a convenience for a common pattern.
Plugins can filter the de
Le 2025-03-17 à 12 h 02, Romain Manni-Bucau a écrit :
Concretely the issue there is that you now require the plugins to
configure a list of (type, scope) instead of a list of types to be
functional.
I'd personally prefer we assume that types and scopes as two things do
not make sense anymore
Le 2025-03-16 à 17 h 37, Guillaume Nodet a écrit :
I think it's time to create a branch to release Maven 4.0.0 GA in the
coming weeks and switch master to 4.1.0-SNAPSHOT. Thoughts ?
One element that may be adjusted before GA. Maven 4 introduced a new way
to control where to put a JAR file, us
Le 2025-03-17 à 08 h 23, Guillaume Nodet a écrit :
Yeah, I proposed a while ago to move the maven plugin and testing
harness inside Maven Core to keep them more easily aligned... So maybe
we think about it again ? I do think we want them to be roughly
available at the same time...
I would ap
+1 (non-binding), but should we publish a "known limitations" page? On a
related topic, the documentation on [1] would need more editions. For
example, [2] said that it uses the plexus compiler, while actually
Plexus is not used anymore (replaced by javax.tools API).
Martin
[1]https://mav
Le 2025-02-04 à 16 h 27, Romain Manni-Bucau a écrit :
there are still processors which are runtime jars, would you make them
declared twice and deduplicated by maven for relevant phases/scopes?
The same JAR file which would need to be both on the class-path and on
the annotation processor pa
Hello all
Maven 4 introduced some new types of JAR, including:
* jar (same as Maven 3)
* modular-jar
* classpath-jar
* processor
* classpath-processor
* modular-processor
It has been pointed out (in a discussion elsewhere about JPMS) that
declaring that a JAR is for use by the annotation
Thanks all for your welcoming. Just for information, the area where I
would like to contribute are maven core and the following plugins:
compiler, surefire, jar, maybe javadoc (the latter one is particular,
more on it another day).
Martin
Le 2025-01-28 à 07 h 50, Guillaume Nodet a écrit :
This release is mainly about to upgrade to Maven 4.0.0-rc-2.
+1 (non binding). Tested with the compiler plugin and integration test
passes.
Will submit a pull request for the compiler plugin after this upgrade
has been published.
Mart
Le 2024-11-25 à 13 h 23, Guillaume Nodet a écrit :
Yes, the model can now evolve much more easily than with Maven 3,
that's one of the main benefits of Maven 4. You should create a PR for
these changes, eventually in draft mode if it's not ready yet.
Thanks, done in draft mode: https://githu
Hello all
Just for planning, there is one significant change that I was hopping to
bring to Maven model: the introduction of a Source element, as discussed
previously. A draft is a [1]. If Maven 4.0.0 is released soon, would a
change of model still be possible in, for example, Maven 4.1?
+1 (non-binding)
Martin
Le 2024-11-09 à 17 h 27, Arnaud Héritier a écrit :
+1
On Fri, Nov 8, 2024 at 8:56 AM Guillaume Nodet wrote:
Hi
The only change is the upgrade to Maven 4.0.0-beta-5.
This release is necessary to test plugins based on the Maven 4 API, as
there were some breaking
Hello
Le 2024-11-01 à 08 h 23, Ozgun Oz a écrit :
I would love to at least have a view on the discussions as an
observer. I think what Olivier propose, "making the group/discussion
public" would be great help to the community.
The discussion did not started yet (or if it did, I didn't realiz
Hello all
The proposed new compiler plugin has been updated with the following
changes:
* Use of ASM for rewriting the module-info.java file on JDK older than
22 has been reintroduced (for reproductible builds).
* Support for overwriting module-info.java in the tests has been
reimpleme
Le 2024-10-24 à 14 h 25, Robert Scholte a écrit :
Just one question: what will happen with Maven3 users (or any other
tool) if one of their dependencies has this special type?
Rephrasing as "what will happen with a Maven 3 plugin running on Maven 4
without having been updated to the Maven 4 API
Le 2024-10-24 à 14 h 13, Robert Scholte a écrit :
What I'm seeing here is: service provides both a module descriptor
with the services, so it can be used on the modulepath At the same
time it also provides a META-INF/services to make it compatible for
the classpath as well. This is awesome to
Le 2024-10-24 à 13 h 17, Robert Scholte a écrit :
(about automatic modules)
What is effectively the difference here? As long as there's no
reference from a module descriptor to a module (either named or
automatic) there should be no difference.
The purpose of automatic modules is to allow th
Le 2024-10-24 à 12 h 07, Robert Scholte a écrit :
Can you explain the problem you're trying to solve? In particular I
don't understand the need for modular-jar and classpath-jar, as
currently both classpath and modulepath are already build up correctly
based on the module descriptors.
The p
Le 2024-10-24 à 07 h 57, Olivier Lamy a écrit :
I wonder if the changes have been ported to surefire and javadoc?
Not yet, but indeed those plugins will also need to be updated. We may
not be able to update them in same time as the compiler plugin. A
consequence is that some tasks that should
Le 2024-10-24 à 08 h 20, Guillaume Nodet a écrit :
Is there any technical reason why we could not port those ?
About MCOMPILER-542 (a workaround that modified the module-info.class
generated by javac versions before Java 22), there is no technical
reason apart a desire to reduce dependencies
Le 2024-10-23 à 16 h 22, Ralph Goers a écrit :
What is the easiest way to determine what has been changed? When I was
working on Log4j’s JPMS support Maven’s handling of JPMS frequently
caused problems and forced us to do some things I consider kind of ugly.
The main changes are described the
Hello Robert
I would be very interrested in participating too. We are in process of
modifying the way than Maven handle module path. Maven 4 already has
some elements giving more controls to the developer.
Unfortunately I didn't had the time to make more progress in the last
month, but I hop
Le 2024-09-25 à 06 h 52, Mateusz Gajewski a écrit :
For me this looks more like an issue of the jar plugin and should
probably be handled there, then even though I wonder why the zip
entries need a timestamp for a jar to be reproducible, should it not
be enough to compare the zip-entries and
Le 2024-09-23 à 12 h 53, Gary Gregory a écrit :
Speaking of collections... In some code bases I review (not here) a
List is often used when a Set would semantically correct. Is there an
opportunity in m3 or m4 for such a change?
Yes, I also though about that. Especially since I have seen cod
Le 2024-09-23 à 12 h 32, Martin Desruisseaux a écrit :
Would it be okay if I modify the implementation with the following goals?
* All setter methods make a defensive copy of the given collection,
preserving Set order.
* All getter methods returns an unmodifiable (but not necessarily
Hello again
In my attempt to add a List to Maven, I got hesitations about
what to do with the following file:
*
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
This class contains many collections, but I'm not sure if they are
Hello
I just realized that there is two "DefaultModelPathTranslator" classes
with almost identical code: one in the "maven-model-builder" module and
one in the "maven-api-impl" module. I presume that one of them is
deprecated in the favor of the other? If so, can we put a @Deprecated
annotati
Le 2024-09-21 à 17 h 45, Tamás Cservenák a écrit :
PR seems ok
https://github.com/apache/maven/pull/1735
@Martin Desruisseaux pls confirm is this what you had in mind?
Yes, this is my guess of what was intended. Thanks!
Martin
Le 2024-09-21 à 16 h 43, Tamás Cservenák a écrit :
AFAIK, as I see, the point is that it nullifies if "default" value is
present, and those come from corresponding super POM? Basically, keep
only the non-default values?
But just above that method, there is another method which performs the
Hello all
I'm starting to work on a prototype using the new build element
(a proposal for a unified replacement for ,
, , etc.) proposed in a previous discussion on
this mailing list. For starting, I'm searching for usages of
in Maven source code and I try to add codes doing
something equi
Hello all
The current Maven Compiler plugin (not the JPMS work) cannot be built
because of compilation errors. A fixed version is available with the
JPMS work (integration tests pass). However, it would require the
following dependencies to be released first:
* maven-plugin-tools 4.0.0-beta
Created a pull request for making "maven-plugin-testing" buildable with
Maven 4.0.0-beta4:
https://github.com/apache/maven-plugin-testing/pull/44
A similar pull request is needed for "maven-compiler-plugin". We could
update the current plugin, or merge the reworked plugin (after
correction
+1 (non-binding)
* Downloaded apache-maven-4.0.0-beta-4-bin.zip
* Checked SHA512
* Used the staging repository for builds listed below
* Used Maven 4-beta4 for building maven-plugin-tools
* Used Maven 4-beta4 for building maven-plugin-testing
o Build fails with "Found Banned Dependency:
Hello
Le 2024-08-16 à 09 h 51, Andreas Sewe a écrit :
Maven has two *orthogonal* ways how to projects can relate to each
other: aggregation and inheritance. (…snip…) I don't think using the
term "Maven sub-project" improves things. In fact, it makes it even
easier to mistake a module (aggrega
Le 2024-08-14 à 09 h 08, Konrad Windszus a écrit :
Module is a quite overloaded term so you always have to specify the context.
For me module without the prefix “Java” doesn’t implicitly mean Java module.
Same would apply for “package”. Is it Java package or Maven package (the
lifecycle phase)?
Hello all
As mentioned in previous emails, I would like to propose a change in
Maven POM. The proposal is to replace (deprecate) all the following
elements:
* resources
* testResources
* sourceDirectory
* testSourceDirectory
* scriptSourceDirectory
* In maven-compiler-plugin configurat
Le 2024-08-08 à 11 h 04, Martin Desruisseaux a écrit :
It would be great to have this summary in the package-info Javadoc,
and also the relevant parts in each interface Javadoc. I will try to
do a PR next weekend for that.
Done as pull request #1640. Relevant commit is:
https
Le 2024-08-09 à 17 h 01, Tamás Cservenák a écrit :
Resolver 1.9.22 and 2.0.1 are out, next are upcoming Maven releases...
please keep eye and review PRs (for both, if possible)
If it includes Maven 4, can we call it "beta" again?
Martin
Hello Guillaume
Le 2024-08-07 à 22 h 23, Guillaume Nodet a écrit :
* ArtifactCoordinate are used to locate artifacts in a repository,
it's basically a pointer to a file in maven repository
* Artifact is the pointed artifact in the repository. They are
created when *resolving* an Art
Le 2024-08-07 à 18 h 25, Guillaume Nodet a écrit :
Can it load non JPMS jars too ?
Yes, as an "automatic" or "unnamed" module.
Martin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands,
Le 2024-08-07 à 17 h 38, Guillaume Nodet a écrit :
Did I miss something ? We need to load plugins at runtime, I thought
JPMS was static…
JPMS can load plugins at runtime as well. However, the way to do that is
very different. It is no longer with ClassLoader, we have to use
ModuleLayer instead
Le 2024-08-07 à 14 h 21, Guillaume Nodet a écrit :
Why do we care ? If we provide a well defined API (with a known set of
jars), people should be aware if they use maven-core jar directly….
It is a matter of reputation for the Maven project. A Murphy law is that
given a sufficiently large am
Le 2024-08-07 à 14 h 26, Guillaume Nodet a écrit :
https://github.com/apache/maven/blob/c0012c08aaad27473770fc39ab7e39026238c7e1/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.1.0.xml#L27
My bad. Re-testing again, I get the warning with Maven 3.9.6 (the
version provided b
Le 2024-08-07 à 13 h 56, Gary Gregory a écrit :
I think COMPAT is going away in Java 23:
https://inside.java/2024/07/11/quality-heads-up/
Thanks for the link. But it seems to be a different `COMPAT`. The above
link mentions only the `java.locale.providers` property value, while the
`COMPAT`
Le 2024-08-07 à 13 h 42, Martin Desruisseaux a écrit :
Note: I would not recommend to change that.
I mean, the fact that the encoding is apparently not specified in the
root POM. I still suggest to remove the warning except on Java 17.
Martin
Le 2024-08-07 à 12 h 49, Guillaume Nodet a écrit :
I thought we set the default encoding in the root pom a while ago ?
Apparently not. The default encoding is ${project.build.sourceEncoding}.
But if this property is not explicitly set in user's project, we get the
warning (tested with Maven 3
Le 2024-08-07 à 12 h 55, Guillaume Nodet a écrit :
I'm not a big fan of reducing the visibility of implementation
classes. The API is well defined, i.e. all org.apache.maven.api.*
packages.
It is because while the API does not expose Eclipse Aether, the
implementation does. If, in the future
Le 2024-08-05 à 14 h 19, Tamás Cservenák a écrit :
You are on the right track and Guillame and I had a lot of discussions
about this. IMO, best would be to wait for him (is on PTO I think) and
have a chat face to face?
Yes I'm fine with a talk. I'm available most time of the day (except
toda
Hello Olivier and all
Le 2024-08-05 à 19 h 37, Oliver B. Fischer a écrit :
I would say the term module is totally fine. We have, as everywhere in
our human word, a lot of homonyms, everythere.
Yes, this is recognized in both the current documentation and the change
proposal. The documentatio
In order to avoid confusion between "Maven module" and "Java module", I
suggest to update documentation for using "Maven sub-project" instead of
"Maven module". However, the XML elements in the POM would be
unchanged for compatibility reason. There is apparently not so many
places in the docum
Le 2024-08-05 à 14 h 07, Martin Desruisseaux a écrit :
* Optional getModuleModuleDescriptor()
Typo: should be getModuleDescription(). It was a copy-and-paste error.
Martin
In Maven 3, if the configuration parameter or the
"project.build.sourceEncoding" property is not set, the compiler emits a
warning like below:
> File encoding has not been set, using platform encoding UTF-8, i.e.
build is platform dependent!
However since Java 18, the default encoding in a
Hello all
The proposed maven-compiler-plugin version 4 now passes the integration
tests. It has reached a state where it could (theoretically) be used
instead of version 3, but there is probably some more bugs to discover.
Many tests had to be modified, and a few of them have been deleted. The
I created a pull request for Maven core which fixes the issue that the
new maven-compiler-plugin was facing (the confusion between "jar" and
"test-jar"). With this fix, I'm starting to be able to compile the
projects in my company with the new compiler.
https://github.com/apache/maven/pull/
Le 2024-07-23 à 10 h 50, András Péteri a écrit :
Class "org.eclipse.jdt.internal.compiler.tool.EclipseCompiler" does
implement this interface (…snip…) name() is a default method on
javax.tools.Tool and this implementation leaves it as-is, so it will
return an empty String.
Looks good. I al
Le 2024-07-23 à 05 h 20, Olivier Lamy a écrit :
How to use ecj with those changes? Or any other external tool by using
the executable configuration?
The compiler needs to implement the following interface (I think it is
the case of the Eclipse compiler, but didn't verified carefully):
j
Le 2024-07-23 à 01 h 21, Guillaume Nodet a écrit :
FWIW, I started working on an API derived from the takari incremental
build. This is available at [1] with usage snippets available at [2].
But the API is much more complex that just a status flag but it would
allow automatically skipping any
Le 2024-07-23 à 01 h 15, Guillaume Nodet a écrit :
Awesome work ! Does ECJ implement javax.tools API too ?
Thanks! I did not tested the Eclipse compiler, but from my search on
internet, I got the impression that yes it implements the javax.tools
API too. If not the case, it should be possibl
Le 2024-07-22 à 21 h 14, Romain Manni-Bucau a écrit :
you must not skip surefire is compiler execution is skipped. Surefire
has its own inputs and even if the overlap with compiler can be
important it is also far to be 1-1 (…snip…) surefire can have custom
paths, must consider the env, props
1 - 100 of 229 matches
Mail list logo
