Re: Plugin Portal: Map Apache NetBeans project roles to pp3 roles

[Michael Bien]

this is awesome!

going to take a look at the PR later to refresh my PHP knowledge :)

-mbien

On 08.01.23 17:59, Matthias Bläsing wrote:

Hi all,

there were now multiple discussion about admin and verifier access to
the plugin portal. To ease this, I have created this PR:

https://github.com/apache/netbeans-tools/pull/60

It will basicly map the two Apache NetBeans project roles to roles in
the plugin portal:

PMC members will automatically gain admin access
Committer members will automatically gain verifier access

It should be remembered, that PMC membership implies committer access,
so all PMC members can automatically act as verifiers.

The members need to login with the Apache OAuth login system and are
then granted the corresponding permissions on the fly.

The option to register separater admin/reviewer permissions is retained
and there is a difference between an automatically mapped verifier and
an explicitly registered verifier: Only the latter will get email
notifications. The automatically mapped reviewers need to access the
list of open verifications via the "Verification requests" menu entry.

I'd like opinions and/or reviews.

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






-
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

updating to 16-u1

[Ernie Rael]

Just updated to the final bits; and wondering about a /backwards seeming 
dependency/. I started with the first check release of 16-u1, so this 
normally wouldn't be seen.


Using plugin manager, uninstall everything with "gradle".  Still had

   org.netbeans.modules.gradle/2 [2.29.1
   Netbeans/netbeans-TLP/netbeans/release160-14-on-20221215]

when starting NetBeans. Uninstalled Groovy and finally 
"...modules.gradle" was uninstalled. *This seems wrong.* Does Groovy 
depend on Gradle?


-ernie

PS. to be complete

Then activated Gradle/Groovy stuff (none of the patch 16-u1 update 
centers were enabled). Guess gradle.java has that last minute fix 
(1223). (More stuff was installed than actually needed since I kept 
trying to uninstall modules.gradle)


Now a boot gives. The curious numbering has been previously addressed.

    org.netbeans.modules.gradle/2 [2.29.1 
Netbeans/netbeans-TLP/netbeans/release160-14-on-20221215]
    org.netbeans.modules.gradle.java [1.20.1.1 
Netbeans/netbeans-TLP/netbeans/release160-16-on-20221223]
    org.netbeans.modules.gradle.test [1.14 
Netbeans/netbeans-TLP/netbeans/release160-11-on-20221119]
    org.netbeans.modules.gradle.spring [1.14 
Netbeans/netbeans-TLP/netbeans/release160-11-on-20221119]
    org.netbeans.modules.gradle.persistence [1.14 
Netbeans/netbeans-TLP/netbeans/release160-11-on-20221119]
    org.netbeans.modules.gradle.editor [1.0 
Netbeans/netbeans-TLP/netbeans/release160-11-on-20221119]
    org.netbeans.modules.gradle.dists [1.6 
Netbeans/netbeans-TLP/netbeans/release160-11-on-20221119]
    org.netbeans.modules.gradle.java.coverage [1.11 
Netbeans/netbeans-TLP/netbeans/release160-11-on-20221119]
    org.netbeans.modules.gradle.kit [1.14 
16-321935444b183aea1c4ff255d8d2ab8d50c60606]
    org.netbeans.modules.gradle.groovy [1.7 
Netbeans/netbeans-TLP/netbeans/release160-11-on-20221119]

Plugin Portal: Map Apache NetBeans project roles to pp3 roles

[Matthias Bläsing]

Hi all,

there were now multiple discussion about admin and verifier access to
the plugin portal. To ease this, I have created this PR:

https://github.com/apache/netbeans-tools/pull/60

It will basicly map the two Apache NetBeans project roles to roles in
the plugin portal:

PMC members will automatically gain admin access
Committer members will automatically gain verifier access

It should be remembered, that PMC membership implies committer access,
so all PMC members can automatically act as verifiers.

The members need to login with the Apache OAuth login system and are
then granted the corresponding permissions on the fly.

The option to register separater admin/reviewer permissions is retained
and there is a difference between an automatically mapped verifier and
an explicitly registered verifier: Only the latter will get email
notifications. The automatically mapped reviewers need to access the
list of open verifications via the "Verification requests" menu entry.

