I don't think the details of how gradle locates (or stores) a particular dependency matter much. As long as the dependency is resolvable (and the signature matches the one initially added to the repository) we're fine.
For most things (running tests, sha checks, etc.) the dependency JARs don't have to be copied to the project (and why should they be). The only exception is packaging final distribution. The way we currently handle things in ant/ ivy (copying to lib/ folders local to the project) is only there because of technological legacy. I don't think we should stick to it. Dawid On Sat, Nov 16, 2019 at 2:16 PM Martin Gainty <mgai...@hotmail.com> wrote: > good catch on what happens when my jar is not located in specified lib > folder? > > public repositories: > ============== > all jars and model declarators should be discoverable in one of these > public repositories > maven https://central.maven.org/ > ant https://repo1.maven.org/maven2/ant/ > gradle https://repo.maven.apache.org/maven2/ > > local repositories: > ========================= > during a build you will find jars (or redirects) being downloaded to local > repository such as > maven $user.home/.m2/repository > gradle $user.home/.gradle/caches > ant $user.home/.ant/lib > > but be aware gradle likes to reference module name instead of using gav > maven coords > so say you are compiling minecraft > > $user.home/.gradle/caches/minecraft/net/minecraftforge/forge/ > > be aware the label that gradle will reference to fetch from caches is > 'minecraft' > but adding 'mincecraft' to gradle varies based on which ide you > use..reference:https://stackoverflow.com/questions/53931937/how-to-include-module-to-the-project > > > <https://stackoverflow.com/questions/53931937/how-to-include-module-to-the-project> > android - How to include module to the project? - Stack Overflow > <https://stackoverflow.com/questions/53931937/how-to-include-module-to-the-project> > Clone the repository which you want to be included as a module. Provide > the path of your cloned repository. Now suppose if I want to include > Calendar module to my project. > stackoverflow.com > > resolving version: > ============= > plugins and dependency without versions in maven default to latest so in > maven land > com.erickson > erick-1.0 > -1.1 > <dependency> > <groupId>com.erickson</groupId> > <artifactId>erick</artifact> > </dependency> > would pull 1.1 version (latest-version) from central repository(s) > > when version not specified gradle will apparently resolves to newest > (latest modification date) e.g. > com.erickson > -erick > -1.0 modification date 11/16/2019 > -1.1 modification date 11/01/2019 > sans version.... gradle will auto-select the latest mod-date (version of > 1.0 version) > > as this is clear as mud i invite correction > > does this help? > M- > > ------------------------------ > *From:* Erick Erickson <erickerick...@gmail.com> > *Sent:* Friday, November 15, 2019 9:44 PM > *To:* dev@lucene.apache.org <dev@lucene.apache.org> > *Subject:* Anyone interested in the Gradle build, please comment on > SOLR-13915 > > In a nutshell, it doesn’t look like there’s any task that populates: > > ../solr/server/solr-webapp/webapp/WEB-INF/lib/ > ../solr/server/lib/ext/ > ../solr/server/lib/ > > with jar files. So "solr/bin/solr start” simply can’t start since it > defines CLASSPATH to point to them. Before I try to mimic the Ant build > that populates these, should we re-think how these are populated and/or > where they live? > > “gradlew assemble” pulls the jars down, but I sure can’t find anywhere > where that task is defined, and the Gradle javadocs say things like: > > assemble() - Method in class org.gradle.language.assembler.tasks.Assemble > > Assemble - Class in org.gradle.language.assembler.tasks > Translates Assembly language source files into object files. > > so I haven’t a clue what’s up with that task. > > Thanks, > Erick > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
