Re: java.io.IOException: Cannot connectIssues

2020-10-03 Thread Matthias Bläsing
Hi,

that is the apache git hosting, that is sometimes a bit flaky. Just
rerun the build and the fetch should succeed.

Greetings

Matthias

Am Samstag, den 03.10.2020, 13:01 -0500 schrieb Eric Bresie:
> I just pulled down recent updates, combined some contrib code
> elsewhere and
> tried to do a cluster build and received the following error:
> 
> Anyone have any ideas about this?
> 
> 
> \nbbuild\build.xml:119: java.io.IOException: Cannot connect to
> https://gitbox.apache.org/repos/asf?p=netbeans-jenkins-lib.git;a=blob_plain;f=meta/netbeansrelease.json
> at
> org.netbeans.nbbuild.extlibs.ConfigureProxy.openConnection(ConfigureP
> roxy.java:114)
> at
> org.netbeans.nbbuild.extlibs.ConfigureProxy.execute(ConfigureProxy.ja
> va:60)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(De
> legatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav
> a:99)
> at org.apache.tools.ant.Task.perform(Task.java:350)
> at org.apache.tools.ant.Target.execute(Target.java:449)
> at org.apache.tools.ant.Target.performTasks(Target.java:470)
> at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1388)
> at
> org.apache.tools.ant.Project.executeTarget(Project.java:1361)
> at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExe
> cutor.java:41)
> at
> org.apache.tools.ant.Project.executeTargets(Project.java:1251)
> at org.apache.tools.ant.Main.runBuild(Main.java:834)
> at org.apache.tools.ant.Main.startAnt(Main.java:223)
> at
> org.apache.tools.ant.launch.Launcher.run(Launcher.java:284)
> at
> org.apache.tools.ant.launch.Launcher.main(Launcher.java:101)
> 
> 
> Eric Bresie
> ebre...@gmail.com


-
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: Running NetBeans in a window-editing mode?

2020-10-03 Thread Eirik Bakke
Found it... this mode is invoked by using the "New" wizard and selecting 
"Layout of of Windows" (see 
https://dzone.com/articles/netbeans-71-review-nbplatform ).

-Original Message-
From: Eirik Bakke  
Sent: Saturday, October 3, 2020 2:51 PM
To: dev@netbeans.apache.org
Subject: Running NetBeans in a window-editing mode?

I remember there was some way to run a NetBeans Platform app in a special mode 
that let you customize the window system defaults (placements of property 
sheet, output pane etc.), without manually editing the XML files.

Does anyone remember how to do this?

-- Eirik

-
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





Running NetBeans in a window-editing mode?

2020-10-03 Thread Eirik Bakke
I remember there was some way to run a NetBeans Platform app in a special mode 
that let you customize the window system defaults (placements of property 
sheet, output pane etc.), without manually editing the XML files.

Does anyone remember how to do this?

-- Eirik


Re: Ruby plugin

2020-10-03 Thread John Kostaras
Wondering if there is a list of community plugins that need contribution, I
came across this wiki page

(kudos to Christian). Status of plugins needs to be updated of course.

Official Apache plugins site 

Old NetBeans plugins site  where old plugins
could also be migrated to the latest Apache NetBeans version.

I 'd propose to add some more columns to the wiki page to include columns
from the old plugins site:

   - Category
   - Supported NetBeans versions
   - Last updated
   - Contributors (who is working/wants to work on the plugin)
   - What needs to be done?

This way, the wiki page could be a reference of all plugins under
development and contributors could decide where to contribute as well as
view the overall status.

Kind regards,
John.



On Fri, 2 Oct 2020 at 16:18, Eric Bresie  wrote:

> Not aware of anything but that doesn't mean someone isn't...
>
> There are existing (dated) links for Ruby plugin like:
> http://wiki.netbeans.org/RubySupport
> http://plugins.netbeans.org/plugin/38549
> https://netbeans.org/community/news/show/1507.html
>
> Eric Bresie
> ebre...@gmail.com
>
>
> On Thu, Oct 1, 2020 at 5:03 AM Piotr Hoppe  wrote:
>
> > Hi guys,
> >
> > Is anyone works on the ruby plugin?
> >
> > Piotr
> >
> > -
> > 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
> >
> >
> >
> >
>


java.io.IOException: Cannot connectIssues

2020-10-03 Thread Eric Bresie
I just pulled down recent updates, combined some contrib code elsewhere and
tried to do a cluster build and received the following error:

Anyone have any ideas about this?


\nbbuild\build.xml:119: java.io.IOException: Cannot connect to
https://gitbox.apache.org/repos/asf?p=netbeans-jenkins-lib.git;a=blob_plain;f=meta/netbeansrelease.json
at
org.netbeans.nbbuild.extlibs.ConfigureProxy.openConnection(ConfigureProxy.java:114)
at
org.netbeans.nbbuild.extlibs.ConfigureProxy.execute(ConfigureProxy.java:60)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown
Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
at org.apache.tools.ant.Task.perform(Task.java:350)
at org.apache.tools.ant.Target.execute(Target.java:449)
at org.apache.tools.ant.Target.performTasks(Target.java:470)
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1388)
at org.apache.tools.ant.Project.executeTarget(Project.java:1361)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.Main.runBuild(Main.java:834)
at org.apache.tools.ant.Main.startAnt(Main.java:223)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:284)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:101)


