You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Mick Semb Wever <mc...@apache.org> on 2021/04/05 14:45:20 UTC
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
Re: building trunk, and switching branches, with lib/ removed from trunk, and offline mode…
Posted by Mick Semb Wever <mc...@apache.org>.
> 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…
Posted by Stefan Miklosovic <st...@instaclustr.com>.
Hi Mick,
it is here https://issues.apache.org/jira/browse/CASSANDRA-16597
On Tue, 13 Apr 2021 at 13:24, Michael Semb Wever <mc...@apache.org> 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: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: building trunk, and switching branches, with lib/ removed from trunk, and offline mode���
Posted by Michael Semb Wever <mc...@apache.org>.
> 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: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: building trunk, and switching branches, with lib/ removed from trunk, and offline mode…
Posted by Stefan Miklosovic <st...@instaclustr.com>.
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
<st...@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 <mc...@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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: building trunk, and switching branches, with lib/ removed from trunk, and offline mode…
Posted by Stefan Miklosovic <st...@instaclustr.com>.
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 <mc...@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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org