Hello all
Do we have a mechanism (e.g. notification by email) for watching if an
artifact staged for deployment at Maven Central contains classes in
packages of another project? More specifically, the "opengis.org" domain
name is owned by the Open Geospatial Consortium (OGC). This organization
Hello
I'm trying to port an existing Maven plugin from JDK8 to JDK9, but got
an error message which seems to be related (if I interpreted correctly)
to the way Maven classes are distributed in packages. My Maven
dependencies are:
org.apache.maven
maven-core
3.5.0
Le 27/04/2018 à 10:27, Robert Scholte a écrit :
> IMO this will overcomplicate things and I don't see the real benefits
> of it.
>
Indeed it would complicates plugins, but conversely doing nothing
complicates the use of standard Java tools. For example Maven can not
yet generate aggregate javadoc
Hello Robert
Le 30/04/2018 à 21:00, Robert Scholte a écrit :
> All seems to fall back to an issue with the maven-javadoc-plugin. What
> if we try to fix that first?
>
That would help a lot. Getting Maven javadoc:aggregate goal to work
would address maybe 95% of the needs. But Javadoc is not the
Alternatively, would the following addition in Maven plugins be acceptable?
maven-compiler-plugin
-
If the plugin find module-info.java in the root source directory or does
not find that file at all, behave as today: javac is invoked with
--source-path option set to
Hello all
Note: this email mixes two issues: Java 9 support and support of
languages other than Java. I discuss those two issues together because
the proposed experiment tries to address them together. This email is
also reworded as a wiki page at [1].
Last April we had an email thread about
Hello Robert
Thanks for your reply
Le 24/04/2018 à 19:44, Robert Scholte a écrit :
> On Tue, 24 Apr 2018 13:00:27 +0200, Martin Desruisseaux
> <martin.desruisse...@geomatys.com> wrote:
>
>> * We now have two conflicting conventions: Maven and Java 9. (…snip
Hello all
The Maven folder structure differs from the folder structure expected by
standard javac and javadoc tools:
* *Maven:* /src/main/java//
* *Java:* //
I understand that Maven can still build a Java 9 project by compiling
each module with a separated invocation of javac, and I have
Le 2023-09-02 à 21 h 15, Henning Schmiedehausen a écrit :
This is the piece that really makes me sad. We tend to get lost in
"rightness" discussions and don't show pragmatism.
In this case we have an opinion-free, objective criterion: make possible
to pass to Java tools (java, javac, javadoc…)
Hello
Le 2023-09-03 à 06 h 15, Romain Manni-Bucau a écrit :
The thing is you can't rely on the pom to know if you use a JPMS or
not module cause most libs will not fill that and even if, then you
never know if consumer wants that.
The POM change proposal is not for specifying if a dependency
Le 2023-09-04 à 16 h 44, Romain Manni-Bucau a écrit :
I'd say open issues for the related plugins, several are known to be
used (not sure about javadoc but others should).
Is the class-path/module-path management duplicated by all modules? I do
not know Maven internal, but I though that it
A possible improvement to Maven default behaviour (when no option is
provided by the user) could be as below. The current rule followed by
Maven is to put a JAR on the module-path if and only if the two
following conditions are true:
1. The JAR is JPMS
2. The application using that JAR is
Le 2023-09-12 à 07 h 16, Henning Schmiedehausen a écrit :
Maven spends a lot of time trying to deal with corner cases and I am
not sure that we get them right.
The thing is that putting a JAR on the module-path versus class-path can
change application behaviour, no matter if JPMS or not.
Hello Henning
Thanks for sharing your experience. I agree that migrating a Maven
project to JPMS can be difficult, and in some cases impossible with
Maven (but possible with Gradle). However I believe that it is a Maven
problem rather than a JPMS issue. JPMS is quite pleasant to use on the
Le 2023-09-03 à 16 h 53, Romain Manni-Bucau a écrit :
Think command line tuning is already possible.
This if true for many parameters, but not for class-path / module-path
as far as I can see. It is easy to add parameters that were not added by
Maven. But it is difficult to change parameters
Le 2023-10-28 à 22 h 54, Tamás Cservenák a écrit :
I still see these just as new dependency types: "module", "agent",
"doclet", and so on.
Does "dependency type" means the element inside ? If
yes, then specifying a different type causes Maven to download a
different JAR, without changing
Le 2023-10-29 à 21 h 36, Romain Manni-Bucau a écrit :
Was referencing the options using module names, if you drop the dep or
reference a package not supported by the module we should be able to fail.
I do not want to distract this thread from the core issue (control on
class-path versus
Le 2023-11-02 à 10 h 49, Romain Manni-Bucau a écrit :
this assumes all plugins + runtimes will use the exact same option
whereas this is generally not true so must be configured per mojo when
forking and in jvm.config when not forking so I don't see any work
done at dependency/artifact level
Le 2023-11-02 à 11 h 21, Romain Manni-Bucau a écrit :
you are right they are orthogonal in terms of design but as soon as
you get the set notion you don't need the others and I prefer to not
multiply the way to do which is always confusing.
It is not necessarily a multiplication of ways of
Le 2023-11-02 à 12 h 53, Romain Manni-Bucau a écrit :
You would also note that using "type" *forces* users to care about
this separation too in an unexpected way.
Type is an optional element. The use of module is a
workaround for the heuristic rules sometime doing the wrong choice. But
Le 2023-11-02 à 17 h 35, Romain Manni-Bucau a écrit :
Now, do the same example but with app in a classpath centric build
(spring boot, EE, ...) which consumes lib1 as a classpath jar even if
it is a module in its original pom (perfectly valid).
Consuming lib1 on the classpath is *not*
Le 2023-11-02 à 20 h 07, Romain Manni-Bucau a écrit :
as of today libs can't ignore classpath cause it stays the majority of
consumers so it is "as if" in this thread IMHO.
Maven can't ignore classpath. But for artifact producers, it is up to
them to decide. They may target a niche market.
Le 2023-11-03 à 16 h 45, Romain Manni-Bucau a écrit :
The detail point you forget is that since this is a partial solution
either nobody cares of it today and it will not be adopted more than
today (more later on that) or it will break in the future
Is the proposal only partial because it
Le 2023-11-03 à 19 h 33, Romain Manni-Bucau a écrit :
putting a dependency on the module-path of a non-JPMS application
such as Spring is okay
Is not ok for me and is a big hidden bug of current guess logic when
not disabled IMHO, we should drop all that guess code probably.
The current
Le 2023-11-02 à 00 h 31, Tamás Cservenák a écrit :
Here is where I am currently:
https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support
It seems that I cannot add comment on that page, so below are my proposals:
1) Modify the explanation of the "jar" type. It
Le 2023-10-29 à 00 h 21, Tamás Cservenák a écrit :
Unsure from where you get that, but is wrong conclusion.
Declaring a dependency with test-jar causes Maven to
download a different JAR file. So I assumed that it was a general
behaviour. However looking at the link you provided [1], it seems
Le 2023-10-29 à 16 h 54, Tamás Cservenák a écrit :
History shows that having lengthy ML discussions usually dies off into
silence. I think we could use Google Meet, where the 60min limit is
actually even welcome, to not get into marathon meetings and stay
focused (or continue on the next
Le 2023-10-29 à 16 h 10, Tamás Cservenák a écrit :
The current draft of types we want to introduce (and packaging):
https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
Thanks! I fully support this proposal, as I believe it can resolve the
most blocking issue in using JPMS with
Le 2023-10-29 à 20 h 58, Romain Manni-Bucau a écrit :
Is it really different since part of options are related so either we
align on the jvm making using maven location mapping easier or we
fully integrate but means we must detect errors in options which is
for me a hard task
Why do we
Le 2023-10-29 à 18 h 05, Romain Manni-Bucau a écrit :
*type* is not a good solution for jpms, only dependency can help
Since we are talking about specifying the type of dependencies, I do not
understand well what would not work exactly?
One thing that we may need is a way for a dependency
Le 2023-10-29 à 21 h 25, Romain Manni-Bucau a écrit :
Then you are back to the dependency set solution which is not the type
solution and in this option the type is fully useless.
Maybe we would need a wiki page explaining how the DependencySet
approach would apply to JPMS. At this time, the
Le 2023-11-03 à 21 h 30, Romain Manni-Bucau a écrit :
The proposal would put the dependency on whatever path the
said it should be.
Means you create as much type as plugin*pathTypePerPlugin, looks overkill.
The current set of new path types would contain about 6 types (class,
module,
Le 2023-11-04 à 13 h 47, Romain Manni-Bucau a écrit :
How does an artifact has 2 types (it is the main issue with this design)?
I also thought about that. For an initial version, Tamas's proposal
would work. For a solution that avoid repetition, maybe should
allow a comma or
Le 2023-11-04 à 14 h 02, Tamás Cservenák a écrit :
What would a dependency type=jar, sources be? That represents two
different files...
Okay, it makes sense to avoid multi-types then. On a second though, even
when the file is the same, some types are mutually exclusive (e.g.
"classpath"
Le 2023-10-20 à 20 h 43, Romain Manni-Bucau a écrit :
that said, on my side, not sure JPMS will be widely adopted anytime
soon so can be a false problem.
I think that this is a chicken-and-egg problem: some peoples renounce to
JPMS because tools support is poor (at least in Maven and
Le 2023-10-23 à 11 h 28, Romain Manni-Bucau a écrit :
anyway, if we go with the "usages" path we can want to enable a
definition containing wrapped in a
scope () this way you
can reference a dependency set in a plugin or even main dependencies
(import all).
Maybe, but the element
Le 2023-10-23 à 11 h 48, Romain Manni-Bucau a écrit :
(…snip…) but still, I don't think we need that for the mentionned issue.
For agents, alternatives have indeed been proposed in this thread. But
some form of usage specification (either as element or
composition) will be needed anyway at
Hello again
What about the following proposal for addressing MNG-7855?
* Long term solution would be to change the POM model by expanding the
section for controlling on an individual basis how to
handle each dependency.
* Short term solution would be to add a configuration element in
Le 28/08/2023 à 14:24, Martin Desruisseaux a écrit :
Rational: a direct dependency may be known to be compatible with both
the class-path and module-path (e.g. it may duplicate "module-info"
into "META-INF/services/"), but maybe some transitive dependencies are
not
Le 28/08/2023 à 13:30, Elliotte Rusty Harold a écrit :
> On Mon, Aug 28, 2023 at 8:49 AM Martin Desruisseaux wrote:
>> * Long term solution would be to change the POM model by expanding the
>> section for controlling on an individual basis how to
>> handle eac
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
Le 2024-02-21 à 10 h 40, Xeno Amess a écrit :
I use toolchain for multi-release-jars please don't drop it or provide
another way for building multi release jars
I hope to make a proposal as a side-effect of a "Module Source
Hierarchy" proposal, when we will reach that point (after control
Le 2024-02-07 à 00 h 37, Gary Gregory a écrit :
I have no use for JPMS today, I just don't want it to get in the way,
which is impossible since there is no --dont-bother-me-jpms flag...
That option exists at the level of the proposed Maven 4 API and has a
JUnit test [1]. Plugins have the
Hello
Le 2024-02-06 à 16 h 11, Hunter C Payne a écrit :
Nobody wants Jigsaw and the API improvements aren't enough to get
people to upgrade.
I cannot debate on whether a small minority, or a big minority, or a
majority of developers want JPMS (a.k.a. Jigsaw), because I have no data
for
Hello
Le 2023-12-19 à 10 h 10, Tamás Cservenák a écrit :
These are all good questions. Ideally I'd not touch maven-artifact,
rather all should be usable with the new Maven API. For example: in
new Api there is Project, and DependencyResolver service, it does not
help? (by revealing
Hello all
I would like to continue to work on JPMS during the weekend, but I'm
facing a blocking issue. How can I get the DependencyProperties of an
aftifact from the MavenProject class? The problem is that MavenProject
uses the Artifact interface from the "maven-artifact" module, while
Hello Romain
Le 2023-12-19 à 18 h 07, Romain Manni-Bucau a écrit :
I fully understand that but my point - same as last time - is that
"modular-jar" does not give you the information you want, ie
"classpath for compiler, module for javadoc, resolved for tests" for
example.
As Tamas said, I
Le 2023-12-19 à 18 h 24, Romain Manni-Bucau a écrit :
compilation: either make things simple or just enable to compile part
of the code which does not use modules (does not prevent to compile
with module meta)
I'm not sure what "enable to compile part of the code which does not use
Hello all
Thanks Tamás for the review.
Le 2023-12-06 à 11 h 50, Tamás Cservenák a écrit :
Still, these changes are not mandatory anymore, as the properties
makes these extensible (and the isXXX method are "just" shortcut methods).
The problem is that the MavenProject class (the main
Le 2023-12-11 à 16 h 59, Tamás Cservenák a écrit :
no, old stuff (Maven3) should not be touched.
Understood, but all the proposed changes are about Maven 4. The question
stay the same:
* Need a way to make DependencyProperties accessible from MavenProject
* Proposing to add
Hello all
Following the recommendations in the "Guidance on Maven 4 API issue"
thread, I refactored the proposal. The new commits (only 2 at this time)
replace the previous ones.
Commit 1
The first commit [1] adds the following constants in the API:
* In Type interface: POM, JAR,
Le 2024-01-02 à 17 h 44, Martin Desruisseaux a écrit :
(…snip…) First, the (class, module, etc.)-paths, later the source
directories (I wish Maven supports Module Source Hierarchy), in which
case I will try to address multi-releases in same time.
Actually, I have been silent on this topic
Hello Romain
Le 2024-01-02 à 18 h 16, Romain Manni-Bucau a écrit :
In other words you deprecated isAddedToClasspath cause it was too
rigid to put in place something as rigid which enables one rare
(today) case so I'm not very enthusiatic about it.
The proposed replacement is not as rigid,
Hello David
Le 2024-01-02 à 17 h 36, David Lloyd a écrit :
Apologies if this was already covered somewhere else, but would (or
could) path accumulation support multi-release JAR layouts for all
cases (whether it be modular or class-path JARs or filesystem paths)?
The current proposal does
Le 2024-01-02 à 20 h 51, Romain Manni-Bucau a écrit :
RMB: so you mean you don't intend to link the classpath to the type?
Not directly. The code dispatching JAR files between classpath,
module-path, etc., bases fully its decision on the following:
* DependencyProperties
* Sometime
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
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
Le 2024-01-03 à 09 h 08, Romain Manni-Bucau a écrit :
(…snip…) just to answer trivially to "But if an artifact is included,
it should (at least by default) always be placed consistently on the
class-path or module-path.", it is obvious it is not the case for
several plugins like surefire
Le 2024-01-03 à 12 h 08, Romain Manni-Bucau a écrit :
I would like to see a proof in the form of an "hello world"
application (…snip…)
Yot got some on github.
Can you share the URL?
defaulting on the classpath is fine only if the library developers
applied workarounds (…snip…)
The
Le 2024-01-03 à 16 h 45, Romain Manni-Bucau a écrit :
maven4 introduces the notion of "services" (...snip...) So guess all
is there to do it and core can stay as this for backward compat
(maven4 must support maven3) but nothing more.
Current services are class-path aware, with
Le 2024-01-03 à 15 h 19, Romain Manni-Bucau a écrit :
I can agree with that so let's move it in a plugin related code maybe?
The call is on core Maven developers. If Tamas (or someone else) moves
everything related to class-path to another location, I will follow. But
I think it would need
Le 2024-01-03 à 17 h 15, Romain Manni-Bucau a écrit :
see it as "where classpath is in core comes from the time maven was
only for java libs" (i'd say maven 2 cause I don't know maven 1).
The CLASSPATH_CONSTITUENT property and related isAddedToClasspath()
methods were added in Maven 4. I let
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
Le 2024-01-10 à 14 h 45, Tamás Cservenák a écrit :
I really like what I see here. Can you make a PR out of it?
Sure, I can create the PR and the JIRA tasks in the next few days. Do we
exclude (for now) the last commit, if the type names need discussion?
I will also need to add test cases
Le 2024-01-09 à 16 h 57, Tamás Cservenák a écrit :
Thanks for your effort, I will take a peek at this soon.
Thanks. Note that commit 1 can be ignored (it is only cleanup), and
commit 2 (refactoring of DependencyProperties) could be omitted as well
if PathTypes were provided directly as a
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
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
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
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
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
Le 2024-01-10 à 15 h 01, Tamás Cservenák a écrit :
IMO, add all. I think is fine, but PR discussion will decide anyway...
Created a JIRA task [1] and a pull request [2] after rebasing behind
latest Maven commit.
Note 1: the guideline shown when creating the pull request suggested to
put the
Just saw that the CI build has been successful on Java 17 and 21, but
failed on Java 11 because of the use of the |{@return ...}| javadoc tag.
This is a trivial Javadoc issue only. Its resolution depends on Maven
PMC decision about which Java version to require.
Martin
Le 2023-12-19 à 15 h 30, Romain Manni-Bucau a écrit :
Side note: the api is similar for the plugins you mentionned but it is
not the same since you can want to compile with everything on the
classpath, (…snip…)
Some developers may want to put everything on the class-path at
compile-time,
Le 2023-12-19 à 14 h 12, Guillaume Nodet a écrit :
Sure, but you asked for an API, there's none so far.
Right, thanks for the information, it is really useful for putting me on
track.
I'm not sure what kind of API we could offer, as this depends on what
you want to build. If you build an
Le 2023-12-19 à 11 h 36, Guillaume Nodet a écrit :
Ideally, you'd only focus on org.apache.maven.api.* and forget about
everything else. That's the Maven 4 API and all other things are not
part of that API (including MavenProject). The class path resolution
should be done using the following
Le 2023-12-19 à 13 h 32, Guillaume Nodet a écrit :
result.getPaths().stream().map(Path::toString).collect(Collectors.joining(":"))
This is more complicated than that. From a set of dependencies, we need
to dispatch them between class-path, module-path and --patch-module
option (the latter
Started proposed changes in a Maven clone (work in progress). Highlights:
* In the DependencyProperties interface, added a
FLAG_MODULE_PATH_CONSTITUENT in complement to the existing
FLAG_CLASS_PATH_CONSTITUENT [1].
* Added corresponding isAddedToModulePath() methods and
Le 2023-12-04 à 17 h 50, Tamás Cservenák a écrit :
(…snip…) parts made from that "experiment" is already merged to maven
master: https://github.com/apache/maven/pull/1299
This now allows to _implement_ what we envisioned with "JPMS experiment"
BUT:
it would work only with use of the new
Hello
One month ago we had a thread named "Maven 5 pom extension for agents"
which also covered JPMS. During that thread, Tamás created a confluence
page [1] (thanks!). That page references a GitHub repository with a
modified Maven [2]. However, the latter now produces an error 404. Has
the
Le 2024-01-22 à 09 h 52, Hervé Boutemy a écrit :
are there known features in Maven 4 API not available in Maven 3 that
would bring stronger interest in writing a goal for Maven 4?
If accepted, the way to determine where to put dependencies (class-path,
module-path, etc.) would require Maven
Hello
I would like a little clarification about the Java version for Maven 4.
I saw debate on this mailing list, but has a decision been reached? I
got the impression that Maven 4 would require Java 11, but last time I
checked, the pom.xml file was still declaring Java 8 as the target. If
Hello
From the replies in this thread, it seems to me that there is a
consensus for moving Maven 4 to some Java version after 8. I see:
* 0 in favour of Java 11
* 1.5 in favour of Java 17 (the .5 is because I split a vote between
Java 17 and 21)
* 2.5 in favour of Java 21
* 4 seem
Le 2024-02-03 à 16 h 25, Michael Osipov a écrit :
I still don't understand what non-problem you are trying to solve
here?! I think that your time and our time would be better invested in
solving real problems, just look into JIRA how many issues have piled up.
For the Java version topic, it
Le 2024-03-04 à 00 h 31, Pavel Horal a écrit :
isn't System.Logger mainly for JDK internals? I always thought that
using it is in a similar ballpark as using java.util.Optional in
method arguments (i.e. „please don’t“).
System.Logger was needed by JDK internal, e.g. because of bootstrapping
Just realized since I'm working on the Maven compiler plugin, upgrading
to Java 21 instead of 17 would allow us to replace currently
hard-to-read Javadoc like this:
*
* compilerArgs
* arg-Xmaxerrs/arg
* arg1000/arg
* arg-Xlint/arg
*
Le 2024-03-02 à 18 h 55, Jeremy Landis a écrit :
You should be able to use @code in same way now without the java upgrade.
Yes I know. But Maven source code currently uses , and if we were
to spent an effort for changing that, it would have been more economical
to go directly to {@snippet}
Note: this logging issue is not very important. If there is such
resistance against it, I will not insist.
Le 2024-03-04 à 08 h 35, Romain Manni-Bucau a écrit :
Please read
https://docs.oracle.com/javase%2F9%2Fdocs%2Fapi%2F%2F/java/lang/System.LoggerFinder.html
I have already read that. The
Maven 4 defines a new interface, `org.apache.maven.api.plugin.Log`, with
the usual debug(…), info(…), warn(…) and error(…) methods in it. Should
we replace that by `java.lang.System.Logger`? (now possible with Java
17) The latter is also an interface, so we have the same flexibility for
Hello Romain
Le 2024-03-03 à 17 h 02, Romain Manni-Bucau a écrit :
SystemLogger has the ServiceLoader "pick random first" implementation
which is not what we want
You are describing the behavior of the System.getLogger() method. I was
talking about the use of the System.Logger interface.
Le 2024-03-03 à 20 h 38, Romain Manni-Bucau a écrit :
the idea of maven-api was to abstract anything from the implementation
to be able to change
A standard Java interface is as good as a Maven interface for that
purpose if they define equivalent methods, which is the case of
System.Logger
Le 2024-03-03 à 18 h 48, Romain Manni-Bucau a écrit :
(snip) Nothing force us to use System.getLogger() for getting an
instance of that interface. (snip)
Yes but you make something well specified misbehaving so while
technically true I think it would deserve us on the long run.
I do not
Le 2024-03-03 à 22 h 53, Romain Manni-Bucau a écrit :
It is expected to use System so the logger finder. if it is not the
case you broke the contract of this API.
Can you point to the contract saying that?
As a matter of fact it is current state so not sure what you want to
enable.
For
Hello all
I would like to propose a change in the way to specify source directory
in a POM file. Currently, it can be done as below:
foo
I would like to propose a structure more like below (similar to
org.codehaus.mojo:build-helper-maven-plugin:add-source). In this
proposal, I'm
Hello all
I'm not yet ready to submit a pull request for the reworked
maven-compiler-plugin, but I would like to report some details about
changes that would come, if accepted. This work is for Maven 4 only, the
plugin for Maven 3 will stay unaffected.
As proposed on GitHub comment [1], I'm
Hello all
Le 2024-03-18 à 09 h 20, sebb a écrit :
It would be helpful if there was a migration page that explained to
users how to handle settings that are no longer supported. This could
be quoted in the relevant error message.
I started a wiki page summarizing the changes (to be moved
Oups, sorry. The link should be
https://github.com/Geomatys/maven-compiler-plugin/wiki
Le 2024-04-16 à 16 h 50, Martin Desruisseaux a écrit :
Hello all
Le 2024-03-18 à 09 h 20, sebb a écrit :
It would be helpful if there was a migration page that explained to
users how to handle settings
Hello all
The Maven compiler plugin has an boolean
parameter with `true` as the default value. This parameter has issues
discussed in MCOMPILER-209 [1], which has 61 votes. In short, builds are
much faster when this parameter is set to `false`, which is
counter-intuitive. During the
Le 2024-04-23 à 10 h 21, sebb a écrit :
Minor correction: the classes method will necessarily *detect* added
sources, because they won't have a class file. What occurs as a result
is another matter./ It might be worth considering forcing a full build
as an option in such cases if there is
Le 2024-05-04 à 13 h 42, Tamás Cservenák a écrit :
MNG-8041: I moved it out
MNG-8073: done, thanks to Sylwester and Slawek
If not too late, can the following be considered for 4.0.0-beta?
https://github.com/apache/maven/pull/1501
This pull request (PR) contains adjustments to the PathType
Hello Tamas
Thanks for the explanation. Then I will pause the Maven compiler plugin
work for now and resume after the new master branches are ready (I need
to focus on 2 meetings in June anyway). Just for avoiding confusion,
would it be possible to delete the current "mvn4" branches?
Side
1 - 100 of 121 matches
Mail list logo