Eric Bresie
ebre...@gmail.com


Re: [DISCUSS] future of master freeze?

2020-10-03 Thread Neil C Smith
On Sat, 3 Oct 2020 at 16:44, Laszlo Kishalmi  wrote:
> So it has not died in my mind, but it is the time to bring up what's on
> my mind.

Thanks!  Generally seems a good plan from my point of view - few
comments below.  No secret I probably prefer keeping master as the
release branch, but not going to -1 this in the Lazy Consensus thread
when you're ready for that.  The existing schedule and amendments to
it have been done that way, so do think we need to continue with that
process though.

> - create branches: release and release122 from master

I hadn't considered this option, and the regular merges from release
to master.  This way of handling fixes does address most of my
concerns about ensuring fixes are always included in master branch /
following release, as well as potential duplication of a lot of PR
effort.

Minor thought - double check any regexes in the build to match release
branches doesn't mind that branch name.  May be safer to use something
other than release.

> - Merge the version bump PR to master
> - Merge the branch-version bump PR to release122
...
> Also I'm not sure if the version bump at the beginning of
> the release mode is a good place.

Version bump for 12.2 is already done.  It's the final commit in
master before freeze ends in the current process.

I would suggest version bump just on master after creation of release
branches, assuming that doesn't add issues to merging fixes.
Otherwise, keep until after release?  Either way, needs to only happen
on master.

Same consideration to when sig test files get updated? ...

> - release branch, if there is a fix wished to be seen in 12.2 put a PR
> against the release branch, if possible no-API changes please

Also see comments from Jaroslav from
https://github.com/apache/netbeans/pull/2338#issuecomment-686633315

We should probably generate either the sig tests or the PR for them at
branch point for merge to all branches.  That way API changes can get
proper review before release, and API problems (although not
additions?) in fixes could be highlighted.

> - PR-s to the release branch shall be at least marked with the 12.2
> milestone and request a review from the RM

So all fixes need a base branch of release during each release cycle?
But only one PR, one JIRA ticket, etc. because they'll be synced to
master (by you)?

Possibly need to document that well.  Although easy enough to change
in the PR UI, probably better to make sure the author has written and
tested against the right branch first.

> It's a pretty tight plan, please fill-in what I've missed, argue,
> correct, etc.

Best laid plans of mice  :-) *  Yes, seems tight, but a reasonable
evolution of what we've done to date.  All really comes down to how
timely fixes are - August was not the best month for releasing in that
regard.  Good that nb-javac looks about ready for integration prior to
freeze too - been a common delayer.

* https://youtu.be/J_7SWUK7gd0

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: [DISCUSS] future of master freeze?

2020-10-03 Thread Laszlo Kishalmi

Thank you Neil!

So it has not died in my mind, but it is the time to bring up what's on 
my mind.


