Re: Browsing Maven central buggy?
Sorry, I need to apologize, as the info I stated below is WRONG: MIMA CLI uses Maven Indexer (Search API from https://github.com/apache/maven-indexer) and it is Maven Indexer project that is Java 11 since 7.x. Sorry again, T On Wed, Jan 24, 2024 at 7:19 PM Tamás Cservenák wrote: > MIMA as a library is Java 8, but CLI is Java11+ (picocli) >
Re: Browsing Maven central buggy?
Hi, thanks for all your answers and pointers to valuable tools. So far I'm using the versions plugin via command line to find out whether there's something new, but from time to time I'd simply like to use my browser to have a look into Maven central; mostly to just inspect a dependency's POM and see what's (new?) inside... ;-) Thorsten Am 24.01.24 um 18:13 schrieb Manfred Moser: I suggest to use the maintained search and browse frontend from Sonatype instead. https://search.maven.org/ .. same as https://central.sonatype.com/ And browse at https://central.sonatype.com/search It sits on top of the same data and is very nice indeed .. props to Brian Fox and team btw! Manfred On 2024-01-24 08:57, Tamás Cservenák wrote: Howdy, Yes, this is a known problem, but it does not affect Maven, as it does not "browse". Basically you have to go directly to the directory you are looking for, and not rely on HTML "index page" as that seems not maintained since a while. T On Wed, Jan 24, 2024 at 5:50 PM Thorsten Heit wrote: Hi, browsing Maven Central using a webbrowser seems, well, a bit buggy: In https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-bom/ for example I only see versions 2.x up to 2.22.0 and 3.0.0-alpha1 whereas 2.22.1 and 3.0.0-beta1 both exist; they are simply not visible. The same happens for a few other GAV coordinates such as https://repo1.maven.org/maven2/org/apache/tika/tika-bom/3.0.0-BETA/ or https://repo1.maven.org/maven2/me/qoomon/maven-git-versioning-extension/9.7.0 : The directories exist, but one level above these versions are not shown. Is this a known problem? Thorsten - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Browsing Maven central buggy?
Alternatively, you could consider mcs [1] (Maven Central Search). MCS lets you search on coordinates (exact or partial) or on class name. It will print out the matching results from the Maven Central index as offered by Sonatype. If you provide a Sonatype API access token, MCS can also report on known security vulnerabilities. It ships as a native executable for Windows, Linux and macOS. As such, it doesn't require JBang (although making it available through JBang is on the wishlist [2]). Disclaimer: I'm the original author of MCS and as such, I might be biased... Hope this helps, Maarten [1] https://github.com/mthmulders/mcs [2] https://github.com/mthmulders/mcs/discussions/305 On 24/01/2024 18:22, Tamás Cservenák wrote: Or something like this: https://asciinema.org/a/0dLOAfWxyxTg6zgcYSDX6FQwm ;) T On Wed, Jan 24, 2024 at 6:13 PM Manfred Moser wrote: I suggest to use the maintained search and browse frontend from Sonatype instead. https://search.maven.org/ .. same as https://central.sonatype.com/ And browse at https://central.sonatype.com/search It sits on top of the same data and is very nice indeed .. props to Brian Fox and team btw! Manfred On 2024-01-24 08:57, Tamás Cservenák wrote: Howdy, Yes, this is a known problem, but it does not affect Maven, as it does not "browse". Basically you have to go directly to the directory you are looking for, and not rely on HTML "index page" as that seems not maintained since a while. T On Wed, Jan 24, 2024 at 5:50 PM Thorsten Heit wrote: Hi, browsing Maven Central using a webbrowser seems, well, a bit buggy: In https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-bom/ for example I only see versions 2.x up to 2.22.0 and 3.0.0-alpha1 whereas 2.22.1 and 3.0.0-beta1 both exist; they are simply not visible. The same happens for a few other GAV coordinates such as https://repo1.maven.org/maven2/org/apache/tika/tika-bom/3.0.0-BETA/ or https://repo1.maven.org/maven2/me/qoomon/maven-git-versioning-extension/9.7.0 : The directories exist, but one level above these versions are not shown. Is this a known problem? Thorsten - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Strange behavior using maven build-cache extension in maven-release-plugin goals
interesting.
is the deploy goal executed twice as well when you run "mvn deploy"?
(as you marked as it as alwaysRun)
On Sun, 21 Jan 2024 at 23:00, Javier Gómez wrote:
>
> Hi all,
>
> We are starting to apply the build-cache maven extension in our local and CI
> environment, and we have seen strange behavior in several maven projects,
> when using the release plugin in conjunction with build-cache, which we have
> been able to reproduce both locally and in CI.
>
> Our usual release plugin configuration is:
>
>
> org.apache.maven.plugins
> maven-release-plugin
> 3.0.0
>
> -DskipEnforceSnapshots -DskipITs -DskipTests
> -DskipUTs
> deploy
>
> SemVerVersionPolicy
> GithubReleaseStrategy
> @{prefix} Prepare release
> @{releaseLabel}
> @{prefix} Prepare for next
> development iteration
> @{project.version}
>
>
> When we add the build-cache extension to the project, and execute the release
> with: mvn release:prepare release:perform -DreleaseVersion=x.y.z we can
> observe a strange behavior when maven is launching the release:perform goal,
> we see that the deploy goal is executed 2 times for each artifact (in fact it
> seems that the maven lifecycle restarts, once it reaches the deploy and
> begins to execute the validate again) and when it reaches the 2nd execution
> of deploy, it fails (since the user we use do not have permissions to
> overwrite artifacts). Below I show an extract from the log:
>
> ...
>
> [INFO] [INFO]
>
> [INFO] [INFO] Reactor Build Order:
> [INFO] [INFO]
> [INFO] [INFO] temp.mectagcore:mectagcore [pom]
> [INFO] [INFO] temp.mectagcore:mectagcore-domain [jar]
> [INFO] [INFO] temp.mectagcore:mectagcore-boot[jar]
> [INFO] [INFO] temp.mectagcore:jacoco-report-aggregate[pom]
> [INFO] [INFO]
> [INFO] [INFO] -< temp.mectagcore:mectagcore >-
> [INFO] [INFO] Building temp.mectagcore:mectagcore 1.0.0 [1/9]
> [INFO] [INFO] from pom.xml
> [INFO] [INFO] [ pom
> ]-
> [INFO] [INFO] Going to calculate checksum for project
> [groupId=temp.mectagcore, artifactId=mectagcore]
> [INFO] [INFO] Project inputs calculated in 12 ms. SHA-256 checksum
> [16534757c14aae9b1ff1961664995f0e7e9396fb88309d207a8a23c080c7f661] calculated
> in 4 ms.
> [INFO] [INFO] Attempting to restore project temp.mectagcore:mectagcore from
> build cache
> [INFO] [INFO] Local build found by checksum
> 16534757c14aae9b1ff1961664995f0e7e9396fb88309d207a8a23c080c7f661
> [INFO] [INFO] Found cached build, restoring temp.mectagcore:mectagcore from
> cache by checksum
> 16534757c14aae9b1ff1961664995f0e7e9396fb88309d207a8a23c080c7f661
> [INFO] [INFO] Project temp.mectagcore:mectagcore restored partially. Highest
> cached goal: verify, requested: deploy
> [INFO] role: 'org.apache.maven.plugin.Mojo', implementation:
> 'org.apache.maven.plugin.failsafe.IntegrationTestMojo', role hint:
> 'org.apache.maven.plugins:maven-failsafe-plugin:3.0.0:integration-test'
> [INFO] role: 'org.apache.maven.plugin.Mojo', implementation:
> 'org.apache.maven.plugin.failsafe.VerifyMojo', role hint:
> 'org.apache.maven.plugins:maven-failsafe-plugin:3.0.0:verify'
> [INFO] ---
> [INFO] [INFO] Skipping plugin execution (cached): enforcer:enforce
> [INFO] [INFO] Skipping plugin execution (cached): enforcer:enforce
> [INFO] [INFO] Skipping plugin execution (cached): build-helper:add-source
> [INFO] [INFO] Mojo execution is forced by project property:
> amiga-assembly:amiga-assembly
> [INFO] [INFO]
> [INFO] [INFO] --- amiga-assembly:5.5.0:amiga-assembly
> (amiga-assembly-execution) @ mectagcore ---
> [INFO] [INFO] Mojo execution is forced by project property: source:jar-no-fork
> [INFO] [INFO]
> [INFO] [INFO] --- source:3.2.1:jar-no-fork (attach-sources) @ mectagcore ---
> [INFO] [INFO] Skipping plugin execution (cached): failsafe:integration-test
> [INFO] [INFO] Skipping plugin execution (cached): failsafe:verify
> [INFO] [INFO]
> [INFO] [INFO] --- install:3.1.1:install (default-install) @ mectagcore ---
> [INFO] role: 'org.apache.maven.plugin.Mojo', implementation:
> 'org.apache.maven.plugins.install.InstallMojo', role hint:
> 'org.apache.maven.plugins:maven-install-plugin:3.1.1:install'
> [INFO] role: 'org.apache.maven.plugin.Mojo', implementation:
> 'org.apache.maven.plugins.install.InstallFileMojo', role hint:
> 'org.apache.maven.plugins:maven-install-plugin:3.1.1:install-file'
> [INFO] ---
> [INFO] [INFO] Installing
> /tmp/mic-mectagcore/code/target/checkout/code/pom.xml to
> /home/alambike/.m2/repository/temp/mectagcore/mectagcore/1.0.0/mectagcore-1.0.0.pom
> [INFO] [INFO]
> [INFO] [INFO] --- deploy:3.1.1:
