Apache NetBeans 12.0-u2 is Available for Testing

2021-01-26 Thread Laszlo Kishalmi

Dear all,

Unfortunately life keeps me busy elsewhere, so there is not too much 
energy I can put in here now.


I've built the, I hope final, build of NetBeans 12.0-u2. It can be 
tested by adding the following UC to an existing NetBeans 12.0 installation:


https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/release120/24/artifact/dist/netbeans/nbms/updates.xml.gz

The changes went into this update are:

https://github.com/apache/netbeans/pulls?q=is%3Aclosed+milestone%3A12.0-u2

I still have to put the release content together for the voting round, I 
hope I can do that in the upcoming week, till then please test!


--

  Laszlo Kishalmi


-
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: How to implement a new language on LSP (Python)

2021-01-26 Thread Jan Lahoda
Hi,

I've started with a page here:
https://cwiki.apache.org/confluence/display/NETBEANS/Adding+New+Language+Support

Feedback, or improvements based on experiences are welcome!

Jan


On Sun, Jan 24, 2021 at 3:22 PM Matthias Bläsing 
wrote:

> Hi Eric,
>
> Am Samstag, den 23.01.2021, 14:37 -0600 schrieb Eric Bresie:
> If one was to want to implement a new language using LSP, what does
> that
> take?  Is there any document on doing so?
>
> have a look at the TypeScript module (webcommon/typescript.editor) or
> the whole cpplite cluster. Both build on top of lsp support.
>
> Greetings
>
> Matthias
>
>
> -
> 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: Maven Archetypes

2021-01-26 Thread Josh Juneau
Hi Will,

Thanks for the great feedback on the Java EE 8 archetype that is being used 
with Apache NetBeans.  When I created the archetype, it was not meant to become 
a standard.  Rather, it was meant as a starting point for Java EE 8 projects 
and to get Java EE 8 project support into Apache NetBeans.  I was hoping that 
it would be built upon by the community over time, and even that a better and 
more standardized Maven archetype be put into place.

All that said, I think it would be great to have the Apache NetBeans projects 
generated by Maven archetypes that are all hosted under a standard namespace.  
We should also be updating the archetypes as time goes on, as needed.  These 
are community supported, just like Apache NetBeans, so they should continue to 
evolve.

Please feel free to fork the Java EE 8 archetype and modify it, and/or put in a 
PR to modify NetBeans so that it points to a more standard archetype.  Also 
note, I have created a Jakarta EE 9 maven archetype for Apache NetBeans use for 
a future release.  Feel free to contribute to that one as well.

https://github.com/juneau001/javaee8-archetype
https://github.com/juneau001/jakartaee9_archetype

In the meantime, I definitely agree that we should aim to place all of the 
archetypes that are in-use by Apache NetBeans into a standardized Maven Central 
namespace.

Thanks again...I appreciate your time and feedback.

  
Josh Juneau
juneau...@gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/us/search?query=Juneau