So please all read through the following plan for 12.2:

15th October:
- create branches: release and release122 from master
- Merge the version bump PR to master
- Merge the branch-version bump PR to release122
- Create and publish 12.2-beta1 using Jenkins as usual

22th October:

- Merge release branch to master
- Merge release branch to release122
- Publish 12.2-beta2

29th October:

- Merge release branch to master
- Merge release branch to release122
- Publish 12.2-beta3

5th November:

- Merge release branch to master
- Merge release branch to release122
- Publish 12.2-rc1 for voting
- Start the Voting process
- Hopefully creation of the 12.2 webpages start at least now.

10th November

- Remove the release branch
- Start the vote on binaries

15th of November:

- Send out release announcement.


As long as the release branch lives, the following rule applies:

- master branch go as is, new features fixes, can go in the usual manner
- release branch, if there is a fix wished to be seen in 12.2 put a PR 
against the release branch, if possible no-API changes please
- PR-s to the release branch shall be at least marked with the 12.2 
milestone and request a review from the RM



It's a pretty tight plan, please fill-in what I've missed, argue, 
correct, etc. Also I'm not sure if the version bump at the beginning of 
the release mode is a good place.


On 10/2/20 4:50 AM, Neil C Smith wrote:

On Thu, 10 Sep 2020 at 06:53, Laszlo Kishalmi  wrote:

Still it is hard to start work on features/fixes that depend on each other.

Agreed.  One way or another we need to have the same fixes in two
branches so that development and release can progress - either
master+release or master+next.

I've been a bit busy catching up with other things since 12.1 release,
but I noticed this conversation died off.  As it stands, we'll have a
master freeze in two weeks for 12.2!  I assume we'd like to find a way
to keep code integration / development happening this time though?  I
think we need one or other approach properly documented and put
through a lazy consensus thread so everyone's on board, everyone knows
how it will work (eg. how issue fixes will be managed / kept in sync),
and any infrastructure changes required are considered prior to freeze
date.

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





Git Performances within Netbeans

2020-10-03 Thread Eric Bresie
Hey folks, while trying to clone a project within Netbeans it seemed to
take a pretty long time.  So on a whim, I started a git bash session and
did the same clone at the same time and the second attempt completed before
the first attempt running in Netbeans was even (so it claims) 60% done).

