Well, I'll be ... this is it! Thanks SO much Laszlo, you made my day :-)
Am Do., 26. Dez. 2019 um 17:54 Uhr schrieb Laszlo Kishalmi <
laszlo.kisha...@gmail.com>:
> The includeBuild in the settings script makes the bind
>
> The included build would get it's metadata read group, module, version and
> would be replaced to local file references by Gradle on the file without
> repository lookup.
> On 12/26/19 8:27 AM, Dr. Matthias Laux wrote:
>
> Hi Laszlo,
>
> then how would the build process find the other project?
>
> For example I have this in one of the projects:
>
> repositories {
> mavenCentral()
> }
>
> dependencies {
> compile (
> [group: 'org.apache.poi', name: 'poi', version: '[4.1,)'],
> [group: 'org.apache.poi', name: 'poi-ooxml', version: '[4.1,)'],
> [group: 'org.apache.poi', name: 'ooxml-schemas', version:
> '[1.4,)'],
> fileTree(dir: "../LaunixTools/build/libs", include: '*.jar')
> )
> }
>
> the [group] dependencies are resolved via mavenCentral and with the
> fileTree, at least I can point to my other project LaunixTools and its jar
> files as dependencies.
> This doesn't cause a recompile tho if any source file in project
> LaunixTools changes.
> Can I somehow tell Gradle in the repositories{} section to scan certain
> local subdirectories? Or how would you recommend I implement your
> recommendation?
>
> Thanks again, Matthias
>
>
>
>
> Am Do., 26. Dez. 2019 um 16:35 Uhr schrieb Laszlo Kishalmi <
> laszlo.kisha...@gmail.com>:
>
>> I do not think that storing the artifact to local maven repo is necessary
>> at all.
>> On 12/22/19 8:49 AM, Dr. Matthias Laux wrote:
>>
>> Hi Laszlo,
>>
>> thanks much - indeed I apparently used the wrong terminology here, we're
>> talking a composite build then.
>>
>> However, for that syntax to work
>>
>> <group of project A>:<name of project A>:<version of project A>
>>
>> I'd need to store (in this case) project A in a local Maven repo since A
>> and B are my own stuff. I was hoping to
>> get it done via a filetree directive in the dependencies section.
>>
>> Thanks
>> Matthias
>>
>>
>> Am So., 22. Dez. 2019 um 16:27 Uhr schrieb Laszlo Kishalmi <
>> laszlo.kisha...@gmail.com>:
>>
>>> Well this set up seems to be a bit odd.
>>>
>>> What you described is not a multi-project build. It seems you are trying
>>> to use two standalone Gradle projects with weak include-build dependency
>>> called composite builds. I'm not sure if that would be your intention to
>>> do, but that works if you specify the dependency on project a with
>>> <group of project A>:<name of project A>:<version of project A> (though
>>> I'm not sure if the version is required)
>>>
>>> See: https://docs.gradle.org/current/userguide/composite_builds.html
>>>
>>> On 12/22/19 6:40 AM, Dr. Matthias Laux wrote:
>>> > Greetings,
>>> >
>>> > I have a Gradle rookie question which I was not able to solve after
>>> > searching the internet for a considerable amount of time, maybe you
>>> > can help.
>>> > I recently decided to upgrade all of my Java projects in netbeans from
>>> > Ant to Gradle build and after a bit of a learning curve it works,
>>> > except for
>>> > one thing: recompiling project dependencies when I change source code
>>> > there.
>>> >
>>> > Example:
>>> >
>>> > - Project A is required for Project B
>>> > - Project B has this in settings.gradle:
>>> > includeBuild '../A'
>>> > pointing to the root directory of project A
>>> > - Project B has a dependency in its build.gradle:
>>> >
>>> > dependencies {
>>> > testCompile group: 'junit', name: 'junit', version: '4.12'
>>> > compile(
>>> > fileTree(dir: "../A/build/libs", include: '*.jar'),
>>> > fileTree(dir: "../A/src", include: '*.java')
>>> > )
>>> > }
>>> >
>>> > My expectation is that if I want to run B and prior to that make a
>>> > change in A, the IDE notices and recompiles as necessary project A
>>> > first. This
>>> > works out-of-the-box for Ant when I add A as a project dependency for
>>> > B, but for my current Gradle setup, I need to manually
>>> > recompile A first. One would think that this can't be the final answer
>>> > here, so I must be doing something wrong.
>>> >
>>> > Any hints greatly appreciated.
>>> > Thx Matthias
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
>>> For additional commands, e-mail: users-h...@netbeans.apache.org
>>>
>>> For further information about the NetBeans mailing lists, visit:
>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>
>>>
