You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@netbeans.apache.org by Ernie Rael <er...@raelity.com> on 2022/09/21 01:00:03 UTC

Gradle: how to get IDE pickup source from open project

(Apologies if you see a duplicate)

Using NB-15, jdk-11

I have a library on MavenCentral (published from a gradle project), that 
I use in another project. I'm creating new version of that library. I'm 
into problems and peculiarities.

1. NetBeans remembered some method signatures that were not valid
2. In debugger opened source from snapshot jar file, rather than from
    open file from open project

1 seemed like a clear error; found a dance that got rid of the problem, 
see below.

If 2 is correct, how can I set things up during dev/debug to get around it?

** Some notes on 1. **

I've created a v1.1-SNAPSHOT and publishToMavenLocal.

I've got the following in BuildSrc in a project that uses the snapshot

    repositories {
         mavenCentral()
         mavenLocal()
         // maven { url
    'https://oss.sonatype.org/content/repositories/snapshots/' }
    }

I use mavenLocal to access the snapshot..

In NetBeans, working on a project that uses the snapshot, although I can 
do a clean build, I had error indicators referring to some signatures 
that are not valid in the snapshot. I tried closing NetBeans and 
clearing it's cache, restart NetBeans. What finally worked (or at least 
seemed to be related) was toggling off

    Tools > Options > Java > Gradle > Experimental > Use on-disk cache

followed by close NB, clear NB cache, restart NB. Perhaps a button: 
"clear NetBeans gradle cache" would be a better UI, at least until the 
cache is reliable. How flakey is the experimental use on-disk cache?

-ernie


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists


Re: Gradle: how to get IDE pickup source from open project

Posted by Ernie Rael <er...@raelity.com>.
On 9/23/22 10:16 AM, László Kishalmi wrote:
> Well, it seems imported build tasks are handled a bit differently. or the
> jvi-cmd:run task is not a JavaExec task.