I'd like opinions and/or reviews.

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: [DISCUSSION] Apache NetBeans 16-u1 Finalization Steps

[Eric Bresie]

Kind of OBE by now but maybe this might have helped some (and the links on
the page)
https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+Release+Management

Eric Bresie
ebre...@gmail.com


On Tue, Jan 3, 2023 at 8:13 PM Laszlo Kishalmi 
wrote:

>
> On 1/3/23 02:33, Neil C Smith wrote:
> > Hi Laszlo,
> >
> > On Mon, 2 Jan 2023 at 20:59, Laszlo Kishalmi 
> wrote:
> >> I've started the finalization steps for Apache NetBeans 16-u1 release.
> > Thanks for leading this through, and sorry for being personally
> > incommunicado and not getting around to voting - I would love to claim
> > excessive merriment, but mainly just laid low by a virus. :-\
>
> Get well, that's the important!
>
> I have not felt myself alone in this release, thank you for guiding me
> through! It seems we've evolved quite much, since my days.
>
>
> >> So far:
> >>
> >>- Created a "16-u1" tag in Git
> >>- Moved the 16-u1 folder into the release area in subversion.
> > Sounds good.
> >
> >> Next, I'd do the following:
> >>
> >>- do a subversion copy on ^/release/netbeans/netbeans/16-u1/nbms as
> >> ^/release/netbeans/netbeans/16/nbms/16-u1
> > No need for that.  Just keep everything where it is.  We don't want
> > duplicate binaries in the releases section, and keeping things clearly
> > separated is better (in some ways) for managing.
> >
> >>- Prepare a manually patched updates.xml (the gz as well) on the
> >> NetBeans VM adding the new location of the two patched modules.
> >>- Wait a day for the mirrors to be sync-ed
> > No need for that - no mirrors to sync anymore!  There is instead a
> > download CDN service - dlcdn.a.o
> >
> > If you check the .htaccess file on the VM, you'll notice we no longer
> > link to closer.lua but directly to dlcdn.  The main download pages
> > still use closer.cgi, but you should see the link come up as dlcdn in
> > most cases - eg.
> >
> https://www.apache.org/dyn/closer.cgi/netbeans/netbeans/16/netbeans-16-bin.zip
> >
> > So, to make this easier, please hardcode the links in updates.xml to
> >
> >
> https://dlcdn.apache.org/netbeans/netbeans/16-u1/nbms/extide/org-netbeans-modules-gradle.nbm
> >
> https://dlcdn.apache.org/netbeans/netbeans/16-u1/nbms/java/org-netbeans-modules-gradle-java.nbm
> >
> > Could do with a better system for this, as we'll need to update the
> > links again when we archive.  Perhaps using alternative relative links
> > and .htaccess.  I realise your suggestion to copy under 16/nbms/ might
> > help there, but other downsides to that.
> >
> >>- Activate the patched update.xml on NetBeans VM (Keeping a backup
> >> version)
> > Yes, please keep a backup in place.  Also make sure the owner /
> > permissions ensure it's not served.
> Well, I left the owner as www-data:www-data, the .htaccess takes care
> that only updates.xml* is served.
>
> Created files updates-16.xml and updates-16-u1.xml (and gz and sha512 in
> the same pattern). updates.xml and others have been replaced with
> symlinks pointing to the 16-u1 versions.
>
> It seems to be working, so people will start to receive these updates on
> the next update center check.
>
> I'm sending out announcements soon.
>
> Once again,
>
> Thank you Neil!
>
>
> >
> > And please use [RELEASES] in the email subject - helps anyone doing
> > subject filtering.
> >
> > 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
> >
> >
> >
>
> -
> 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: [DISCUSSION] DevOps Cluster?

[Eric Bresie]

Assume some of these interfaces would also show up under the "Service" area
which currently has


   1. "Databases"
   2. "Web Services:
   3. "Servers"
   4. "Maven Repositories"
   5. "Cloud"
   6. "Hudson Builders"
   7. "Docker"
   8. "Task Repositories:
   9. "JS Test Driver"
   10. "Selenium Server"


Or is the idea here (in addition to a "DevSecOps" cluster in build context)
to have a "DevSecOps" grouping with all of these assorted services being
able to be added here?

