Re: Multi-module Maven projects and Scala-aware artifact IDs
> Guava has -jre > and -android flavors on their artifact ID instead of using classifiers. not exactly, they have the flavor as part of version string https://central.sonatype.com/artifact/com.google.guava/guava/32.0.1-jre/ versions which in fact looks like what François describes in another answer to the thread Regards, Hervé Le lundi 12 juin 2023, 19:30:12 CEST Greg Chabala a écrit : > Sure, individual projects have done things as they saw fit. Guava has -jre > and -android flavors on their artifact ID instead of using classifiers. > Bouncycastle is using ant for their build process. I wouldn't want to > emulate either as best practice. > > Scala, as an ecosystem, has decided on "_binaryVersion" appended to > artifact ID, which feels gross. > > The Maven POM reference ( https://maven.apache.org/pom.html ) is pretty > clear: "The classifier distinguishes artifacts that were built from the > same POM but differ in content. It is some optional and arbitrary string > that - if present - is appended to the artifact name just after the version > number. As a motivation for this element, consider for example a project > that offers an artifact targeting Java 11 but at the same time also an > artifact that still supports Java 1.8." > > Binary compatibility versions are noise that should be in the classifier, > if you're building from the same source tree, it only needs one artifact ID. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Questions about the build cache plugin
reading the discussion about maintenance branch and "who updates the cache", I think that: 1. maintenance branch is like main branch: with Olivier's nice strategy, you should build fully. In fact, the few long-lived branches should be built fully, only the many PR short-lived branches should be built quickly with cache 2. "updating" the cache makes you feel that it's like publishing a SNAPSHOT, ie the last publication wins over previous ones. With cache, any publication is just an addition of new content, indexed by input checksums. Then we don't really care about who is the first discovering a new input checksum, then filling the output cache for that new input checksum. Really nice feedback on build cache extension in real life! Thanks a lot to the contributor to this great feature Regards, Hervé Le mardi 13 juin 2023, 07:11:50 CEST Olivier Lamy a écrit : > On Mon, 12 Jun 2023 at 21:38, Benjamin Marwell wrote: > > Am Mo., 12. Juni 2023 um 12:08 Uhr schrieb Olivier Lamy : > > > On Mon, 12 Jun 2023 at 18:53, Benjamin Marwell wrote: > > > > Hello everyone! > > > > > > > > First of all thank you everyone working on the build cache plugin! It > > > > is amazing! > > > > > > > > At least some of the following questions seem to be of interest to > > > > most users and might end up on the documentation, So here's a few > > > > things which came to my mind. > > > > > > > > 1.) Considering I always require PRs in my projects, would setting > > > > -Dmaven.build.cache.remote.save.enabled=true be a sensible thing only > > > > for the main branch? > > > > > > Personally, I would have the main branch always have a full build > > > without caching to be sure everything works fine but use cache only > > > for branches/PR :) > > > That's what we will do at Jetty project. > > > The build for 12 branch is around 50 minutes with the cache it goes > > > down to 8/9 minutes (only because something is always rebuilt and > > > retrigger a few small modules) > > > The idea is to reduce development/check of PR and use some incremental > > > build while the main is always fully build especially when the build > > > has few jdks as target. > > > But here it's up to you :) > > > > I can see your point, but who is updating the remote cache then? > > every PR potentially updates the cache. depending on changes per PR > some module cache will be shared or not with other PRs. > We (Jetty project) have decided to not have any publicity open remote > cache setup per default as we do not have the infra for this (but CI > use a private one) > but in a company context or if you have the infra for this it might be > a better option. > > > > > 2.) Can I maybe have the branch name included in a path to a remote? > > > > This way I could have a different cache for maintenance branches. Just > > > > include the branch name into -Dmaven.build.cache.remote.url? > > > > > > why would need that? > > > if your branch has different sources (java, pom, etc..) the calculated > > > hash will be different so the hash key will be simply different no > > > need to configure a cache URL differently (well except if you want to > > > clean up caches per branch) > > > > It depends on what you might be trying to do. For projects with new > > major versions and some > > big refactoring done in the past, this did sound sensible to me. > > What is the cache worth if there's 0% hit on the maintenance branch? > > hit ratio will depend on the changes you do. > parent pom change -> everything will be rebuilt > single java source in a module: only this module and dependant will be > rebuilt. Finally, there is no single rule on how to use/configure the > cache, the usage depends on how a team is working, what sort of change they > often have, etc... > first, have your build working (if it's complicated one you may have > some extra configuration to add) > > > > > 3.) Can I somehow use option 1 & 2 to make caches available for > > > > colleagues without making them manually configure the remote URL for > > > > each branch they are working on? > > > > > > cache will be used by colleagues' build as long as a module have the > > > same calculated hash any local differences will have a different > > > calculated hash > > > > Same as above: > > What about devs working on a maintenance branch when main has seen big > > refactoring? > > > > > > 4.) The docs say there's also XX and XXMM algorithms, but it doesn't > > > > say WHEN to use them (only that they may leverage performance). Are > > > > there some example cases or does someone already have some experience > > > > we could benefit from? > > > > > > I have yet to see huge differences. > > > currently with a build already down from 50 minutes to 8/9 minutes not > > > sure this was my primary goal > > > So I can't really tell :) > > > > Well, it is listed under "performance tuning", so I concluded it might > > make a difference. > > Will probably go for XX (because it is mentioned as perfo
[ANN] Maven Indexer 7.0.3 released
The Apache Maven team is pleased to announce the release of the Maven Indexer 7.0.3 https://maven.apache.org/maven-indexer/ Release Notes - Maven Indexer - Version 7.0.3 ** Improvement * [MINDEXER-190] - Avoid use of String#split in hot code * [MINDEXER-191] - Avoid group rebuilding during incremental updates ** Task * [MINDEXER-192] - Update build plugins ** Dependency upgrade * [MINDEXER-189] - Upgrade to Lucene 9.6.0 * [MINDEXER-193] - Update dependencies Have fun, -The Apache Maven team
[ANN] Maven Shade Plugin 3.5.0 released
The Apache Maven team is pleased to announce the release of the Maven Shade Plugin 3.5.0 https://maven.apache.org/plugins/maven-shade-plugin/ Release Notes - Maven Shade Plugin - Version 3.5.0 ** Bug * [MSHADE-443] - Fix problems with shadeSourcesContent ** New Feature * [MSHADE-400] - Self-minimisation with custom entry points ** Task * [MSHADE-438] - Update to Maven 3.2.5 * [MSHADE-450] - Upgrade to parent POM 39, reformat ** Dependency upgrade * [MSHADE-446] - Update dependencies * [MSHADE-447] - Move off forked Guice * [MSHADE-448] - Upgrade ASM to 9.5 * [MSHADE-449] - Upgrade plexus-utils to 3.5.1 Have fun, -The Apache Maven team
[ANN] Maven Resolver 1.9.11 released
The Apache Maven team is pleased to announce the release of the Maven Resolver 1.9.11 https://maven.apache.org/resolver/ Release Notes - Maven Resolver - Version 1.9.11 ** Bug * [MRESOLVER-361] - Unreliable TCP and retries on upload ** New Feature * [MRESOLVER-353] - Make aether.checksums.algorithms settable per remote repository * [MRESOLVER-370] - Lock factory should dump lock states on failure ** Task * [MRESOLVER-356] - Remove Guava (is unused) * [MRESOLVER-364] - Revert MRESOLVER-132 * [MRESOLVER-366] - Upgrade build plugins ** Dependency upgrade * [MRESOLVER-365] - Upgrade dependencies * [MRESOLVER-367] - upgrade redisson in named locks and simplify installation Have fun, -The Apache Maven team
TAC Applications for Community Over Code North America and Asia now open
Hi All, (This email goes out to all our user and dev project mailing lists, so you may receive this email more than once.) The Travel Assistance Committee has opened up applications to help get people to the following events: *Community Over Code Asia 2023 - * *August 18th to August 20th in Beijing , China* Applications for this event closes on the 6th July so time is short, please apply as soon as possible. TAC is prioritising applications from the Asia and Oceania regions. More details on this event can be found at: https://apachecon.com/acasia2023/ More information on how to apply please read: https://tac.apache.org/ *Community Over Code North America - * *October 7th to October 10th in Halifax, Canada* Applications for this event closes on the 22nd July. We expect many applications so please do apply as soon as you can. TAC is prioritising applications from the North and South America regions. More details on this event can be found at: https://communityovercode.org/ More information on how to apply please read: https://tac.apache.org/ *Have you applied to be a Speaker?* If you have applied or intend to apply as a Speaker at either of these events, and think you may require assistance for Travel and/or Accommodation - TAC advises that you do not wait until you have been notified of your speaker status and to apply early. Should you not be accepted as a speaker and still wish to attend you can amend you application to include Conference fees, or, you may withdraw your application. The call for presentations for Halifax is here: https://communityovercode.org/call-for-presentations/ and you have until the 13th of July to apply. The call for presentations for Beijing is here: https://apachecon.com/acasia2023/cfp.html and you have until the 18th June to apply. *IMPORTANT Note on Visas:* It is important that you apply for a Visa as soon as possible - do not wait until you know if you have been accepted for Travel Assistance or not, as due to current wait times for Interviews in some Countries, waiting that long may be too late, so please do apply for a Visa right away. Contact tac-ap...@tac.apache.org if you need any more information or assistance in this area. *Spread the Word!!* TAC encourages you to spread the word about Travel Assistance to get to these events, so feel free to repost as you see fit on Social Media, at work, schools, universities etc etc... Thank You and hope to see you all soon Gavin McDonald on behalf of the ASF Travel Assistance Committee.