Running the project directly, not includedBuild, with

    tasks.run { t ->
         println "****************** ${t.class.name}"

I see

     > Configure project :jvi-cmd
    ****************** org.gradle.api.tasks.JavaExec_Decorated

>
> Then I'd just create a run (JavaExec) task in your build configured the
> same way (classpath, main class etc) as it is in jvi-cmd:run
Since I just did something like "id application" and the run task 
magically appeared, this will take some investigation.
>
> BTW go you have this stuff on GitHub or somewhere public, so I can have a
> glimpse? Might be able to file a PR for you.

https://sourceforge.net/p/jvi/code

There's a "Download Snapshot" button if you don't want to use mercurial.

The composite build scripts are:

/src/jvi-dev/jvi-ide
$ for i in settings.gradle build.gradle; do echo === $i ===;cat $i;done
=== settings.gradle ===

rootProject.name = 'jvi-ide'

includeBuild '/src/jvi-dev/jvi'
=== build.gradle ===

def jvi_proj = [ ':jvi-core', ':jvi-swing', ':jvi-cmd' ]

void deps(Task t, String proj, List subprojs, String subt) {
     for(sp in subprojs) {
         t.dependsOn gradle.includedBuild(proj).task(sp + subt)
     }
}

tasks.register('clean') { task ->
     deps(task, 'jvi', jvi_proj, ':clean')
}

tasks.register('build') { task ->
     deps(task, 'jvi', jvi_proj, ':build')
}

tasks.register('run') {
     dependsOn gradle.includedBuild('jvi').task(':jvi-cmd:run')
}

>
> On Fri, Sep 23, 2022 at 9:31 AM Ernie Rael <er...@raelity.com> wrote:
>
>> On 9/22/22 10:07 PM, Laszlo Kishalmi wrote:
>>> Well, if I see well, you try to bring the jvi-cmd:run task down to the
>>> project level by defining a task that depends on that.
>>>
>>> The defined run task would be a DefaultTask, so it is not taking the
>>> --debug-jvm argument.
>>>
>>> Here instead of defining a new run task, I'd configure the ide's run
>>> and debug action to use :jvi-cmd:run  or (jvi-cmd:run I'm not sure
>>> that the first : is needed) instead of run.
>> Haven't been able to get debug action to work
>>
>> Doing
>>
>>      ConfiguredAction: debug, Arguments: :jvi:jvi-cmd:run
>>
>> And clicking debug runs the command, but no debugger. Change it to
>>
>>      Arguments: :jvi:jvi-cmd:run --debug-jvm
>>
>> But this hangs. With a different project, with unmodified actions,
>> clicking debug shows
>>
>>      cd /src/jvi-dev/jvi/jvi-cmd; ../gradlew --configure-on-demand -x
>>      check run --debug-jvm
>>
>> Tried
>>
>>      Arguments: -x check :jvi:jvi-cmd:run --debug-jvm
>>
>> which fails with "Task 'check' not found in root project 'jvi-ide'.".
>> Tried a couple "Hail Mary"s with
>>
>>      Arguments: -x :jvi:jvi-cmd:check :jvi:jvi-cmd:run --debug-jvm
>>      Arguments: -x :jvi:check :jvi:jvi-cmd:run --debug-jvm
>>
>> The first doesn't get an error, but hangs just the same. The second
>> doesn't find check in jvi.
>>
>> I thought about running the debugger from the 'buildInclude' project
>> directly, but I suspect in a more general case the dependencies would be
>> wrong.
>>
>> -ernie
>>
>>> On 9/22/22 19:37, Ernie Rael wrote:
>>>> On 9/22/22 9:15 AM, László Kishalmi wrote:
>>>>> You may find reading this one useful:
>>>>> https://docs.gradle.org/current/userguide/composite_builds.html
>>>>>
>>>> Thanks, this looks promising. I started, only for one project, with
>>>> settings.gradle
>>>>
>>>>     rootProject.name = 'jvi-ide'
>>>>
>>>>     includeBuild '/src/jvi-dev/jvi'
>>>>
>>>> Mixed in some build.gradle
>>>>
>>>>     def jvi_proj = [ ':jvi-core', ':jvi-swing', ':jvi-cmd' ]
>>>>
>>>>     void deps(Task t, String proj, List subprojs, String subt) {
>>>>          for(sp in subprojs) {
>>>>              t.dependsOn gradle.includedBuild(proj).task(sp + subt)
>>>>          }
>>>>     }
>>>>
>>>>     tasks.register('clean') { task ->
>>>>          deps(task, 'jvi', jvi_proj, ':clean')
>>>>     }
>>>>     ...
>>>>     tasks.register('run') {
>>>>          dependsOn gradle.includedBuild('jvi').task(':jvi-cmd:run')
>>>>     }
>>>>
>>>> I thought it was weird that I had to enumerate the sub-projects, but
>>>> some think I'm weird.
>>>>
>>>> Opening this project in ide I can build, clean, Use the GREEN button
>>>> to run the project, but the DEBUG button fails. Suggestions? IDE output:
>>>>
>>>> cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run
>>>> ...
>>>>> Configure project :jvi:jvi-swing
>>>> namedservicesMerge-1: project ':jvi:jvi-swing'
>>>> 'jVi/init/com.raelity.jvi.ViInitialization'
>>>> Configuration on demand is an incubating feature.
>>>>
>>>>> Task :jvi:jvi-core:compileJava UP-TO-DATE
>>>> ...
>>>>
>>>>> Task :jvi:jvi-cmd:run
>>>> ======================================================================
>>>> cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run --debug-jvm
>>>> ...
>>>>> Configure project :jvi:jvi-swing
>>>> namedservicesMerge-1: project ':jvi:jvi-swing'
>>>> 'jVi/init/com.raelity.jvi.ViInitialization'
>>>> Configuration on demand is an incubating feature.
>>>>
>>>> FAILURE: Build failed with an exception.
>>>>
>>>> * What went wrong:
>>>> Problem configuring task :run from command line.
>>>>> Unknown command-line option '--debug-jvm'.
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>>
>>> For further information about the NetBeans mailing lists, visit:
>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>
>>>
>>>
>>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists




Re: Gradle: how to get IDE pickup source from open project

Posted by László Kishalmi <la...@gmail.com>.
Well, it seems imported build tasks are handled a bit differently. or the
jvi-cmd:run task is not a JavaExec task.

Then I'd just create a run (JavaExec) task in your build configured the
same way (classpath, main class etc) as it is in jvi-cmd:run

BTW go you have this stuff on GitHub or somewhere public, so I can have a
glimpse? Might be able to file a PR for you.

On Fri, Sep 23, 2022 at 9:31 AM Ernie Rael <er...@raelity.com> wrote:

> On 9/22/22 10:07 PM, Laszlo Kishalmi wrote:
> > Well, if I see well, you try to bring the jvi-cmd:run task down to the
> > project level by defining a task that depends on that.
> >
> > The defined run task would be a DefaultTask, so it is not taking the
> > --debug-jvm argument.
> >
> > Here instead of defining a new run task, I'd configure the ide's run
> > and debug action to use :jvi-cmd:run  or (jvi-cmd:run I'm not sure
> > that the first : is needed) instead of run.
>
> Haven't been able to get debug action to work
>
> Doing
>
>     ConfiguredAction: debug, Arguments: :jvi:jvi-cmd:run
>
> And clicking debug runs the command, but no debugger. Change it to
>
>     Arguments: :jvi:jvi-cmd:run --debug-jvm
>
> But this hangs. With a different project, with unmodified actions,
> clicking debug shows
>
>     cd /src/jvi-dev/jvi/jvi-cmd; ../gradlew --configure-on-demand -x
>     check run --debug-jvm
>
> Tried
>
>     Arguments: -x check :jvi:jvi-cmd:run --debug-jvm
>
> which fails with "Task 'check' not found in root project 'jvi-ide'.".
> Tried a couple "Hail Mary"s with
>
>     Arguments: -x :jvi:jvi-cmd:check :jvi:jvi-cmd:run --debug-jvm
>     Arguments: -x :jvi:check :jvi:jvi-cmd:run --debug-jvm
>
> The first doesn't get an error, but hangs just the same. The second
> doesn't find check in jvi.
>
> I thought about running the debugger from the 'buildInclude' project
> directly, but I suspect in a more general case the dependencies would be
> wrong.
>
> -ernie
>
> >
> > On 9/22/22 19:37, Ernie Rael wrote:
> >> On 9/22/22 9:15 AM, László Kishalmi wrote:
> >>> You may find reading this one useful:
> >>> https://docs.gradle.org/current/userguide/composite_builds.html
> >>>
> >> Thanks, this looks promising. I started, only for one project, with
> >> settings.gradle
> >>
> >>    rootProject.name = 'jvi-ide'
> >>
> >>    includeBuild '/src/jvi-dev/jvi'
> >>
> >> Mixed in some build.gradle
> >>
> >>    def jvi_proj = [ ':jvi-core', ':jvi-swing', ':jvi-cmd' ]
> >>
> >>    void deps(Task t, String proj, List subprojs, String subt) {
> >>         for(sp in subprojs) {
> >>             t.dependsOn gradle.includedBuild(proj).task(sp + subt)
> >>         }
> >>    }
> >>
> >>    tasks.register('clean') { task ->
> >>         deps(task, 'jvi', jvi_proj, ':clean')
> >>    }
> >>    ...
> >>    tasks.register('run') {
> >>         dependsOn gradle.includedBuild('jvi').task(':jvi-cmd:run')
> >>    }
> >>
> >> I thought it was weird that I had to enumerate the sub-projects, but
> >> some think I'm weird.
> >>
> >> Opening this project in ide I can build, clean, Use the GREEN button
> >> to run the project, but the DEBUG button fails. Suggestions? IDE output:
> >>
> >> cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run
> >> ...
> >> > Configure project :jvi:jvi-swing
> >> namedservicesMerge-1: project ':jvi:jvi-swing'
> >> 'jVi/init/com.raelity.jvi.ViInitialization'
> >> Configuration on demand is an incubating feature.
> >>
> >> > Task :jvi:jvi-core:compileJava UP-TO-DATE
> >> ...
> >>
> >> > Task :jvi:jvi-cmd:run
> >>
> >> ======================================================================
> >> cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run --debug-jvm
> >> ...
> >> > Configure project :jvi:jvi-swing
> >> namedservicesMerge-1: project ':jvi:jvi-swing'
> >> 'jVi/init/com.raelity.jvi.ViInitialization'
> >> Configuration on demand is an incubating feature.
> >>
> >> FAILURE: Build failed with an exception.
> >>
> >> * What went wrong:
> >> Problem configuring task :run from command line.
> >> > Unknown command-line option '--debug-jvm'.
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>
>

Re: Gradle: how to get IDE pickup source from open project

Posted by Ernie Rael <er...@raelity.com>.
On 9/22/22 10:07 PM, Laszlo Kishalmi wrote:
> Well, if I see well, you try to bring the jvi-cmd:run task down to the 
> project level by defining a task that depends on that.
>
> The defined run task would be a DefaultTask, so it is not taking the 
> --debug-jvm argument.
>
> Here instead of defining a new run task, I'd configure the ide's run 
> and debug action to use :jvi-cmd:run  or (jvi-cmd:run I'm not sure 
> that the first : is needed) instead of run.

Haven't been able to get debug action to work

Doing

    ConfiguredAction: debug, Arguments: :jvi:jvi-cmd:run

And clicking debug runs the command, but no debugger. Change it to

    Arguments: :jvi:jvi-cmd:run --debug-jvm

But this hangs. With a different project, with unmodified actions, 
clicking debug shows

    cd /src/jvi-dev/jvi/jvi-cmd; ../gradlew --configure-on-demand -x
    check run --debug-jvm

Tried

    Arguments: -x check :jvi:jvi-cmd:run --debug-jvm

which fails with "Task 'check' not found in root project 'jvi-ide'.". 
Tried a couple "Hail Mary"s with

    Arguments: -x :jvi:jvi-cmd:check :jvi:jvi-cmd:run --debug-jvm
    Arguments: -x :jvi:check :jvi:jvi-cmd:run --debug-jvm

The first doesn't get an error, but hangs just the same. The second 
doesn't find check in jvi.

I thought about running the debugger from the 'buildInclude' project 
directly, but I suspect in a more general case the dependencies would be 
wrong.

-ernie

>
> On 9/22/22 19:37, Ernie Rael wrote:
>> On 9/22/22 9:15 AM, László Kishalmi wrote:
>>> You may find reading this one useful:
>>> https://docs.gradle.org/current/userguide/composite_builds.html
>>>
>> Thanks, this looks promising. I started, only for one project, with 
>> settings.gradle
>>
>>    rootProject.name = 'jvi-ide'
>>
>>    includeBuild '/src/jvi-dev/jvi'
>>
>> Mixed in some build.gradle
>>
>>    def jvi_proj = [ ':jvi-core', ':jvi-swing', ':jvi-cmd' ]
>>
>>    void deps(Task t, String proj, List subprojs, String subt) {
>>         for(sp in subprojs) {
>>             t.dependsOn gradle.includedBuild(proj).task(sp + subt)
>>         }
>>    }
>>
>>    tasks.register('clean') { task ->
>>         deps(task, 'jvi', jvi_proj, ':clean')
>>    }
>>    ...
>>    tasks.register('run') {
>>         dependsOn gradle.includedBuild('jvi').task(':jvi-cmd:run')
>>    }
>>
>> I thought it was weird that I had to enumerate the sub-projects, but 
>> some think I'm weird.
>>
>> Opening this project in ide I can build, clean, Use the GREEN button 
>> to run the project, but the DEBUG button fails. Suggestions? IDE output:
>>
>> cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run
>> ...
>> > Configure project :jvi:jvi-swing
>> namedservicesMerge-1: project ':jvi:jvi-swing' 
>> 'jVi/init/com.raelity.jvi.ViInitialization'
>> Configuration on demand is an incubating feature.
>>
>> > Task :jvi:jvi-core:compileJava UP-TO-DATE
>> ...
>>
>> > Task :jvi:jvi-cmd:run
>>
>> ======================================================================
>> cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run --debug-jvm
>> ...
>> > Configure project :jvi:jvi-swing
>> namedservicesMerge-1: project ':jvi:jvi-swing' 
>> 'jVi/init/com.raelity.jvi.ViInitialization'
>> Configuration on demand is an incubating feature.
>>
>> FAILURE: Build failed with an exception.
>>
>> * What went wrong:
>> Problem configuring task :run from command line.
>> > Unknown command-line option '--debug-jvm'.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists




Re: Gradle: how to get IDE pickup source from open project

Posted by Laszlo Kishalmi <la...@gmail.com>.
Well, if I see well, you try to bring the jvi-cmd:run task down to the 
project level by defining a task that depends on that.

The defined run task would be a DefaultTask, so it is not taking the 
--debug-jvm argument.

Here instead of defining a new run task, I'd configure the ide's run and 
debug action to use :jvi-cmd:run  or (jvi-cmd:run I'm not sure that the 
first : is needed) instead of run.

On 9/22/22 19:37, Ernie Rael wrote:
> On 9/22/22 9:15 AM, László Kishalmi wrote:
>> You may find reading this one useful:
>> https://docs.gradle.org/current/userguide/composite_builds.html
>>
> Thanks, this looks promising. I started, only for one project, with 
> settings.gradle
>
>    rootProject.name = 'jvi-ide'
>
>    includeBuild '/src/jvi-dev/jvi'
>
> Mixed in some build.gradle
>
>    def jvi_proj = [ ':jvi-core', ':jvi-swing', ':jvi-cmd' ]
>
>    void deps(Task t, String proj, List subprojs, String subt) {
>         for(sp in subprojs) {
>             t.dependsOn gradle.includedBuild(proj).task(sp + subt)
>         }
>    }
>
>    tasks.register('clean') { task ->
>         deps(task, 'jvi', jvi_proj, ':clean')
>    }
>    ...
>    tasks.register('run') {
>         dependsOn gradle.includedBuild('jvi').task(':jvi-cmd:run')
>    }
>
> I thought it was weird that I had to enumerate the sub-projects, but 
> some think I'm weird.
>
> Opening this project in ide I can build, clean, Use the GREEN button 
> to run the project, but the DEBUG button fails. Suggestions? IDE output:
>
> cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run
> ...
> > Configure project :jvi:jvi-swing
> namedservicesMerge-1: project ':jvi:jvi-swing' 
> 'jVi/init/com.raelity.jvi.ViInitialization'
> Configuration on demand is an incubating feature.
>
> > Task :jvi:jvi-core:compileJava UP-TO-DATE
> ...
>
> > Task :jvi:jvi-cmd:run
>
> ======================================================================
> cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run --debug-jvm
> ...
> > Configure project :jvi:jvi-swing
> namedservicesMerge-1: project ':jvi:jvi-swing' 
> 'jVi/init/com.raelity.jvi.ViInitialization'
> Configuration on demand is an incubating feature.
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Problem configuring task :run from command line.
> > Unknown command-line option '--debug-jvm'.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists




Re: Gradle: how to get IDE pickup source from open project

Posted by Ernie Rael <er...@raelity.com>.
On 9/22/22 9:15 AM, László Kishalmi wrote:
> You may find reading this one useful:
> https://docs.gradle.org/current/userguide/composite_builds.html
>
Thanks, this looks promising. I started, only for one project, with 
settings.gradle

    rootProject.name = 'jvi-ide'

    includeBuild '/src/jvi-dev/jvi'

Mixed in some build.gradle

    def jvi_proj = [ ':jvi-core', ':jvi-swing', ':jvi-cmd' ]

    void deps(Task t, String proj, List subprojs, String subt) {
         for(sp in subprojs) {
             t.dependsOn gradle.includedBuild(proj).task(sp + subt)
         }
    }

    tasks.register('clean') { task ->
         deps(task, 'jvi', jvi_proj, ':clean')
    }
    ...
    tasks.register('run') {
         dependsOn gradle.includedBuild('jvi').task(':jvi-cmd:run')
    }

I thought it was weird that I had to enumerate the sub-projects, but 
some think I'm weird.

Opening this project in ide I can build, clean, Use the GREEN button to 
run the project, but the DEBUG button fails. Suggestions? IDE output:

cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run
...
 > Configure project :jvi:jvi-swing
namedservicesMerge-1: project ':jvi:jvi-swing' 
'jVi/init/com.raelity.jvi.ViInitialization'
Configuration on demand is an incubating feature.

 > Task :jvi:jvi-core:compileJava UP-TO-DATE
...

 > Task :jvi:jvi-cmd:run

======================================================================
cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run --debug-jvm
...
 > Configure project :jvi:jvi-swing
namedservicesMerge-1: project ':jvi:jvi-swing' 
'jVi/init/com.raelity.jvi.ViInitialization'
Configuration on demand is an incubating feature.

FAILURE: Build failed with an exception.

* What went wrong:
Problem configuring task :run from command line.
 > Unknown command-line option '--debug-jvm'.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists




Re: Gradle: how to get IDE pickup source from open project

Posted by László Kishalmi <la...@gmail.com>.
You may find reading this one useful:
https://docs.gradle.org/current/userguide/composite_builds.html

On Thu, Sep 22, 2022 at 7:43 AM Ernie Rael <er...@raelity.com> wrote:

> Thanks László,
>
> Since I got thing back in sync, have not seen the problem. I tried what
> I think were similar steps, it /did not reproduce/. Did not get into a
> situation where it seemed like I needed to nuke the on disk cache.
> Here's the steps, I see some things I'm not sure about, clarification on
> expectations would be great.
>
> Given two separate projects: app, lib. Where lib publishes to maven
> repository
>
>  1. put method "void XXX(String)" in lib
>     Publish lib local from console, access it from lib in IDE, build ok.
>  2. modify lib sig to "void XXX(int)", publish lib local to new version
>     from console
>  3. In app's buildSrc to reference new version. (but don't fix call to
>     XXX new arg type)
>     IDE shows no error, build app from IDE, build gets error
>  4. build lib in IDE, IDE still shows no error in app
>  5. change sig in app to call "XXX(int)"
>     IDE shows error, but IDE builds with no error
>  6. Close IDE, flush IDE cache, restart IDE
>     IDE shows no error, seems like flush cleared up problem in IDE cache
>
> So I could not reproduce a problem that required gradle cache cleanup.
> (though it seems I had reproducible steps that required IDE flush) I
> tried similar steps again, but instead in step 2, I used IDE to run
> action from navigator to publish lib to local maven, and IDE picked up
> the change and were consistent. So it seems like running stuff from
> console, isn't always picked up from the IDE. Was I hallucinating?
>
> Good to know about "Reload" project. If I see something peculiar, I can
> try that.
>
> I will stop using SNAPSHOTS, thanks. I guess the key is to turn off
> mavenLocal() to verify that I need to publish something :-)
>
> -ernie
>
> On 9/20/22 10:53 PM, László Kishalmi wrote:
> > I would say the on-disk cache is pretty stable by now, probably we
> > should remove that from being experimental.
> > I would check the project properties, the Sources section, and the
> > compile classpath section if that looks right.
> > You could check if reloading the project (right click on the project
> > node, the Reload) would help. That one would clear the cache and get a
> > fresh information from Gradle.
> > So, if that's not helping then, there is something else that the IDE
> > does not pick up.
> >
> > If the project could be disclosed, I could take a look.
> >
> > Hint: One of the bad things Maven introduced were the SNAPSHOT
> > versions. They created them as in the early days (probably pre 3.0)
> > the only way to reference dependencies between entities (sub projects
> > in Gradle term) of in a multi-pom projects was through the deployed
> > SNAPSHOT version of the library in the Local Maven repository. That's
> > gone now. SNAPSHOT versions should be avoided.
> >
> > On Tue, Sep 20, 2022 at 6:00 PM Ernie Rael <er...@raelity.com> wrote:
> >
> >     (Apologies if you see a duplicate)
> >
> >     Using NB-15, jdk-11
> >
> >     I have a library on MavenCentral (published from a gradle
> >     project), that
> >     I use in another project. I'm creating new version of that
> >     library. I'm
> >     into problems and peculiarities.
> >
> >     1. NetBeans remembered some method signatures that were not valid
> >     2. In debugger opened source from snapshot jar file, rather than from
> >         open file from open project
> >
> >     1 seemed like a clear error; found a dance that got rid of the
> >     problem,
> >     see below.
> >
> >     If 2 is correct, how can I set things up during dev/debug to get
> >     around it?
> >
> >     ** Some notes on 1. **
> >
> >     I've created a v1.1-SNAPSHOT and publishToMavenLocal.
> >
> >     I've got the following in BuildSrc in a project that uses the
> snapshot
> >
> >         repositories {
> >              mavenCentral()
> >              mavenLocal()
> >              // maven { url
> >         'https://oss.sonatype.org/content/repositories/snapshots/' }
> >         }
> >
> >     I use mavenLocal to access the snapshot..
> >
> >     In NetBeans, working on a project that uses the snapshot, although
> >     I can
> >     do a clean build, I had error indicators referring to some signatures
> >     that are not valid in the snapshot. I tried closing NetBeans and
> >     clearing it's cache, restart NetBeans. What finally worked (or at
> >     least
> >     seemed to be related) was toggling off
> >
> >         Tools > Options > Java > Gradle > Experimental > Use on-disk
> cache
> >
> >     followed by close NB, clear NB cache, restart NB. Perhaps a button:
> >     "clear NetBeans gradle cache" would be a better UI, at least until
> >     the
> >     cache is reliable. How flakey is the experimental use on-disk cache?
> >
> >     -ernie
> >
> >
> >     ---------------------------------------------------------------------
> >     To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
> >     For additional commands, e-mail: users-help@netbeans.apache.org
> >
> >     For further information about the NetBeans mailing lists, visit:
> >     https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
>
>