Richard Schmidt wrote:
> I am new to maven, NetBeans 13, and gluon and graalvm. I just created a a
> gluon javafx project for desktop platform. I needed to add a dependency to
> POM.XML file for org.openjfx, javafx-web. Most of the time I get the “could
> not find artifact” javafx-web. Once in
I am new to maven, NetBeans 13, and gluon and graalvm. I just created a a gluon
javafx project for desktop platform. I needed to add a dependency to POM.XML
file for org.openjfx, javafx-web. Most of the time I get the “could not find
artifact” javafx-web. Once in a while it works, but not for lo
Hello,
I think you can’t publish ranges to central, but yes if a dependency has a
range each built will resolve the Version new, and unless there is a mother
dependency fixing the version you get the latest one in that range from your
repo.
As others said, just don’t use ranges.
Gruss
Bernd
-
Another question, if the published pom has a range:
Published pom:
com.hp.cp.dfe.shared
common-types
[1.0,1.1)
Does that mean when another maven build that depends on this will select the
latest available common-types in that range, not the one that was used
I suspect you could use dependency plugin and copy dependencies goal to pin
them for now and store the produced archive somewhere for now.
On Thu, Apr 14, 2022, 17:24 Creager, Greg
wrote:
> Thanks for all the quick responses, greatly appreciate it. I’ll have to
> work with our architects and see
Thanks for all the quick responses, greatly appreciate it. I’ll have to work
with our architects and see if I can steer them away from this, build
reproducibility is highest priority.
Thanks again
From: Mark Derricutt
Sent: Wednesday, April 13, 2022 4:49 PM
To: Maven Users List
Subject: Re: D
Alexander Kriegisch wrote:
> A personal note: I am trying to keep my hands off version ranges. I am
> not sure the assumed flexibility is worth the trouble of using it and
> running into the same issues as you. It also potentially creates a huge
> matrix of possible dependency version combination