> On Jan 26, 2021, at 4:20 PM, Will Hartung  wrote:
> 
> The JEE Maven archetypes are a bit of a disaster right now, there's
> relevant issues in JIRA already.
> 
> But it brought up a question.
> 
> Historically, and currently, the archetypes used for these projects (I
> don't know about others) are not part of Netbeans. They're external
> archetypes used by Netbeans.
> 
> For example, originally, there were several from
> org.codehaus.mojo.archetypes. I don't know the original relationship
> between Sun/Oracle and codehaus.
> 
> The current ones, for JEE 8, are from io.github.juneau001.
> 
> Now, barring the detail that the JEE 8 ones are just flat out wrong given
> the structure of the JEE Maven Application Wizard (honestly, I don't know
> how these were committed -- this isn't even a subtle failure), I'm curious
> whether these should be "owned" by the Netbeans project, rather than a kind
> contributor.
> 
> By own, I simply mean they're under the netbeans.apache.org name space, and
> the archetype templates are checked in to the NB source tree and, somehow,
> they're distributed to an appropriate Maven Repo to ideally get picked up
> by Maven Central.
> 
> Does Netbeans already have a mechanism for publishing and managing
> archetypes? Any reason that NB can't or shouldn't do that?
> 
> Regards,
> 
> Will Hartung
> ]


Re: Netbeans Bug (With Bug Bounty)

2021-01-26 Thread August Nagro
Trying out a different editor now, so going to retract the bug
bounties unless someone already started on them.

Regards,

August

On Wed, Jan 20, 2021 at 10:37 PM August Nagro  wrote:
>
> Hello,
>
> I am new to Netbeans and am enjoying it so far. I have
> encountered 5 bugs. I've documented them here:
>
> https://github.com/AugustNagro/netbeans-bugs/tree/master/public_html
>
> I will pay $40 USD per bug. I know it's not much, but hope it's
> motivational for someone.
>
> Cheers,
>
> August

-
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





Maven Archetypes

2021-01-26 Thread Will Hartung
The JEE Maven archetypes are a bit of a disaster right now, there's
relevant issues in JIRA already.

But it brought up a question.

Historically, and currently, the archetypes used for these projects (I
don't know about others) are not part of Netbeans. They're external
archetypes used by Netbeans.

For example, originally, there were several from
org.codehaus.mojo.archetypes. I don't know the original relationship
between Sun/Oracle and codehaus.

The current ones, for JEE 8, are from io.github.juneau001.

Now, barring the detail that the JEE 8 ones are just flat out wrong given
the structure of the JEE Maven Application Wizard (honestly, I don't know
how these were committed -- this isn't even a subtle failure), I'm curious
whether these should be "owned" by the Netbeans project, rather than a kind
contributor.

By own, I simply mean they're under the netbeans.apache.org name space, and
the archetype templates are checked in to the NB source tree and, somehow,
they're distributed to an appropriate Maven Repo to ideally get picked up
by Maven Central.

Does Netbeans already have a mechanism for publishing and managing
archetypes? Any reason that NB can't or shouldn't do that?

Regards,

Will Hartung
]


Re: Collaborative Editing with Netbeans

2021-01-26 Thread Sven Reimers
Hi all,

Having had a look at the beginning of the lockdown phase here in germany, I
found that all code collaboration was done using meta xml like message via
jabber - so this should be doable using any jabber server out there...

I got everything compiled and running - but failed at the login code for
the Jabber Server ... dumb me...

Hope this helps

-Sven

On Tue, Jan 26, 2021 at 6:03 PM Will Hartung  wrote:

> On Sat, Jan 23, 2021 at 4:05 PM Eric Bresie  wrote:
>
> >
> > DId it have a "host" functionality (using jabber) to initiate as a
> > makeshift server with invites and joining by clients?
> >
> > The big question is what, if any, central services Kanai provided to
> empower the team aspects.
>
> Even with something like Jabber, out of the box you can't connect peer to
> peer, it needs to be routed through something.
>
> It would not surprise me if the collaborative editing also streamed over
> Jabber to leverage a central server hosted at Kanai.
>
> Now, given that, if there WERE to be some central service necessary, is
> that something that Apache would be comfortable with hosting or is that out
> of scope.
>
> Since they can't host the code, (i.e. assuming you can get your hands on
> the source, Apache can't import it due to licensing), Apache would have
> essentially no involvement at all, so there would be no impetus for Apache
> to host any central infrastructure for such a facility.
>
> But, even if there were an aspect delivered by Apache Netbeans, I don't
> know if hosting something like the Jabber (or whatever) infrastructure is
> something that they would want to do.
>
> Regards,
>
> Will Hartung
>


-- 
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


Re: Collaborative Editing with Netbeans

2021-01-26 Thread Will Hartung
On Sat, Jan 23, 2021 at 4:05 PM Eric Bresie  wrote:

>
> DId it have a "host" functionality (using jabber) to initiate as a
> makeshift server with invites and joining by clients?
>
> The big question is what, if any, central services Kanai provided to
empower the team aspects.

Even with something like Jabber, out of the box you can't connect peer to
peer, it needs to be routed through something.

It would not surprise me if the collaborative editing also streamed over
Jabber to leverage a central server hosted at Kanai.

Now, given that, if there WERE to be some central service necessary, is
that something that Apache would be comfortable with hosting or is that out
of scope.

Since they can't host the code, (i.e. assuming you can get your hands on
the source, Apache can't import it due to licensing), Apache would have
essentially no involvement at all, so there would be no impetus for Apache
to host any central infrastructure for such a facility.

But, even if there were an aspect delivered by Apache Netbeans, I don't
know if hosting something like the Jabber (or whatever) infrastructure is
something that they would want to do.

Regards,

Will Hartung


Re: Travis jobs for my PR not started for few hours

2021-01-26 Thread Neil C Smith
On Tue, 26 Jan 2021 at 16:18, Neil C Smith  wrote:
>
> On Tue, 26 Jan 2021 at 13:58, Christian Oyarzun  wrote:
> > If we still want to use Travis, someone with admin rights on Travis needs
> > to migrate netbeans, netbeans-html4j, and netbeans-jackpot30 from
> > travis-ci.org to travis-ci.com.
>
> I've opened https://issues.apache.org/jira/browse/INFRA-21349

And it's been done already. Infra are awesome! :-)

https://travis-ci.com/github/apache/netbeans

Best wishes,

Neil

-
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: Travis jobs for my PR not started for few hours

2021-01-26 Thread Neil C Smith
On Tue, 26 Jan 2021 at 13:58, Christian Oyarzun  wrote:
> If we still want to use Travis, someone with admin rights on Travis needs
> to migrate netbeans, netbeans-html4j, and netbeans-jackpot30 from
> travis-ci.org to travis-ci.com.

I've opened https://issues.apache.org/jira/browse/INFRA-21349

Best wishes,

Neil

-
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: Travis jobs for my PR not started for few hours

2021-01-26 Thread Christian Oyarzun
> I still have the original problem: e.g. I can't run the Travis jobs for
my PR
> and without all of them passing, I am hesitating to integrate my change:
> https://github.com/apache/netbeans/pull/2707 - how do you guys do it, that
> your Travis checks run?

If we still want to use Travis, someone with admin rights on Travis needs
to migrate netbeans, netbeans-html4j, and netbeans-jackpot30 from
travis-ci.org to travis-ci.com.

https://docs.travis-ci.com/user/migrate/open-source-repository-migration#migrating-a-repository

--Christian



On Tue, Jan 26, 2021 at 4:30 AM Neil C Smith  wrote:

> On Tue, 26 Jan 2021 at 01:47, Jaroslav Tulach 
> wrote:
> > I still have the original problem: e.g. I can't run the Travis jobs for
> my PR
> > and without all of them passing, I am hesitating to integrate my change:
> > https://github.com/apache/netbeans/pull/2707 - how do you guys do it,
> that
> > your Travis checks run?
>
> I guess we don't, right now.  There's quite a queue backlog at the
> moment by the look of it.  I don't see it getting any better.
> Retriggering all or part of Travis jobs, checking logs, etc. is what
> I'd normally be expecting to be doing during release, but it certainly
> doesn't seem like something we'll be doing much of!
>
> > Anyway few thoughts, with respect to switching to GitHub actions:
> >
> > - 1st and foremost, ASF has to have a contract with provider of the CI
> > solution! Unless I am mistaken ASF pays to Travis and as such we can run
> such
> > a huge NetBeans loads on Travis. ASF needs to do the same with GitHub
> before
> > we can fully use Actions.
>
> I'm not sure ASF pays to Travis - if so, the current issues and
> configuration need some looking at!
>
> From the infra@ email linked earlier, the ASF GitHub account is a
> sponsored enterprise level account as far as I know, so it is "paid".
> It doesn't mean that ASF isn't already hitting the limits of what's
> available.
>
> > - preferrably all of them, before the PR is merged. However, we don't
> have to
> > run them with every commit automatically. Simple `ant build` would be
> enough
> > for an automatic "ready to go" check.
>
> +1 to tests green to merge.  Have argued for that multiple times.
> But, we do need to look at what tests are actually reliable.  eg. the
> Java hints tests fail so much, that particularly if we don't have
> ability to re-run them separately they're going to get annoying very
> quickly.
>
> > - btw. shall not we reuse the ASF's own build infrastructure (e.g.
> > `Jenkinsfile`) to run our pipeline tests? In general whoever donates a
> CPU is a
> > friend, right?
>
> In part I don't think there's a difference - both sponsored CPU's.
> But we certainly shouldn't be adding to our use of resources without
> also reviewing everything that's running on
> https://ci-builds.apache.org/job/Netbeans/
>
> Best wishes,
>
> Neil
>
> -
> 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: Travis jobs for my PR not started for few hours

2021-01-26 Thread Neil C Smith
On Tue, 26 Jan 2021 at 01:47, Jaroslav Tulach  wrote:
> I still have the original problem: e.g. I can't run the Travis jobs for my PR
> and without all of them passing, I am hesitating to integrate my change:
> https://github.com/apache/netbeans/pull/2707 - how do you guys do it, that
> your Travis checks run?

I guess we don't, right now.  There's quite a queue backlog at the
moment by the look of it.  I don't see it getting any better.
Retriggering all or part of Travis jobs, checking logs, etc. is what
I'd normally be expecting to be doing during release, but it certainly
doesn't seem like something we'll be doing much of!

> Anyway few thoughts, with respect to switching to GitHub actions:
>
> - 1st and foremost, ASF has to have a contract with provider of the CI
> solution! Unless I am mistaken ASF pays to Travis and as such we can run such
> a huge NetBeans loads on Travis. ASF needs to do the same with GitHub before
> we can fully use Actions.

I'm not sure ASF pays to Travis - if so, the current issues and
configuration need some looking at!

>From the infra@ email linked earlier, the ASF GitHub account is a
sponsored enterprise level account as far as I know, so it is "paid".
It doesn't mean that ASF isn't already hitting the limits of what's
available.

> - preferrably all of them, before the PR is merged. However, we don't have to
> run them with every commit automatically. Simple `ant build` would be enough
> for an automatic "ready to go" check.

+1 to tests green to merge.  Have argued for that multiple times.
But, we do need to look at what tests are actually reliable.  eg. the
Java hints tests fail so much, that particularly if we don't have
ability to re-run them separately they're going to get annoying very
quickly.

> - btw. shall not we reuse the ASF's own build infrastructure (e.g.
> `Jenkinsfile`) to run our pipeline tests? In general whoever donates a CPU is 
> a
> friend, right?

In part I don't think there's a difference - both sponsored CPU's.
But we certainly shouldn't be adding to our use of resources without
also reviewing everything that's running on
https://ci-builds.apache.org/job/Netbeans/

Best wishes,

Neil

-
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