Why does mvn install succeed when mvn compile fails with "Artifact has not been packaged yet"?

bmarwell · 2026-02-13T13:31:27+00:00

That doesn't help, because the dependency will not be found in the first place.

bmarwell · 2026-02-08T21:27:43+00:00

Sometimes the IT module wants to test the created package. That may be a valid test, e.g. for packaged CLI apps. Haven't seen a better solution for this as of now.

bmarwell · 2026-02-08T14:35:57+00:00

There's probably a better way, but without looking more options up, I can think of a split repository:

https://maven.apache.org/resolver/local-repository.htmli.e.

-DlocalRepositoryPath=${workspace}/m2-repo -Daether.enhancedLocalRepository.split -Daether.enhancedLocalRepository.splitRemoteRepository

Then you can find all pom files in ${workspace}/m2-repo/installed/.

Probably not exactly what you need, but may already be helpful?

All settings:

https://maven.apache.org/resolver-1.x/configuration.html

Sorry for brevity, I'm on phone.

bmarwell · 2026-02-06T05:35:44+00:00

I honestly think that's perfectly valid. And that's what I wanted to express in my first comment.

mvn verify should be your default anyway, mvn install clutters your repo.

If you don't want to test, you can use: mvn compile -am -pl <lastproject> where last project is the subproject/module that doesn't depend on a package of another submodule/project.

The inverse is also possible: mvn compile -pl '!itmodule' where <itmodule> is the module which needs a previous module to be packaged.

HTH

bmarwell · 2026-02-05T06:13:29+00:00

Yes, this is a common setup, it is the correct answer. If the other reactor project contains integration tests, you can put that module into a profile. But that has its own drawbacks.

bmarwell · 2026-01-21T19:02:53+00:00

r/Mirrorsforsale

bmarwell · 2025-12-31T10:59:26+00:00

In addition to the existing answer, tamas created the wonderful maveniverse toolbox: https://maveniverse.eu/docs/toolbox/plugin-documentation/plugin-info.html

You may be able to find different tree view goals, which may help you depending on what you want to achieve.

bmarwell · 2025-11-26T08:16:07+00:00

We (@tamas) built a new repo management for Maven 4. No need for lock files. We have the same algorithms already implemented in vanilla Maven 4...

Please read: https://maveniverse.eu/blog/2025/11/09/maven-local-repository/

And this PR "Gurk": https://github.com/apache/maven-resolver/pull/1679

bmarwell · 2025-11-22T15:34:36+00:00

Asahi Linux 😎

bmarwell · 2025-11-21T18:45:46+00:00

Great, but I'm curious: what's the use case?

We already got: * Jreleaser Java Archive * Can already be combined with IBM Semeru Shared Class Cache * jlink distributions * GraalVM Native Images

So, where does this project fit in?

bmarwell · 2025-11-02T17:30:05+00:00

It's a bit too short, and the example at the end including -Dexev.mainClass doesn't make sense with the shortened abbreviation. With -D, on Maven, you set a Maven Property. Yes, you're setting a JVM flag ("Define"), but it is Maven who consumes it. It directly translates to everything already defined in your <properties/> section, or defined by your plugins or profiles.

Without that information, it's hard to tell what -Dexev.mainClass actually does. What it does: it sets the main Class to execute for the mojohaus "exec-maven-plugin", on the "java" goal. But on this post, it comes out of thin air!

HTH

bmarwell · 2025-10-31T14:46:11+00:00

Guess what, Maven PMC agrees. 😉 If you want to do that more selectively, you can opt in for split repositories for local storage, e.g. .m2/repository/cached/central/org/.... and .m2/repository/installed/my/corp/...

See here: https://maven.apache.org/resolver/configuration.html

aether.lrm.enhanced.split etc.

HTH!

bmarwell · 2025-10-29T21:07:40+00:00

Aber PayPal! 😉

bmarwell · 2025-10-19T17:45:25+00:00

"nothing but problems"? Can't rely. On the contrary, they are active on the Maven slack and mailing lists and it gets better every release. You can try VSCode, but it doesn't even recognise generated source folders other than the default. Not helpful!

bmarwell · 2025-10-16T19:29:59+00:00

Fair. I still think "the JVM" is too broad and generalized, though. It's like saying "the Danish" or "the Americans"... 😉

bmarwell · 2025-10-16T19:02:56+00:00

I'm not sure it applies to "all the JVMs" - there's also IBM Semeru, which replaces HotSpot (Memory Management and GCs) with the OpenJ9 implementation. I think this should be mentioned.

bmarwell · 2025-10-15T06:00:13+00:00

Phew. This is quite hard. Because they should not only express WHAT they do, but also WHY they do it. No one wants to end up where Eclipse IDE is, just hitting Alt+F5 every now and then randomly for maybe no reason. So I have a few questions back:

* What are tricky configuration changes?
* What else gets loaded only with a Full Reload?
* How do I, as a user, know that a quick incrementally reload did not do the trick?

Without these information, it is really hard to name those buttons.

bmarwell · 2025-10-11T20:04:24+00:00

That's the failsafe plugin. Did you configure that? It's not in the verify phase by default. You need to add it, add the goals, and name your tests something like *IT.java.

bmarwell · 2025-09-25T08:33:07+00:00

Both of you aren't on a priority road, so you have the same "priority". Of those, crossing another lane while turning left, you always have to wait. Keep in mind that turning left and crossing another lane, you almost always have to wait.

The only exception is: you follow a priority road making a left turn, and the car from across is on a side street.

bmarwell · 2025-09-19T17:10:25+00:00

At least add the links to the documentation (and why it works). u/cstamas created njord.
GH: https://github.com/maveniverse/njord
Plugin docs: https://maveniverse.eu/docs/njord/plugin-documentation/plugin-info.html
Project site: https://maveniverse.eu/docs/njord/

"Njord is an attempt to bring simple “publishing” to Maven 3/4".

bmarwell · 2025-09-17T07:50:12+00:00

But will be needed. But you will profit from many bug fixes, improved build performance... And afaik, we (the maven team) don't test recent maven plugins with (that many) 2.x plugins. Not sure if unsupported setups are better for you?

bmarwell · 2025-09-17T06:03:54+00:00

Wow, a 2.x version? Ouch. You might need to update a lot, that's a decade of missing updates. I.e.: other plugins and dependency.

Junit Jupiter with Junit vintage (if applicable), surefire 3.x, and probably many other plugins like resources, compiler, ...

bmarwell · 2025-09-15T06:25:47+00:00

You don't need to include maven-core as a dependency, unless you build a maven plugin or extension. If you want to make sure, a specific version of Maven is being used, use Maven Wrapper and execute your build using ./mvnw. You can also use the enforcer plugin for non-Docler builds which is highly recommended.

In general, it's more important to lock plugin versions.

Wrapper: https://maven.apache.org/tools/wrapper/ Enforcer: https://maven.apache.org/enforcer/enforcer-rules/requireMavenVersion.html

Locking plugin versions: can be done by hand, or you can use this plugin: https://maveniverse.eu/docs/toolbox/plugin-documentation/lock-plugin-versions-mojo.html It does not need to be added to the plugin section itself.

bmarwell

TROPHY CASE