You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Erick Erickson <er...@gmail.com> on 2020/08/31 16:14:15 UTC
Checking dependencies in gradle after code is removed
Is there an easy way to insure that versions.props only has necessary dependencies listed? Ideally it would be just a top-level command.
I got to wondering about this thinking about all the code that’s being removed from core and was wondering how we’d be sure that any dependencies that were required only by that code got taken out of versions.props.
gradlew dependencies lists pretty much everything, is it the case that if a dependency does _not_ show up in a project that it’s unused?
Inquiring minds want to know.
Erick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Checking dependencies in gradle after code is removed
Posted by Dawid Weiss <da...@gmail.com>.
The location doesn't really matter I think - I just wouldn't want it to be
mixed with lots of other content... These things are build-related. The
same content appears when you type
./gradlew help
or even just
./gradlew
Try it.
Dawid
On Fri, Sep 4, 2020 at 5:32 PM David Smiley <ds...@apache.org> wrote:
> Thanks! This "/help" folder is something I've overlooked. You've done a
> fine job of maintaining a variety of information for developers.
>
> Cassandra (and everyone really): should we move /dev-docs somewhere
> else? A new person browsing seeing "dev-docs" might notice it first
> (alphabetically first relative to "help") and at a glance seems to overlap
> in purpose. At a glance by name alone, it even suggests to me it may be
> more likely to have build docs that are actually in "/help". Only once you
> read dev-docs/README.md is it clear it's only for us project members.
> Maybe it should be beneath "/help" and be named "for-committers" -- thus
> "/help/for-committers"?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Fri, Sep 4, 2020 at 5:58 AM Dawid Weiss <da...@gmail.com> wrote:
>
>> > What's the path of the ".lock" file you refer to?
>>
>> versions.lock
>>
>> See help/dependencies.txt for more.
>>
>> D.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: Checking dependencies in gradle after code is removed
Posted by David Smiley <ds...@apache.org>.
Thanks! This "/help" folder is something I've overlooked. You've done a
fine job of maintaining a variety of information for developers.
Cassandra (and everyone really): should we move /dev-docs somewhere else?
A new person browsing seeing "dev-docs" might notice it first
(alphabetically first relative to "help") and at a glance seems to overlap
in purpose. At a glance by name alone, it even suggests to me it may be
more likely to have build docs that are actually in "/help". Only once you
read dev-docs/README.md is it clear it's only for us project members.
Maybe it should be beneath "/help" and be named "for-committers" -- thus
"/help/for-committers"?
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Fri, Sep 4, 2020 at 5:58 AM Dawid Weiss <da...@gmail.com> wrote:
> > What's the path of the ".lock" file you refer to?
>
> versions.lock
>
> See help/dependencies.txt for more.
>
> D.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Checking dependencies in gradle after code is removed
Posted by Dawid Weiss <da...@gmail.com>.
> What's the path of the ".lock" file you refer to?
versions.lock
See help/dependencies.txt for more.
D.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Checking dependencies in gradle after code is removed
Posted by David Smiley <ds...@apache.org>.
Thanks Dawid for that fantastic explanation!
What's the path of the ".lock" file you refer to?
gradlew -p solr/solrj dependencies
I observe it has many named dependency trees; some quite large.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Sep 1, 2020 at 3:19 AM Dawid Weiss <da...@gmail.com> wrote:
> bq. you get a lot of entries there
>
> That's why this is to large degree automated. You do have a lot of
> entries because it's a union of all dependencies across all
> sub-projects. While this may seem like a negative, it's not - it
> ensures everyone stays on the same set of dependencies. Makes life
> easier in the long run.
>
> Also, you can check what depends on what by looking at the .lock file;
> for example:
>
> com.github.jnr:jffi:1.2.18 (1 constraints: b20902ab)
>
> if you ask for this hash, you'll see where the dependency comes from
> (and so on, recursively). Note that some of these dependencies are
> built-time, not runtime.
>
> O:\repos\lucene-master>gradlew why --hash=b20902ab
> Starting a Gradle Daemon (subsequent builds will be faster)
>
> > Task :why
> com.github.jnr:jffi:1.2.18
> org.jruby:jruby-core -> 1.2.18
>
> O:\repos\lucene-master>gradlew why --hash=0f08b57d
>
> > Task :why
> org.jruby:jruby-core:9.2.6.0
> org.jruby:jruby -> 9.2.6.0
>
> org.jruby:jruby-stdlib:9.2.6.0
> org.jruby:jruby -> 9.2.6.0
>
> O:\repos\lucene-master>gradlew why --hash=490d7d28
>
> > Task :why
> org.jruby:jruby:9.2.6.0
> org.asciidoctor:asciidoctorj -> 9.2.6.0
>
> etc.
>
> Dawid
>
> On Tue, Sep 1, 2020 at 1:20 AM Erick Erickson <er...@gmail.com>
> wrote:
> >
> > Excellent, I’ve put it in my notes… you get a lot of entries there…
> Thanks!
> >
> > > On Aug 31, 2020, at 2:59 PM, Dawid Weiss <da...@gmail.com>
> wrote:
> > >
> > >> Is there an easy way to insure that versions.props only has necessary
> dependencies listed? Ideally it would be just a top-level command.
> > >
> > > If a dependency isn't used, check will fail. It's a feature of
> > > palantir's version control plugin. The concrete task that does it is
> > > named checkUnusedConstraints but you should not need to know it (or
> > > care). Use check at the top level and it'll be run automatically.
> > >
> > >> gradlew dependencies lists pretty much everything, is it the case
> that if a dependency does _not_ show up in a project that it’s unused?
> > >
> > > That's because solr depends on pretty much everything...
> > >
> > > D.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Checking dependencies in gradle after code is removed
Posted by Dawid Weiss <da...@gmail.com>.
bq. you get a lot of entries there
That's why this is to large degree automated. You do have a lot of
entries because it's a union of all dependencies across all
sub-projects. While this may seem like a negative, it's not - it
ensures everyone stays on the same set of dependencies. Makes life
easier in the long run.
Also, you can check what depends on what by looking at the .lock file;
for example:
com.github.jnr:jffi:1.2.18 (1 constraints: b20902ab)
if you ask for this hash, you'll see where the dependency comes from
(and so on, recursively). Note that some of these dependencies are
built-time, not runtime.
O:\repos\lucene-master>gradlew why --hash=b20902ab
Starting a Gradle Daemon (subsequent builds will be faster)
> Task :why
com.github.jnr:jffi:1.2.18
org.jruby:jruby-core -> 1.2.18
O:\repos\lucene-master>gradlew why --hash=0f08b57d
> Task :why
org.jruby:jruby-core:9.2.6.0
org.jruby:jruby -> 9.2.6.0
org.jruby:jruby-stdlib:9.2.6.0
org.jruby:jruby -> 9.2.6.0
O:\repos\lucene-master>gradlew why --hash=490d7d28
> Task :why
org.jruby:jruby:9.2.6.0
org.asciidoctor:asciidoctorj -> 9.2.6.0
etc.
Dawid
On Tue, Sep 1, 2020 at 1:20 AM Erick Erickson <er...@gmail.com> wrote:
>
> Excellent, I’ve put it in my notes… you get a lot of entries there… Thanks!
>
> > On Aug 31, 2020, at 2:59 PM, Dawid Weiss <da...@gmail.com> wrote:
> >
> >> Is there an easy way to insure that versions.props only has necessary dependencies listed? Ideally it would be just a top-level command.
> >
> > If a dependency isn't used, check will fail. It's a feature of
> > palantir's version control plugin. The concrete task that does it is
> > named checkUnusedConstraints but you should not need to know it (or
> > care). Use check at the top level and it'll be run automatically.
> >
> >> gradlew dependencies lists pretty much everything, is it the case that if a dependency does _not_ show up in a project that it’s unused?
> >
> > That's because solr depends on pretty much everything...
> >
> > D.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Checking dependencies in gradle after code is removed
Posted by Erick Erickson <er...@gmail.com>.
Excellent, I’ve put it in my notes… you get a lot of entries there… Thanks!
> On Aug 31, 2020, at 2:59 PM, Dawid Weiss <da...@gmail.com> wrote:
>
>> Is there an easy way to insure that versions.props only has necessary dependencies listed? Ideally it would be just a top-level command.
>
> If a dependency isn't used, check will fail. It's a feature of
> palantir's version control plugin. The concrete task that does it is
> named checkUnusedConstraints but you should not need to know it (or
> care). Use check at the top level and it'll be run automatically.
>
>> gradlew dependencies lists pretty much everything, is it the case that if a dependency does _not_ show up in a project that it’s unused?
>
> That's because solr depends on pretty much everything...
>
> D.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Checking dependencies in gradle after code is removed
Posted by Dawid Weiss <da...@gmail.com>.
> Is there an easy way to insure that versions.props only has necessary dependencies listed? Ideally it would be just a top-level command.
If a dependency isn't used, check will fail. It's a feature of
palantir's version control plugin. The concrete task that does it is
named checkUnusedConstraints but you should not need to know it (or
care). Use check at the top level and it'll be run automatically.
> gradlew dependencies lists pretty much everything, is it the case that if a dependency does _not_ show up in a project that it’s unused?
That's because solr depends on pretty much everything...
D.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org