Actually, I am not completely sure if Maven wrapper will play nicely with Ant stuff of yours as maybe it indeed looks for "mvn" on path and wrapper is invoked differently so it does not have to necessarily see it. I ll check it and let you know.
Regards On Mon, 5 Apr 2021 at 17:34, Stefan Miklosovic <stefan.mikloso...@instaclustr.com> wrote: > > Superb stuff, thanks Mick. > > Would it maybe be possible to include some automatic way to get Maven? > Maven wrapper is the standard here I would say, it is possible to do > it such a way that JAR does not need to be included either. > > I can prepare PR with this. > > https://github.com/takari/maven-wrapper#usage-without-binary-jar > > Regards > > On Mon, 5 Apr 2021 at 16:45, Mick Semb Wever <m...@apache.org> wrote: > > > > CASSANDRA-16391 has been committed to trunk. > > Migrate dependency handling from maven-ant-tasks to resolver-ant-tasks. > > > > > > It addresses a number of issues, > > - dependencies are downloaded, using the resolver-ant-tasks plugin instead > > of the deprecated maven-ant-tasks plugin, > > - it will no longer attempt and fail to download dependencies through any > > insecure and unavailable http:// central repositories, > > - it makes our generated pom files the source of truth for our dependency > > tree, updating dependencies is now only about the edit to build.xml > > - it fixes a number of maven pom inaccuracies, from including > > dependencies, to fixing their scope, to excluding conflicts in the > > transitive tree. > > > > It also addresses the tribal knowledge of not including compiled binaries > > in source artefacts, unless their source are also bundled, or they are only > > used as a build tool or for tests, or god-knows-what-other-reason. Related > > to these issues is also CASSANDRA-16558, waiting on review. > > > > It has not been committed to the 2.2, 3.0, 3.11 branches. Mostly because of > > the urgency of getting this into trunk before another release is cut, but > > also to give everyone a post-commit chance to review and test it. This has > > all happened much faster than desired. > > > > But *be warned*, because it hasn't yet been committed to these past > > branches we have a temporary headache of having to do `ant realclean` > > before git switching from trunk to an older branch (otherwise git won't put > > back into place the versioned lib/ directory). This didn't come up during > > the testing of CASSANDRA-16391, mea culpa, though it will be fixed by > > committing CASSANDRA-16557. Another issue that has come up is compiling in > > IDE and Eclipse broke, ref CASSANDRA-16560, for the meantime build with > > `ant` on the command line. > > > > It would still be possible to keep lib/ in version control, without losing > > any of the other advantages gained by CASSANDRA-16391. But we are not clear > > where the policy regarding that will land, as it doesn't really provide our > > build any advantage. Now _everything_ is downloaded first to > > ~/.m2/repository/, so rebuilds don't need the internet (at least after > > CASSANDRA-16559 lands, which is patch ready). Re-introducing lib/ would > > IMHO just mean extra files to remove and commit when changing dependencies. > > > > regards, > > Mick --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
