Re: Could not find artifact org.openjfx:javafx-web

[Nils Breunese]

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 a while it works, but not for long. I 
> have tried to use other repositories to get it, but that fails also. Would 
> like to know how to get over this hump. Thanks!

I am not familiar with Gluon or JavaFX, but it seems org.openjfx:javafx-web is 
available from Maven Central [0]. I just tried adding it to one of my projects, 
and Maven downloaded the dependency just fine:


org.openjfx
javafx-web
17.0.2


I wonder what you mean with ’Once in a while it works, but not for long’. Once 
Maven has downloaded a dependency into your local Maven repository, it should 
find it for all next builds, because the dependency doesn’t need to be 
downloaded again.

Nils.

[0] https://search.maven.org/artifact/org.openjfx/javafx-web
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Could not find artifact org.openjfx:javafx-web

[Richard Schmidt]

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 long. I have tried 
to use other repositories to get it, but that fails also. Would like to know 
how to get over this hump. Thanks!

Sent from Mail for Windows

Re: Determine Maven Dependencies after a build

[Bernd Eckenfels]

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
--
http://bernd.eckenfels.net

Von: Creager, Greg 
Gesendet: Thursday, April 14, 2022 5:37:21 PM
An: Maven Users List 
Betreff: RE: Determine Maven Dependencies after a build

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 for that 
build? (my hunch is yes, constant moving target)

-Original Message-
From: Nils Breunese 
Sent: Thursday, April 14, 2022 2:01 AM
To: Maven Users List 
Subject: Re: Determine Maven Dependencies after a build

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 combinations which might or
> might not play nice with each other. How can you ensure to run your
> tests on all of them? Sometimes, there is a bug which affects you in
> 2.5.3, but not in 2.5.2, and quickly fixed in 2.5.4. Maybe you did or
> did not notice that it even exists. Then suddenly, someone uses the
> buggy version, and the software does not work despite green tests.

I would indeed also recommend to not use version ranges, and using a tool like 
Dependabot or Renovate to keep your dependencies up-to-date.

Nils.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Determine Maven Dependencies after a build

[Creager, Greg]

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 for that 
build? (my hunch is yes, constant moving target)

-Original Message-
From: Nils Breunese  
Sent: Thursday, April 14, 2022 2:01 AM
To: Maven Users List 
Subject: Re: Determine Maven Dependencies after a build

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 combinations which might or 
> might not play nice with each other. How can you ensure to run your 
> tests on all of them? Sometimes, there is a bug which affects you in 
> 2.5.3, but not in 2.5.2, and quickly fixed in 2.5.4. Maybe you did or 
> did not notice that it even exists. Then suddenly, someone uses the 
> buggy version, and the software does not work despite green tests.

I would indeed also recommend to not use version ranges, and using a tool like 
Dependabot or Renovate to keep your dependencies up-to-date.

Nils.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Determine Maven Dependencies after a build

[Mantas Gridinas]

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 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: Determine Maven Dependencies after a build
>
> I don’t believe there currently is a way for this is native maven.
>
> We ended up writing a custom tool/mojo for resolution management using a
> DSL like:
>
> repository https://repo1.maven.org/maven2/
> as central;
>
> resolve highest org.antlr:antlr4-maven-plugin:[4.10,5.0.0) via central;
>
> locked org.antlr:antlr4-maven-plugin:4.10;
>
>
> Which tracks the repositories to check, a range to resolve, and what was
> resolved/locked ( also tracking deprecated/blacklisted dependencies ).
>
> These pom.deps files get attached as artifacts and can be subsequently
> imported in downstream repos:
>
> repository https://nexus.az1.smxk8s.net/repository/maven-public-group;<
> https://nexus.az1.smxk8s.net/repository/maven-public-group;>
>
> import groupId:artifact.bill-of-materials:3.3.150;
>
> locked org.antlr:antlr4-maven-plugin:4.10;
>
>
> From here, the actual pom.xml files are rewritten with
> [4.10] references - locking the build to a specific,
> locked range version ( for extra banality we also automatically add
>  on * to prevent transitive dependencies.
>
> This definitely has problems, but also have benefits and certainly made hot
> fixes much easier to handle when we had different deployments staggered
> into production between customer sites.
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
>
> On 14/04/2022 at 6:25:47 AM, "Creager, Greg"  >
> wrote:
>
> > I am trying to reproduce a build that was done a week ago. Our maven pom
> > files use range in many places ([1.0,1.1), when I go look at the pom of
> the
> > published project, it just shows the range, not the actual version
> chosen:
> >
> > Published pom:
> > 
> > com.hp.cp.dfe.shared
> > common-types
> > [1.0,1.1)
> > 
> >
> >
> > How do I determine exact versions of dependencies used in a prior build?
> > In Apache ivy the published ivy.xml shows the exact version chosen, I was
> > expecting maven to have the same and I am assuming I just am not using
> the
> > right util.
> >
>

RE: Determine Maven Dependencies after a build

[Creager, Greg]

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: Determine Maven Dependencies after a build

I don’t believe there currently is a way for this is native maven.

We ended up writing a custom tool/mojo for resolution management using a
DSL like:

repository https://repo1.maven.org/maven2/ as 
central;

resolve highest org.antlr:antlr4-maven-plugin:[4.10,5.0.0) via central;

locked org.antlr:antlr4-maven-plugin:4.10;


Which tracks the repositories to check, a range to resolve, and what was
resolved/locked ( also tracking deprecated/blacklisted dependencies ).

These pom.deps files get attached as artifacts and can be subsequently
imported in downstream repos:

repository 
https://nexus.az1.smxk8s.net/repository/maven-public-group;

import groupId:artifact.bill-of-materials:3.3.150;

locked org.antlr:antlr4-maven-plugin:4.10;


From here, the actual pom.xml files are rewritten with
[4.10] references - locking the build to a specific,
locked range version ( for extra banality we also automatically add
 on * to prevent transitive dependencies.

This definitely has problems, but also have benefits and certainly made hot
fixes much easier to handle when we had different deployments staggered
into production between customer sites.

--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 14/04/2022 at 6:25:47 AM, "Creager, Greg" 
mailto:greg.crea...@hp.com.invalid>>
wrote:

> I am trying to reproduce a build that was done a week ago. Our maven pom
> files use range in many places ([1.0,1.1), when I go look at the pom of the
> published project, it just shows the range, not the actual version chosen:
>
> Published pom:
> 
> com.hp.cp.dfe.shared
> common-types
> [1.0,1.1)
> 
>
>
> How do I determine exact versions of dependencies used in a prior build?
> In Apache ivy the published ivy.xml shows the exact version chosen, I was
> expecting maven to have the same and I am assuming I just am not using the
> right util.
>

Re: Determine Maven Dependencies after a build

[Nils Breunese]

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 combinations which might or might
> not play nice with each other. How can you ensure to run your tests on
> all of them? Sometimes, there is a bug which affects you in 2.5.3, but
> not in 2.5.2, and quickly fixed in 2.5.4. Maybe you did or did not
> notice that it even exists. Then suddenly, someone uses the buggy
> version, and the software does not work despite green tests.

I would indeed also recommend to not use version ranges, and using a tool like 
Dependabot or Renovate to keep your dependencies up-to-date.

Nils.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org