Re: Checking dependencies in gradle after code is removed
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 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 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-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
Re: Checking dependencies in gradle after code is removed
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 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-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Checking dependencies in gradle after code is removed
> 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Checking dependencies in gradle after code is removed
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 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 > 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 > 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-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Checking dependencies in gradle after code is removed
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 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 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-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Checking dependencies in gradle after code is removed
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 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-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 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. 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
