Re: [DISCUSS] Merge ITs in maven
in fact, putting everything in 1 Git repo does not force to run 1 single build: we can continue running in separate executions and with this, nothing prevents from running the its HEAD against another commit for Maven core build Le jeudi 10 octobre 2024, 13:47:31 CEST Michael Osipov a écrit : > No, it won't, but it will allow you to integrate the IT w/o pulling them in > physically. > On 2024/10/10 11:22:25 Guillaume Nodet wrote: > > I don’t see git submodules fixing the pain of having to create two PRs, > > keeping them aligned, having to merge or rebase both at the same time… > > > > > > Guillaume Nodet > > > > Le jeu. 10 oct. 2024 à 09:41, Michael Osipov a écrit : > > > A few notes on this though I am neutral: > > > > > > * Significant growth of repo, thus repo size for those who simply don't > > > need ITs > > > * A compat kit (which it is) is usually a separate repo/product/project > > > * Though I consider Git submodules as a horrible implementation compared > > > to Subversion externals, it could live as an optional submodule with a > > > Maven profile being activated. Those who need it can init the > > > subrepo/submodule. > > > > > > Michael > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PR] Bump org.junit.jupiter:junit-jupiter from 5.11.1 to 5.11.2 [maven-hocon-extension]
slachiewicz merged PR #8: URL: https://github.com/apache/maven-hocon-extension/pull/8 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PR] Bump org.junit.jupiter:junit-jupiter from 5.11.0 to 5.11.2 [maven-xinclude-extension]
slachiewicz merged PR #8: URL: https://github.com/apache/maven-xinclude-extension/pull/8 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Merge ITs in maven
On Thu, Oct 10, 2024 at 7:32 AM Xeno Amess wrote: > > do there really be...some widely used 3rd-party distribution (non-apache) > for maven? > > I know this situation be true for openjdk, but for maven I really didn't > notice any... > No, there isn't. This was a now abandoned plan and can be revisited now if it makes sense. Way back in the day, some devs who are no longer around had really ambitious plans for maven that never really materialized. Among other things, this led to Plexus and Modello and are the cause of much technical debt in Maven. I suspect the separate ITs are another artifact of these now defunct plans. YAGNI! -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Merge staged classifiers and deploy
Hello, Any updates here? Also the challenge I found is that I can't understand how Maven and the repository cooperate on deployment. Is there some docs or specs describe the concepts and workflows so that I can try to customize my own solutions? Now I'd like to release one new classifier "all" that contains all the native libs as resources, but I don't know how to start working on it .. Best, tison. Tamás Cservenák 于2024年5月3日周五 09:27写道： > > Howdy, > > We have a similar use case (unsolved yet, done manually) in maven-mvnd, > where native binaries for various OS es (produced by GraalVM) need to be > collected > > Stay tuned. > > T > > On Thu, May 2, 2024 at 3:38 AM tison wrote: > > > Hi, > > > > I found the other thread talks about nexus-staging-plugin and it's > > deprecated. > > > > In Apache OpenDAL, we're currently relying on nexus-staging-plugin for > > merging staged classifiers (i.e., JARs with native library on different > > platforms) and deploy. > > > > We wrote [1] and [2] for doing so, and IIRC I spent a few days but fail to > > find the way achieve this in maven-deploy-plugin. > > > > [1] > > > > https://github.com/apache/opendal/blob/v0.45.1/.github/workflows/release_java.yml > > [2] > > > > https://github.com/apache/opendal/blob/v0.45.1/scripts/merge_local_staging.py > > > > Did you ever encounter this case? Is there any reference? > > > > Best, > > tison. > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Merge ITs in maven
the resulting history looks reasonable and we can later split with filter if necessary I don't know if making one single build is useful, or keeping 2 separate, or even promoting 3 (Maven core itself, ITs build, ITs run) But definitively, doing one single Git commit when doing a feature is a clear win Also doing an IT run when doing the release: I confess I never do, I should... I see good reasons to do the merge like proposed, I don't really see drawbacks (apart from "it's not as usual" :) ) great idea Hervé Le mercredi 9 octobre 2024, 09:10:17 CEST Guillaume Nodet a écrit : > I just pushed a branch with the results: >https://github.com/gnodet/maven/tree/merge-its > > This is just the raw output of the recipe. The ITs are not integrated into > the build, which will even fail due to RAT checks and maybe other reasons. > > Le mer. 9 oct. 2024 à 08:35, Herve Boutemy a écrit : > > I understand how it adds complexity > > > > AFAIK, the interest of having a separate project of core ITs is to clear > > state the Maven core version range for each test, to clearly document when > > things were introduced / broken / fixed and even be able to run HEAD ITs > > against a past release > > > > is it the only reason? I don't know, it's the key aspect I understood 15 > > years ago when it was done and I was too noob to really grasp every detail > > > > :) > > > > does this really deserve the complexity it creates? > > I don't know > > > > I also need to check the Git merge recipe, to see how the result would be > > ok to me: do you have a personal fork somewhere so we can review without > > running the command ourselves? > > > > Regards, > > > > Hervé > > > > On 2024/10/08 06:36:19 Guillaume Nodet wrote: > > > I'd like to discuss merging ITs into maven core repository. > > > The ITs have already been splitted some time ago between the 3.x branch > > > > and > > > > > master for testing Maven master. But I don't really see a good reason > > > to > > > keep the repositories separated, this makes things more complicated when > > > modifying maven code and adding ITs. > > > > > > The following script allow merging the two repositories while keeping > > > > both > > > > > histories: > > > > > > > > > brew install git-filter-repo > > > > > > git clone https://github.com/apache/maven > > > > > > git clone https://github.com/apache/maven-integration-testing > > > > > > (cd maven-integration-testing && \ > > > > > > git filter-repo --to-subdirectory-filter its) > > > > > > (cd maven && \ > > > > > > git remote add its ../maven-integration-testing && \ > > > > > > git fetch its --no-tags && \ > > > > > > EDITOR=true git merge --allow-unrelated-histories its/master && \ > > > > > > git remote remove its) > > > > > > The next step would be to actually include them in a profile and update > > > > the > > > > > github workflow. > > > > > > I think they could be refactored to: > > > * first perform a full run on Ubuntu + latest LTS JDK: > > > - restore cache > > > - checkout > > > - build with no tests > > > - run IT bootstrap (to prime local repo) > > > - save cache > > > - build again with tests and ITs > > > > > > * if this first run succeeds, do the same on other platforms / jdks > > > > > > The cache is important to add imho. It seems lately, GH runners have > > > > often > > > > > problems downloading from maven central, so that would help a lot > > > increasing the stability. So using > > > https://github.com/marketplace/actions/maven-cache or a similar action > > > would be handy imho. > > > > > > We should also upload nightlies from GH. > > > And automate the releases as much as possible > > > > > > -- > > > > > > Guillaume Nodet > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: thought: allow exclude dependencies from parent in maven4?
well I would like to implement the codes and fire a jira ticket this month, since seems nobody be strongly reject this... Richard Eckart de Castilho 于2024年9月25日周三 23:26写道： > Ran into this also recently (again). > > I believe a good way to solve this would be to allow overriding a > dependency > inherited from the parent POM with `none` or something like > that. > > I tried overriding with `provided` but for some reason that > didn't seem to work. > > The context was trying that I typically have `slf4j-simple` as a test > dependency for all > modules so I had added that to the parent, but then I had one module where > I absolutely > needed to use the log4j SLF4J binding and I couldn't get rid of the > `slf4j-simple` then > just for that module. > > That said, in general I would advise against inheriting dependencies from > parents. > Typically, you inherit too much and that means you'll have to add excludes > for the > dependency analyzer plugin as well... it's a mess. > > -- Richard > > > On 25. Sep 2024, at 17:17, Xeno Amess wrote: > > > > and another idea be we could add a and > > (kind of mirror to dependencies and dependencyManagement) to remove those > > dependencies from parent &EVERY dependency... > > > > Xeno Amess 于2024年9月25日周三 22:59写道： > > > >> Hi. > >> > >> In maven3 we cannot exclude dependencies inherited from parent. > >> > >> see this > >> > >> > https://stackoverflow.com/questions/2681759/is-there-anyway-to-exclude-artifacts-inherited-from-a-parent-pom > >> > >> That be kind of annoying if situation comes to be the parent-pom be > >> maintained by others, and you extend it and it works fine until one day > >> they suddenlly decide to depend on some packages you would never make > >> compatible/useless, and you have no permission to change their mind. > >> What I wanna do is adding such a gramma like this: > >> > >> > >> base > >> es.uniovi.innova > >> 1.0.0 > >> > >> > >> javax.mail > >> mail > >> > >> > >> > >> > >> ' > >> but I wanna hear about your opinions first. > >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