Do any of these services in question fall under one of these existing ones
(i.e. maybe under Cloud which when right clicking allows adding an "Amazon
Beanstalk" or "Oracle Cloud" option).

With the "Enterprise" being very "bloated" would it be worth moving those
out into a smaller grouping (i.e. into DevSecOps")?

Eric Bresie
ebre...@gmail.com


On Thu, Jan 5, 2023 at 1:01 PM László Kishalmi 
wrote:

>
> Well,
>
> @Eric Bresie 
> I usually do not enable the Enterprise cluster on my work NetBeans, and
> Java SE + Groovy is only enabled as we have Jenkins in Job DSL. Anyway, I
> think the Enterprise cluster is bloated already.
>
> Yes, there are some things available as LSP, but if I'd just use that I
> could use VS Code as well.
>
> @Eric Barboni 
> Yes, if there were support for Ansible or Puppet, those would belong there.
>
> Yes, the new modules can be put into existing clusters, the question would
> be which one and why.
>
> @Michael Bien 
>
> Well, that wouldn't be the "generic project" idea, rather than some shared
> project infrastructure code between Terraform and Helm, though that
> "generic project" could come out of that.
>
> Also till a point ide cluster is fine, and from a point it might be weird.
> I feel that with docker now. The editor support is fine, Dockerfiles are
> common enough. The other docker integrations however could go somewhere
> else. (Those features not that useful, and probably need some love)
>
>
> Let's step back and ask, what requirements need to be fulfilled to have a
> new cluster.
> Also what things are against creating a new cluster.
>
> On Thu, Jan 5, 2023 at 4:30 AM Eric Bresie  wrote:
>
>> Would any of that fall under the enterprise cluster which has some
>> “cloud” functionality (Amazon. or is that too overloaded) or ide which has
>> some container (docker)?
>>
>> So is a LSP server an option for some of this? There seem to be a few
>> servers available for Terraform
>> https://microsoft.github.io/language-server-protocol/implementors/servers/
>>
>> Get Outlook for iOS
>> 
>> From: Eric Barboni 
>> Sent: Thursday, January 5, 2023 3:52:25 AM
>> To: dev@netbeans.apache.org 
>> Subject: RE: [DISCUSSION] DevOps Cluster?
>>
>> It could be nice.
>>
>> I'm not very aware of the scope but ansible or puppet could belongs to
>> this cluster ? (no intend to do plugin )
>>
>> Best Regards
>> Eric
>>
>> -Message d'origine-
>> De : Michael Bien 
>> Envoyé : jeudi 5 janvier 2023 09:01
>> À : dev@netbeans.apache.org; Laszlo Kishalmi 
>> Objet : Re: [DISCUSSION] DevOps Cluster?
>>
>> sounds awesome,
>>
>> comments inline.
>>
>> On 04.01.23 16:48, Laszlo Kishalmi wrote:
>> > Dear all,
>> >
>> > As many of you know, I'm a DevOps Engineer by trade (whatever that
>> > means). I use NetBeans daily, however beside supporting Text editing,
>> > terminal and favorites to organize my work. Text editing is mostly
>> > Terraform and sometimes YAML.
>> >
>> > One day, I spent good time, when I edited code in a long comment
>> > block, trying to troubleshoot why my changes were not applied. That
>> > would be obvious if I had basic syntax highlight for Terraform.
>> >
>> > I wanted to create a syntax highlight module for Terraform. I checked
>> > the available HCL grammars written in Java, I was not convinced
>> > enough. That lead to ANTLR support in NB16.
>> >
>> > So, I have an ambitious plan creating a set of plugins which actually
>> > would help my work:
>> >
>> >  - Support for Helm Charts: That would mean Helm Charts would open as
>> > NetBeans Projects, main goal would be providing code completion in the
>> > Yaml templates.
>> >
>> >  - Editor Support for Terraform files: syntax highlight, code
>> > templates
>> >
>> >  - Terraform Project Support: Terraform files to be parsed, and
>> > provide code completion on the parsed data.
>> >
>> >  - Go Lang Support: Well, this is not to express my love for GoLang
>> > (as there are none of that), but Terraform resource/datasource
>> > metadata can be extracted from the original source code. I just need a
>> > parser.
>> >
>> > What I have so far:
>> >
>> >  - Initial code for Go. (ANTLR based Lexer/Parser, basic Syntax
>> > Highlight)
>> >
>> >  - Initial code for Terraform (ANTLR based Lexer/Parser, basic Syntax
>> > Highlight, Code Templates)
>> >
>> >  - Some code for Helm project support, that does not provide anything
>> > useful in its current state.
>> >
>> >  - A General DevOps project type, I 

Re: bits.netbeans.org doc search problem

[Eric Bresie]

Am I remembering correctly that the javadocs have to periodically get
regenerated (manually I think) and maybe there are occasionally some
"hiccups" in the process?

Are these sorts of things impacted by the actual javadoc annotations
needing updating on a case by case basis?

Eric Bresie
ebre...@gmail.com


On Thu, Jan 5, 2023 at 7:11 PM Ernie Rael  wrote:

> Under javadoc for ActionRegistration annotation, in the verbose doc for
> lazy, the Presenter.* links work.
>
> -ernie
>
> On 23/01/05 2:29 PM, Ernie Rael wrote:
> > Came across another unexpected "Oracle Transition".
> >
> > 1. Goto PopupAction
> > 2. Click on something under "Nested Class Summary".
> >
> > Can't find Presenter either. Not sure how widespread this nested class
> > issue is.
> >
> > -ernie
> >
> > On 23/01/04 5:25 PM, Ernie Rael wrote:
> >> Clicking on "ContextAwareAction", through following steps ends up at
> >> https://netbeans.apache.org/about/oracle-transition.html
> >>
> >> 1. bits.netbeans.org - click on "Apache NetBeans dev"
> >> 2. search for actionreg - click on "ActionRegistration"
> >> 3. just above the "since 7.26" - click on "context aware action"
> >>it goes to method returning ContextAwareAction
> >> 4. Click on "ContextAwareAction"
> >>is:
> >>
> https://bits.netbeans.org/dev/javadoc/org-openide-util/org/openide/util/ContextAwareAction.html?is-external=true
> >>
> >>sb:
> >>
> https://bits.netbeans.org/dev/javadoc/org-openide-util-ui/org/openide/util/ContextAwareAction.html
> >>
> >>
> >> Observe: end up at transition page.
> >>
> >> Looks like: "org-openide-util" should be "org-openide-util-ui
> >>
> >> I took a look at Actions.java, but IDK...
> >>
> >> -ernie
> >>
> >> I replied, rather than a new message, because the original message
> >> was about the same interface and I can be easily amused.
> >>
> >>
> >> On 22/09/28 5:35 AM, Eric Barboni wrote:
> >>> Nice finding
> >>> Seems that regexp is not parsing the interface
> >>> linehttps://
> github.com/apache/netbeans/blob/b7cabc0cf7417fd494cf3f84cd6169bc4eadb75f/nbbuild/antsrc/org/netbeans/nbbuild/JavadocIndex.java#L115
> >>>
> >>> A typical interface line looks like:
> >>>  >>> title="interface in org.openide"> >>> class="interfaceName">ErrorManager.Annotation
> >>>
> >>> I try to edit the regexp but I did not succed to swallow the span
> >>> element.
> >>>
> >>> Start thinking using jsoup to do the job  (but that's because I'm
> >>> not goot at regexp)
> >>>
> >>> Regards
> >>> Eric
> >>>
> >>> -Message d'origine-
> >>> De : Ernie Rael  Envoyé : samedi 24 septembre
> >>> 2022 19:05
> >>> À :dev@netbeans.apache.org
> >>> Objet : bits.netbeans.org doc search problem
> >>>
> >>> I wanted to take a look at ContextAwareAction. But entering this in
> >>> the search box has no results. Found it in the source, searched for
> >>> imageutil from the same package, clicked AllClasses, found it there.
> >>>
> >>> I think this has been an issue for a long time. Might have to do
> >>> with "Interface".
> >>>
> >>> 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
> >>>
> >>>
> >>>
> >>>
> >>
> >
>
>
> -
> 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/Gradle Netbean Builds [Re: JUnit 5 Generated Tests Warning/Error]

[Eric Bresie]

Thanks for the input guys.

I'm not trying to start a "build system holy war" here, just a general
discussion on the merits...

I acknowledge this is not something that would be done overnight (i.e. long
term project)...

A few thoughts below (EB>)...

Eric Bresie
ebre...@gmail.com

On Sat, Jan 7, 2023 at 2:24 PM Laszlo Kishalmi 
wrote:

>
> On 1/7/23 08:47, Matthias Bläsing wrote:
> > Am Samstag, dem 07.01.2023 um 10:25 -0600 schrieb Eric Bresie:
> >> That is a bigger philosophical/paradigm change here.  Are there any
> >> longer term plans to migrate the Netbeans codebase build from ant to
> >> something other (Maven or Gradle)?
>

EB> I want to say up front and agree with others, that ant has done well in
this context


> > I have to ask: What problem do you try to fix? Sure when the build is
>

EB> The problem is usage of an "older build" system instead of leveraging a
new build system as is common in java ecosystems.

EB> For example, from the original thread

On Sat, Dec 31, 2022 at 11:18 AM Ernie Rael  wrote:

> My solution, considering that ant is essentially deprecated in NetBeans,

was to convert projects to Maven or Gradle.

EB> I know this is probably more in context of "creating new projects" as
opposed to existing projects but still when the trend in usage in the IDE
is to "not use ant" and/or this functionality is deprecated, it seems then
an alternative may be a way forward.

EB> In the same way, why update Netbeans code base to use a newer java
version and not just stick with an older one?  Here I assume it's to adapt
to the changing ecosystem and to accommodate benefits of new features and
not get stagnant.

> converted to another build system the problems will magically go away.
> > Except they don't. Gradle has its own set of WTF elements, the same is
> > true for maven.


EB> I agree as with any system, they all have their quirks and
idiosyncrasies.  Ant does as well.
EB> If migrated to another system then there would be a lot of up front
growing pains to get over
EB> I never said a migration would be doable overnight (i.e. did ask for a
"long term plan"), that was kind of why I suggested a "phased" approach
doing smaller batches.


> Well, I have a long term plan for that (doing a Gradle migration). This
> is not that easy. NetBeans build is an
> incredible peace of art. Replacing that with something else is hard,
> especially in the core platform. I had some wins, being able to compile
> the platform cluster with Gradle, though compiling is just one thing,
> and that's probably on the easier side.
>
> It is still in my mind, I see benefits of that effort.
>
> Though I have to admit, that what we have with Ant is good enough. Until
> someone really put the effort, and proves that it could be done, we
> shall not make a move.
>

EB> Tim converted over a lot of the "contrib" plugins previously so I think
in theory it's possible...but as mentioned it would require a lot of work.
Not sure if maybe he had any netbeans-tools or other mechanisms out there
to help in transition.


> > There are three things missing before changes could be done:
> >
> > - arguments why it is benefical to switch
>
EB> Ant is an older build system with the current java development
ecosystem moving more towards other build systems.
EB> Maven (and Gradle; going forward will reference Maven but can still
include Gradle as well) established a common convention for project
development across java ecosystem
EB> Maven provides built in dependency management capabilities (I know ant
may provide this indirectly with Ivy or the build infrastructure leveraging
the "external/binary-lists"; but these are kind of "patched on" instead of
internal to the build systems)
EB> Maven provides a plugin mechanism that provides a wealth of  useful
code quality, security, test, assembly, and related functionality.
EB> Maven provides the means to monitor dependencies versioning (i.e. can
identify newer versions available, can identify dependencies with security
issues in need of updates, etc.)
EB> Maven, as with Ant, are "Apache" projects so leveraging this is always
a win-win for the Apache organization

> - preparations to counter all possible "what ifs"
>
EB> I'm not 100% sure what these "what ifs" might be but will try and think
of a few
EB>  * What if some of the internal ant logic / targets do not migrate
easily?
EB>  -> I would assume initially some of the "ant - maven" plugins may
allow continued usage of existing ant build configuration and over time the
individual portions can be migrated in phases
EB>  -> In the event of something not fully accounted for, then may also be
able to further expand existing nb maven plugin adding additional goals /
functionality as needed

> - someone who takes up the fight and does the work
>
EB> Yes that is the big hurdle.  My main reason for bringing it up was to
see if anyone has started thinking of this.
EB> Given my limited time (I'm having a hard enough time developing my
python plugin)