I thought I recall there being some work to updated the interns with newer
git version internally, but not sure if that was completed or made it in to
12.1 yet (which is what I'm running with by the way).

Any ideas?

Eric Bresie
ebre...@gmail.com


Re: Re: Re: Python donation status

2020-10-03 Thread Eric Bresie
Okay so digging through other emails on the subject I find a lot of the old
code including python code in the Mercurial / hg repository as mentioned
previously here [1] as well as Tim's Maven-ized version here [2]

So the question is, to get "python" brought in is this as simple as
(1) make a python branch,
(2) merge in the "mavenized" code where applicable
(3) make sure compiles
(4) make sure unit tests work
(5) If not already done, assume may need some tweaks (i.e. maybe IP,
headers, change over to any "apache" applicable, etc?)
(6) raise a PR for inclusion

[1] https://hg.netbeans.org/main/contrib/file
[2] https://github.com/timboudreau/netbeans-contrib

Eric Bresie
ebre...@gmail.com


On Fri, Oct 2, 2020 at 12:00 PM Eric Bresie  wrote:

> Is anyone working on python?  If not, what needs to be done to start the
> ball rolling?  Is it still pending Oracle vetting for the donation?
>
> Eric Bresie
> ebre...@gmail.com
>
>
> On Thu, Sep 17, 2020 at 8:00 AM Eric Bresie  wrote:
>
>>
>>Hopefully there isn’t a newer thread on this but was looking through
>>old emails.
>>
>>
>>
>>
>>
>>Assume this is related to
>>
>>
>>
>>
>>
>>NETBEANS-4538 Please support Python.
>>
>>
>> Is the contribution in question the same as associated with the
>> nbpython.org project?  On that site it seems to indicate it’s dual
>> licenses.
>>
>> I looked at the nbpython.org site which seems to be slightly broken
>> (i.e. forum and contribute areas fail to load).  There has been no activity
>> it appears since around 2015 if I’m reading it correctly.
>>
>> Are the contributions available on the hg site?  Looking there at
>> hg.netbans.org I don’t see anything so not sure where else to look.
>>
>>
>> On Sun, Apr 19, 2020 at 1:05 AM Julio César Rocha 
>> wrote:
>>
>>> What needs to be done by us individually?
>>>
>>> I contributed a bit of build logic about 6 years ago.
>>>
>>> Whichever commits are attributed to me, I'd obviously donate.
>>>
>>> I had also signed the OCA before.
>>>
>>>
>>>
>>> On 2020/04/13 05:13:17 Lou Dasaro wrote:
>>>
>>> > Everyone on my team was required to sign the OCA before committing
>>> code was allowed.
>>>
>>> > I'm sure we could sign something else if need be.
>>>
>>> > Most of the code was written by Sun employees who are long gone.
>>>
>>> > I am not able to work on the project, except for consults like this.
>>>
>>> >
>>>
>>> > Regards,
>>>
>>> >
>>>
>>> > On 2020/04/10 13:31:45 Matthias Bläsing wrote:
>>>
>>> > > Hi,
>>>
>>> > >
>>>
>>> > > Am Donnerstag, den 09.04.2020, 11:39 +0200 schrieb Geertjan Wielenga:
>>>
>>> > > > The argument could be made that since the code was part of contrib
>>> under
>>>
>>> > > > the OCA (Oracle Contributor Agreement), it belongs to Oracle and
>>> Oracle can
>>>
>>> > > > simply donate it.
>>>
>>> > >
>>>
>>> > > yes - and assuming, that correct procedure was followed all
>>>
>>> > > contributions to netbeans had to be covered by an OCA. (for all this
>>>
>>> > > IANAL applies)
>>>
>>> > >
>>>
>>> > > Oracle puts itself into a position of massive power when requiring
>>> the
>>>
>>> > > OCA (applies to all projects using CLAs). Oracle is the only entity,
>>>
>>> > > that can for example take the OpenJDK Code, slab their "Oracle JDK"
>>>
>>> > > label on and sell it with a license, that is incompatible with the
>>>
>>> > > GPLv2-CPE. This is only possible, because every contriutor has to
>>> sign
>>>
>>> > > the OCA and thus gives Oracle a full license.
>>>
>>> > >
>>>
>>> > > I quote from the OCA:
>>>
>>> > >
>>>
>>> > > You agree that each of us can do all things in relation to your
>>>
>>> > > contribution as if each of us were the sole owners, and if one of us
>>>
>>> > > makes a derivative work of your contribution, the one who makes the
>>>
>>> > > derivative work (or has it made) will be the sole owner of that
>>>
>>> > > derivative work.
>>>
>>> > >
>>>
>>> > > So yes Oracle has "owner equal" rights to the code (and demonstrates,
>>>
>>> > > that they excercise that right (see OpenJDK)). In any case,
>>>
>>> > > contributions also applied to the NetBeans core, so if Oracle now
>>> wants
>>>
>>> > > to pull the "OCA is a problem" card, the ball was already dropped.
>>>
>>> > > Noone forced Oracle to use an OCA, that was and is a deliberate
>>> choice.
>>>
>>> > >
>>>
>>> > >
>>>
>>> > > So I'll reverse the question: How should it work, that all individual
>>>
>>> > > contributors validate, that they own the code and how shall we
>>>
>>> > > (NetBeans PMC) validate that? In this case relying on OCA and proper
>>>
>>> > > procedure of contribution in the past are invaluable.
>>>
>>> > >
>>>
>>> > >
>>>
>>> > > Greetings
>>>
>>> > >
>>>
>>> > > Matthias
>>>
>>> > >
>>>
>>> > >
>>>
>>> > > -
>>>
>>> > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
>>>
>>> > > For additional commands, e-mail: dev-h...@netbeans.apache.org
>>>
>>> > >
>>>
>>> > > For further information abo