Re: Update Center Problem, ant vs maven
Something about shooting myself in the foot.
BTW, the only docs I'm finding for nbm-maven-plugin are through
bits.netbeans.org.
For codeNameBase Default value is:
${project.groupId}.${project.artifactId} in fact.
In order to get a plugin into the old plugin repository, which sadly is
the only way to get something automatically into the plugin manager, it
needs to be old style java signed. The stuff I added to the pom changed
the default codenamebase...
-ernie
On 3/22/2020 1:04 PM, Ernie Rael wrote:
(before I file an issue, a sanity check is appreciated)
I've got an nbm, "jVi Core" (it's a wrapper nbm) with
com.raelity.jvi
and recently created a new maven based update center "jVi for NB
Update Center" with
com.raelity.jvi
nb-uc
The plugin manager is saying that "jVi UC" has an update pending of
"jVi Core". In the debugger I'm seeing, from
platform/autoupdate.services/.../UpdateElement.toString(),
jVi for NB Update Center[com.raelity.jvi/1.2.1]
and
jVi Core[com.raelity.jvi/1.6.19.37]
And toString is defined as
impl.getDisplayName() + "[" + impl.getCodeName ()
+ "/" + impl.getSpecificationVersion () + "]";
If I do an update, "jVi Core" does not actually replace "jVi UC"
(h, I don't think it does), but I'm getting some weird behavior
though eventually I can get things loaded.
I think getCodeName() is used in compares. My first thought is that
impl.getCodeName() should include the artifactId somehow.
I'm still looking through code, but if someone can shed some light...
I guess my biggest question is whether there's a bug in the plugin
manager related to maven artifacts or whether I've got a naming
problem (or both?)
Any insight appreciated.
-ernie
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re: Buildin Gradle not using Wrapper?
hi @Laszlo Kishalmi , If i return NULL from that method, i still get the behaviour of the default gradle dist being used, so no wrapper download. Sorry, busy busy this side with organising people to work from home due to the covid19 stuff. I also had another issue i thought we could address - that of NB "remembering" the type of project it opened. At the moment, if a project has a POM and ./gradle dir, the behaviour depends on the Prefer Maven Option setting. However, would it not be better for the project to be opened as either, depending on the user selection, and then persisted, until changed? Regards Jon On Tue, Mar 17, 2020 at 1:46 PM Eric Bresie wrote: > I don’t suppose this could be a matter of classpath/path settings causing > erratic behavior could it? > > Could there be/have been conflicting (different versions) Gradle daemons > running? > > Eric Bresie > ebre...@gmail.com > > On March 16, 2020 at 8:46:10 PM CDT, Laszlo Kishalmi < > laszlo.kisha...@gmail.com> wrote: > > I meant, be brave, change the code! Just return null and see what > happens. > > > > Then probably set a Breakpoint at line 127 on GradleDaemonExecutor to > > see the rest. Just experiment with it! > > > > On 3/16/20 5:14 PM, Jonathan Bergh wrote: > > > Hi Laszlo, > > > > > > I'm sorry, i dont quite get what you mean. > > > > > > If i select Use Wrapper, and and use either Custom or Standard, it > does not > > > matter - if the wrapper in the project > > > ./gradle/wrapper/gradle-wrapper.properties is present in > > > ./.gradle/wrappers/dist, then it will use the wrapper. If the wrapper > is > > > not present in ./.gradle/wrapper/dist then it will not, and NB will > use the > > > Standard version? > > > > > > I tested with a couple of projects and breakpoints. > > > > > > Regards > > > Jonathan > > > > > > On Tue, Mar 17, 2020 at 2:07 AM Laszlo Kishalmi < > laszlo.kisha...@gmail.com> > > > wrote: > > > > > > > Well, first just test what happens if you do not select the default. > > > > Ideally Gradle would download the required binary. There was > something > > > > around that (if I remember well). So let's test how Gradle behaves > and > > > > plan according to that. > > > > > > > > On 3/16/20 5:03 PM, Jonathan Bergh wrote: > > > > > Hi Laszlo, > > > > > > > > > > So i have inspected the code and can confirm the above behaviour > (even if > > > > > Use Wrapper is selected, if the wrapper dist is missing, NB will > default > > > > to > > > > > NB default). > > > > > > > > > > 1) Can we confirm the agreed behaviour then - that IF Use Wrapper > is > > > > > selected, even if the gradle dist is missing, this will be > downloaded? > > > > This > > > > > seems to be the point of wrapper so i suggest this. > > > > > 2) What do we do while the dist is downloading (assume we use a > > > > > RequestProcessor for download in background?). Do we block until > download > > > > > is complete? or what do we do? > > > > > > > > > > Thanks > > > > > Regards > > > > > Jon > > > > > > > > > > > > > > > On Mon, Mar 16, 2020 at 4:40 PM Laszlo Kishalmi < > > > > laszlo.kisha...@gmail.com> > > > > > wrote: > > > > > > > > > > > On 3/15/20 6:03 PM, Jonathan Bergh wrote: > > > > > > > OK, thanks Laszlo, > > > > > > > > > > > > > > That makes sense, at least i am not going crazy ;) ! > > > > > > > > > > > > > > I have just downloaded Netbeans project now, and am building > it, so > > > > > > > hopefully i can have a look too. Maybe i can ask you some > questions > > > > about > > > > > > > your implementation and we fix it together. > > > > > > Wow, that's great! Here are some hints to get you started: > > > > > > > > > > > > Once you've built NetBeans, you can load the groovy/gradle > project into > > > > > > NetBeans > > > > > > > > > > > > put a breakpoint to: > > > > > > > > > > > org.netbeans.modules.gradle.api.execute.RunUtils.evaluateGradleDistribution, > > > > > > then choose Debug project to start aNetBeans debug instance, you > might > > > > > > need to enable the java and groovy pluginsagain there and load > your > > > > > > project, then build. The breakpoint will be hit. > > > > > > > > > > > > > Thanks for all your help / work so far, > > > > > > > Much appreciated > > > > > > > Jonathan > > > > > > > > > > > > > > PS i have tested again, and yes, if i manually download the > wrapper, > > > > then > > > > > > > Netbeans selects the correct wrapper and builds with that. If > not, it > > > > > > > default back to the main NB system gradle. > > > > > > > > > > > > > > On Mon, Mar 16, 2020 at 2:57 AM Laszlo Kishalmi < > > > > > > laszlo.kisha...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > On 3/15/20 5:45 PM, Jonathan Bergh wrote: > > > > > > > > > The IDE itself needs to run on Java 8 in order to be able > to use > > > > Gardle > > > > > > > > > 4.10 and less. It is not enough to set up the project > compile options > > > > > > to > > > > > > > > > point to Java 8. It is because the listening part of the > Gradle > > >
Re: NetBeans 12.0, Groovy and Java 14
PR available, added testing on 11, 14 to the travis matrix ;-) Now back to figuring out Groovy 3 stuff... -Sven On Sat, Mar 21, 2020 at 10:30 PM Sven Reimers wrote: > Started work - see > > https://issues.apache.org/jira/browse/NETBEANS-4051 > > Hope to get it ready for 12.0 > > -Sven > > On Thu, Mar 19, 2020 at 7:31 AM Benjamin Graf > wrote: > >> Big +1 to update to Groovy 2.5.10 >> >> Benjamin >> >> On 19.03.2020 06:11, Geertjan Wielenga wrote: >> > Yes, we can include this in one of the betas, if Eric permits, as >> release >> > manager. >> > >> > Gj >> > >> > On Wed, 18 Mar 2020 at 23:54, Sven Reimers >> wrote: >> > >> >> Hi all, >> >> >> >> seems there is an issue with the Groovy version provided with NetBeans >> wrt >> >> running on top of Java 14 - some class not found stuff which occurs >> during >> >> parsing. >> >> >> >> Seems the easy fix would be to update to latest Groovy 2.5.x series, >> which >> >> should fix the issue. >> >> >> >> I would try to create a PR for this, if everyone agrees that this >> would be >> >> good to have on NetBeans 12.0 - else I may just look at getting latest >> >> Groovy 3.0.x ready for NetBeans 12.x >> >> >> >> Comments? >> >> >> >> -Sven >> >> >> >> -- >> >> Sven Reimers >> >> >> >> * Java Champion >> >> * Apache NetBeans PMC: http://netbeans.apache.org >> >> * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee >> >> * Duke's Choice Award Winner 2009 & 2018 >> >> >> >> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >> >> >> > > -- > Sven Reimers > > * Java Champion > * Apache NetBeans PMC: http://netbeans.apache.org > * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee > * Duke's Choice Award Winner 2009 & 2018 > > * LinkedIn: http://www.linkedin.com/in/svenreimers > -- Sven Reimers * Java Champion * Apache NetBeans PMC: http://netbeans.apache.org * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee * Duke's Choice Award Winner 2009 & 2018 * LinkedIn: http://www.linkedin.com/in/svenreimers
Update Center Problem, ant vs maven
(before I file an issue, a sanity check is appreciated) I've got an nbm, "jVi Core" (it's a wrapper nbm) with com.raelity.jvi and recently created a new maven based update center "jVi for NB Update Center" with com.raelity.jvi nb-uc The plugin manager is saying that "jVi UC" has an update pending of "jVi Core". In the debugger I'm seeing, from platform/autoupdate.services/.../UpdateElement.toString(), jVi for NB Update Center[com.raelity.jvi/1.2.1] and jVi Core[com.raelity.jvi/1.6.19.37] And toString is defined as impl.getDisplayName() + "[" + impl.getCodeName () + "/" + impl.getSpecificationVersion () + "]"; If I do an update, "jVi Core" does not actually replace "jVi UC" (h, I don't think it does), but I'm getting some weird behavior though eventually I can get things loaded. I think getCodeName() is used in compares. My first thought is that impl.getCodeName() should include the artifactId somehow. I'm still looking through code, but if someone can shed some light... I guess my biggest question is whether there's a bug in the plugin manager related to maven artifacts or whether I've got a naming problem (or both?) Any insight appreciated. -ernie - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Verschlüsselte Nachricht
Sorry missed this issue... -Sven Benjamin Graf schrieb am So., 22. März 2020, 07:35: > Hi Sven, > > but why another new issue ticket? ( > https://issues.apache.org/jira/plugins/servlet/mobile#issue/NETBEANS-3876) > > Regards > Benjamin > > Am 21. März 2020 22:30:17 MEZ schrieb Sven Reimers >: > >Started work - see > > > >https://issues.apache.org/jira/browse/NETBEANS-4051 > > > >Hope to get it ready for 12.0 > > > >-Sven > > > >On Thu, Mar 19, 2020 at 7:31 AM Benjamin Graf > wrote: > > > >> Big +1 to update to Groovy 2.5.10 > >> > >> Benjamin > >> > >> On 19.03.2020 06:11, Geertjan Wielenga wrote: > >> > Yes, we can include this in one of the betas, if Eric permits, as > release > >> > manager. > >> > > >> > Gj > >> > > >> > On Wed, 18 Mar 2020 at 23:54, Sven Reimers > >> wrote: > >> > > >> >> Hi all, > >> >> > >> >> seems there is an issue with the Groovy version provided with > NetBeans > >> wrt > >> >> running on top of Java 14 - some class not found stuff which occurs > >> during > >> >> parsing. > >> >> > >> >> Seems the easy fix would be to update to latest Groovy 2.5.x series, > >> which > >> >> should fix the issue. > >> >> > >> >> I would try to create a PR for this, if everyone agrees that this > would > >> be > >> >> good to have on NetBeans 12.0 - else I may just look at getting > latest > >> >> Groovy 3.0.x ready for NetBeans 12.x > >> >> > >> >> Comments? > >> >> > >> >> -Sven > >> >> > >> >> -- > >> >> Sven Reimers > >> >> > >> >> * Java Champion > >> >> * Apache NetBeans PMC: http://netbeans.apache.org > >> >> * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee > >> >> * Duke's Choice Award Winner 2009 & 2018 > >> >> > >> >> * LinkedIn: http://www.linkedin.com/in/svenreimers > >> >> > >> > >> > > > > -- > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
