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
Hello again
This is a side-effect of the work on maven-compiler-plugin. The
"incremental build" mechanism is reviewed as a side-effect, for fixing
MCOMPILER-209 [1] among others. When the compiler has detected that no
source file, no dependency and no compiler option has changed, is there
awa
Hello all
The work on a new maven-compiler-plugin [1] for Maven 4 has reached the
following state:
* All existing JUnit tests pass
* Integration tests do not yet pass (I'm working on that)
* Plexus compiler dependency completely removed (replaced by javax.tools)
My current issue is that de
Le 2024-07-12 à 19 h 00, Guillaume Nodet a écrit :
I like it a lot. This could also prove very useful to better support
multi-release JARs.
Yes, I had that purpose in mind as well, and multi-releases is one of
the reasons for the proposal. It would also be useful for Module Source
Hierarchy,
Le 2024-07-12 à 15 h 26, Guillaume Nodet a écrit :
I've been working on migrating the build-helper-maven-plugin to the
Maven 4.x API. (…snip…). This plugin in particular is used a lot (to
add generated source/resources and attach artifacts) and there's no
other way to do it. This is essentiall
Hello
Le 2024-07-06 à 20 h 32, Karl Heinz Marbaise a écrit :
First I would like to see more beta versions where we can fix the
issues which are currently existing... and do more thoroughly testing...
I would like the same. To my knowledge, the new API for controlling
class-path versus module
Le 2024-06-14 à 19 h 19, Gary Gregory a écrit :
Yeah, we need clarification, I can't imagine test/verify would be skipped.
I should have said "mvn package for all modules, followed by mvn deploy
for all modules". The package phase include tests if I remember right.
Martin
Le 2024-06-14 à 19 h 11, Gary Gregory a écrit :
Thank you Martin for clarifying this! If I understand correctly: If I
said 'mvn clean deploy foo bar' in a multi-module project, then 'mvn
clean foo bar' happens first for all modules followed by 'mvn deploy'
for all modules?
This is my unders
Le 2024-06-14 à 18 h 28, Gary Gregory a écrit :
Install by default locally is probably OK for devs, especially for
multi-module projects, but deploy by default is a bad IMO.
I believe that Tamas's proposal is not to deploy by default, but *if*
users asked for deployment, then makes it happen
Le 2024-05-21 à 11 h 18, Guillaume Nodet a écrit :
https://github.com/Geomatys/maven/commit/5165ca60a1b44cd2a376cd1bfe48f558a2cbd54f
looks interesting, as the interface was introduced in 4.x branch, so no
need to keep it as it's not used anymore. Feel free to create a proper PR.
Thanks, done.
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 no
Hello all
I'm trying to run the tests on the reworked compiler plugin for Maven 4,
but execution is having an issue with Maven dependency injection. Before
to give more details, I would like to check if I'm up to date.
Three months ago, I was told to use the following branches:
* Maven core
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
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 any
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 refactor
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
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 some
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 u
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
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 i
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
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 t
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 ver
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 und
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. Not
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
customi
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} in
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:
*
*
* -Xmaxerrs
* 1000
* -Xlint
* -J-D
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 on
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 pos
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 back
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 i
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 neutr
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 4
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
Jav
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 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
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 bef
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 Depe
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-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 discu
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 it
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 co
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 pleas
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 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-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 multiple
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 à 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 DependencyProper
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 to
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 oppos
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 (…sni
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 whethe
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, be
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 in
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 no
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, CLASS
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
modules"
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 d
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, oth
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 O
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 may
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
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 properties
1 - 100 of 166 matches
Mail list logo
