On 15/09/2025 19:44, Guillaume Nodet wrote:
Le lun. 15 sept. 2025 à 17:15, Thomas Reinhardt a
écrit :
I think definitly should disable discovery. A list of
submodules *was* specified (with 0 actual submodules).
I agree that would be the most intuitive, however, this information is
Mit freundlichen Grüßen,
Thomas Reinhardt
On 15/09/2025 16:22, Romain Manni-Bucau wrote:
Maybe we can consider empty is defined (even if defined as null) so do not
discover else discover.
Also think the last example is exactly what we do want for maven 4 since if
the module doesn'
only my actually
defined modules/subprojects are considered, right?
Greeings,
Thomas Reinhardt
On 15/09/2025 11:02, Guillaume Nodet wrote:
I just replied on the issue. This is the expected behavior for:
* 4.1.0 models
* which have a `pom` packaging
* which defines no subprojects/mo
You are right, that's what I am using. I guess I looked into that pom to
see what it actually manages and then went on to copy the parent section
from there. Dumb :)
-Thomas
On 20/03/2025 16:59, Filipe Roque wrote:
On Wed, 2025-03-19 at 14:20 +0100, Thomas Reinhardt wrote:
If you need to digest a large 3rd party project you have to "know" all
the internal versions of that project and/or its dependencies in some way.
For example we import com.fasterxml.jackson:jackson-parent which fixes
versions of about 60 artifacts. Of course we don't use all of those but
if
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
limited options or an explosion of all valid com
difference between the MavenXpp3Reader and
MavenXpp3ReaderEx (and the corresponding writer) classes? I was not able
to google anything about those.
Feel free to ignore this mail if you think it is completely offtopic.
-Thomas
Mit freundlichen Grüßen,
Thomas Reinhardt
On 10/02/2025
Interesting, I was not aware of the new discovery mechanism.
Unfortunately the most interesting goal "select-jdk-toolchain" is not
marked threadsafe. Was that a conscious decision or just easier to
implement?
Also I am missing a parameter to provide a search path. Might come in
handy in CI
On 20/10/2023 20:43, Romain Manni-Bucau wrote:
Can be the way to define the lookup, an heuristic will never work by
design...that said, on my side, not sure JPMS will be widely adopted
anytime soon so can be a false problem.
This is a chicken and egg problem. My company would love to use JPMS
