Re: building trunk, and switching branches, with lib/ removed from trunk, and offline mode…
Hi Mick, it is here https://issues.apache.org/jira/browse/CASSANDRA-16597 On Tue, 13 Apr 2021 at 13:24, Michael Semb Wever wrote: > > > > > 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. > > > I misunderstood you Stefan. > > If you would like to contribute a patch that replaces the three invocations > of "`mvn` on the path", with a calls to `./.build/mvnw …` that would be > appreciated, and indeed it would strength the build for machines that don't > have maven installed. > > https://github.com/apache/cassandra/blob/trunk/.build/build-resolver.xml#L137-L160 > > regards, > Mick > > - > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: building trunk, and switching branches, with lib/ removed from trunk, and offline mode…
> 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. I misunderstood you Stefan. If you would like to contribute a patch that replaces the three invocations of "`mvn` on the path", with a calls to `./.build/mvnw …` that would be appreciated, and indeed it would strength the build for machines that don't have maven installed. https://github.com/apache/cassandra/blob/trunk/.build/build-resolver.xml#L137-L160 regards, Mick - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: building trunk, and switching branches, with lib/ removed from trunk, and offline mode…
> 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. > There hasn't been any appetite for maven in the project. There was some for Gradle, but not enough to get it over the line. These are bigger endeavours than expected (it is only to look at snazy's patch). The pom files we generate are just for listing dependencies (i.e. runtime usage).
Re: building trunk, and switching branches, with lib/ removed from trunk, and offline mode…
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 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 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: [email protected] For additional commands, e-mail: [email protected]
Re: building trunk, and switching branches, with lib/ removed from trunk, and offline mode…
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 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: [email protected] For additional commands, e-mail: [email protected]
building trunk, and switching branches, with lib/ removed from trunk, and offline mode…
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
