NetBeans core startup order is incorrect

[Peter Hansson]

I know everyone is busy with the transition, but if anyone does have time, I 
would love to get some feedback/brainstorming on 
https://issues.apache.org/jira/browse/NETBEANS-63

Basically, as far as I can tell, the startup order of the core is incorrect: 
tasks can start before the network infrastructure is initialized. This creates 
various spurious problems. I'm guessing that at least some in-explainable bug 
reports over the years may be attributed to this. It is hit and miss if it 
works or not.

This is really core of the Platform and therefore needs a bit of thought before 
jumping to fix. I don't mind working on a patch but the matter really needs 
validation/review/brainstorming so as to find best solution. As always Emilian 
is leading the way with valuable comments.

Please use the JIRA report for comments.

/Peter

Re: Cryptography audit of incubator-netbeans

[Peter Hansson]

Side note (but related):


In case you've missed it: the Oracle JDK people are in the process of removing 
all crypto strength restrictions completely. Apparently not important anymore 
as it was in the past. This change in the Oracle JDK distribution will be 
backported to Java8, Java7 and Java6.
See https://bugs.openjdk.java.net/browse/JDK-8170157



So at least the Oracle lawyers has changed the view on things.  Great for 
developers.




On Wednesday, September 13, 2017 8:54 PM, Geertjan Wielenga 
 wrote:



Hi all, especially mentors,


We've started a cryptography audit, with first results here:


https://lists.apache.org/thread.html/0f257994eb16bcf0ee2ffd7dc63baa9ae0799dac40ca30dab35bff47@%3Cdev.netbeans.apache.org%3E


Questions -- what is the next step?


Thanks,


Gj

Re: 1st code donation is complete

[Peter Hansson]

Well, I have ProxySelector2 which is a working solution but which is a COMPLETE 
replacement of the existing NB ProxySelector2 and fixes a bunch of other 
reported issues too.
(URL: https://bitbucket.org/phansson/netbeansproxy2)

But the question is if there's time for taking that into the NB code base now?  
As a quick workaround I should be able to in 24h to come up with a simple patch 
that can make the existing ProxySelector work without the GPL'ed file. It still 
wont work (as in: it won't do what it is supposed to) but we won't be worse off 
than we are today. And then we'll leave inclusion of ProxySelector2 for post 
NB9 phase, perhaps for NB9.1.


Let me know. 


Peter





On Monday, September 11, 2017 9:43 PM, Geertjan Wielenga 
<geertjan.wiele...@googlemail.com> wrote:



Well, great, if you can solve the problem such that we avoid the licensing 
problem while also having an actually working solution, that would be really 
great. If you have a patch, i.e., one that removes the existing problematic 
solution and replaces it with yours, that would be a way forward, I think, with 
everything referenced in the issue you're referring to (i.e., 
https://issues.apache.org/jira/browse/NETBEANS-4).

Gj


On Mon, Sep 11, 2017 at 9:39 PM, Peter Hansson 
<peterhansson...@yahoo.com.invalid> wrote:


>
>
>The problem you ran into, the missing nsProxyAutoConfig.js file, is touched 
>upoin in https://issues.apache.org/ jira/browse/NETBEANS-4.  As far as I 
>understand the problem with the file is that it is GPL'ed and therefore cannot 
>live in a Apache repo nor can it be distributed with an Apache licensed 
>bundle. Or am I wrong?
>
>
>To fix, Geertjan wrote to me some time ago asking if I would donate my 
>ProxySelector2 project to Apache and of course the answer was yes (emails from 
>me to various parties on 11 Jun 2017).
>
>In any case, I haven't followed the incubator process and haven't heard more 
>about the issue - until today when I stumbled over the messages where people 
>said they couldn't build because of this missing file. I thought I would pitch 
>in with what I know.
>
>If it is ok to include the file from a legal perspective - so the build will 
>work - then I understand that it is a short term way forward to make the build 
>work. But the file in question belongs to a part of NetBeans, the 
>ProxySelector, which doesn't work with Java8 or later (it expects Rhino, not 
>Nashorn) and therefore for all practical matters you might as well include an 
>empty nsProxyAutoConfig.js file just to get going with the build. Anyway, 
>ProxySelector2 project was born out of this deficiency as well as many others 
>that exists with the existing ProxySelector in NB.
>
>
>I'm thrilled with the progress you've made and can't wait till the day when 
>Apache NetBeans is ready to accept contributions.
>
>
>Peter
>
>
>
>
>
>
>
>On Monday, September 11, 2017 8:40 PM, Geertjan Wielenga 
><geertjan.wielenga@googlemail. com> wrote:
>
>
>
>Great, thanks a lot.
>
>Gj
>
>
>On Mon, Sep 11, 2017 at 8:20 PM, Jan Lahoda <lah...@gmail.com> wrote:
>
>> Both done. For building simple "ant" should now suffice.
>>
>> Jan
>>
>> On Mon, Sep 11, 2017 at 6:30 PM, Geertjan Wielenga <
>> geertjan.wielenga@googlemail. com> wrote:
>>
>> > That would be brilliant, thanks very much!
>> >
>> > Gj
>> >
>> > On Mon, Sep 11, 2017 at 6:28 PM, Jan Lahoda <lah...@gmail.com> wrote:
>> >
>> > > Unless someone disagrees (or wants to do that), my plan is to push the
>> > > missing file and change the default cluster config to basic later
>> today.
>> > > After that, building should simply be done by "ant".
>> > >
>> > > Jan
>> > >
>> > > On Mon, Sep 11, 2017 at 6:23 PM, Simon IJskes <si...@ijskes.org>
>> wrote:
>> > >
>> > > > After the 1st run, i followed that instruction and it fixed that
>> > > > particular problem.
>> > > >
>> > > > And i have a succesful build i see:
>> > > >
>> > > > BUILD SUCCESSFUL
>> > > > Total time: 3 minutes 6 seconds
>> > > >
>> > > >
>> > > >
>> > > > On 11-09-17 18:19, Geertjan Wielenga wrote:
>> > > >
>> > > >> I see this problem still when building, of course we have not fixed
>> > this
>> > > >> at
>> > > >> this point. But the fix above does not work for me, so I cannot
>> build.
>> > > >>
>> > > >> Gj
>> > > >>
>> > > >> On Thu, Aug 31, 2017 at 11:07 AM, Jan Lahoda <lah...@gmail.com>
>> > wrote:
>> > > >>
>> > > >> Hi,
>> > > >>>
>> > > >>> I am afraid the compilation is indeed broken, probably some mistake
>> > in
>> > > a
>> > > >>> "last moment" change. For now, I'd suggest to manually create file:
>> > > >>> core.network/external/ binaries-list
>> > > >>>
>> > > >>> with content:
>> > > >>> 22C41D62B7BD70C00603B2CAE75406 414224CF9F nsProxyAutoConfig.js
>> > > >>>
>> > > >>> We need to fix more properly as soon as we can, of course.
>> > > >>>
>> > > >>> Jan
>> > > >>>
>> > > >>
>> > > >
>> > >
>> >
>>
>

Re: 1st code donation is complete

[Peter Hansson]

The problem you ran into, the missing nsProxyAutoConfig.js file, is touched 
upoin in https://issues.apache.org/jira/browse/NETBEANS-4.  As far as I 
understand the problem with the file is that it is GPL'ed and therefore cannot 
live in a Apache repo nor can it be distributed with an Apache licensed bundle. 
Or am I wrong?


To fix, Geertjan wrote to me some time ago asking if I would donate my 
ProxySelector2 project to Apache and of course the answer was yes (emails from 
me to various parties on 11 Jun 2017).

In any case, I haven't followed the incubator process and haven't heard more 
about the issue - until today when I stumbled over the messages where people 
said they couldn't build because of this missing file. I thought I would pitch 
in with what I know.

If it is ok to include the file from a legal perspective - so the build will 
work - then I understand that it is a short term way forward to make the build 
work. But the file in question belongs to a part of NetBeans, the 
ProxySelector, which doesn't work with Java8 or later (it expects Rhino, not 
Nashorn) and therefore for all practical matters you might as well include an 
empty nsProxyAutoConfig.js file just to get going with the build. Anyway, 
ProxySelector2 project was born out of this deficiency as well as many others 
that exists with the existing ProxySelector in NB. 


I'm thrilled with the progress you've made and can't wait till the day when 
Apache NetBeans is ready to accept contributions.


Peter






On Monday, September 11, 2017 8:40 PM, Geertjan Wielenga 
 wrote:



Great, thanks a lot.

Gj


On Mon, Sep 11, 2017 at 8:20 PM, Jan Lahoda  wrote:

> Both done. For building simple "ant" should now suffice.
>
> Jan
>
> On Mon, Sep 11, 2017 at 6:30 PM, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com> wrote:
>
> > That would be brilliant, thanks very much!
> >
> > Gj
> >
> > On Mon, Sep 11, 2017 at 6:28 PM, Jan Lahoda  wrote:
> >
> > > Unless someone disagrees (or wants to do that), my plan is to push the
> > > missing file and change the default cluster config to basic later
> today.
> > > After that, building should simply be done by "ant".
> > >
> > > Jan
> > >
> > > On Mon, Sep 11, 2017 at 6:23 PM, Simon IJskes 
> wrote:
> > >
> > > > After the 1st run, i followed that instruction and it fixed that
> > > > particular problem.
> > > >
> > > > And i have a succesful build i see:
> > > >
> > > > BUILD SUCCESSFUL
> > > > Total time: 3 minutes 6 seconds
> > > >
> > > >
> > > >
> > > > On 11-09-17 18:19, Geertjan Wielenga wrote:
> > > >
> > > >> I see this problem still when building, of course we have not fixed
> > this
> > > >> at
> > > >> this point. But the fix above does not work for me, so I cannot
> build.
> > > >>
> > > >> Gj
> > > >>
> > > >> On Thu, Aug 31, 2017 at 11:07 AM, Jan Lahoda 
> > wrote:
> > > >>
> > > >> Hi,
> > > >>>
> > > >>> I am afraid the compilation is indeed broken, probably some mistake
> > in
> > > a
> > > >>> "last moment" change. For now, I'd suggest to manually create file:
> > > >>> core.network/external/binaries-list
> > > >>>
> > > >>> with content:
> > > >>> 22C41D62B7BD70C00603B2CAE75406414224CF9F nsProxyAutoConfig.js
> > > >>>
> > > >>> We need to fix more properly as soon as we can, of course.
> > > >>>
> > > >>> Jan
> > > >>>
> > > >>
> > > >
> > >
> >
>

Re: Drag and drop install on macOS instead of the current installer package

[Peter Hansson]

>> I don't see a huge problem in using native OS build slaves to get a
>> particular installer. 

I wish my company had that kind of dough. :-)

>> I don't believe there is a crossplatform way to sign
>> Windows EXEs or change Windows EXE icons, etc.
Wouldn't know about signing. I would think so.Changing resources inside an EXE 
(e.g. icons) is perfectlypossible to do from another platform due to the fact 
that thePE format (the official word for Windows executables) is 
fullydocumented and disclosed. There's a lack of tools though.
>> But speaking of DMGs, I believe mkfs.hfsplus is able to make images, so
>> there is code out there, just not pure Java.
Yes, true. That's a Linux-only tool. They reverse engineered the 
DMG format.
Apologies if I side-tracked the discussion. Best of luck with yourproject.
Peter







 

On Friday, April 21, 2017 5:58 PM, Emilian Bold <emilian.b...@gmail.com> 
wrote:
 

 @Peter: perhaps I should have mentioned that I already did a DMG, see
https://nextbeans.com/downloads/retina/ and it's perfectly easy. Indeed, it
helps that I'm working on a Mac and bypassed NBI entirely.

I don't see a huge problem in using native OS build slaves to get a
particular installer. I don't believe there is a crossplatform way to sign
Windows EXEs or change Windows EXE icons, etc.

But speaking of DMGs, I believe mkfs.hfsplus is able to make images, so
there is code out there, just not pure Java.


--emi

On Fri, Apr 21, 2017 at 6:44 PM, Peter Hansson <
peterhansson...@yahoo.com.invalid> wrote:

>
>
> Some additional notes on this.
>
> First of all: NBI doesn't out-of-the-box support bundling a JRE for the OS
> X platform.
> This is dead simple to fix. You can read more about it here:
>
> http://stackoverflow.com/a/30479473/1504556
>
> (don't expect the RFE to be picked up, I believe development in
>
> the NBI area is stalled which is why I'm sooo looking forward to
>
> the Apache setup)
>
> Then to your actual question: Why isn't drag'n & drop installation
> supported ?
>
>
> I think what you refer is a DMG file. Just like anything else concerning
> Apple
> this is completely secret. It is a proprietary format and I guess Apple
> will come
>
> after you if you try to reverse engineer it. I'm pretty sure this is the
> reason
> why NBI isn't able to create a DMG file.
>
> Apple's strategy is clear:  If you want to build a DMG for OS X you better
> buy a copy of our OS. And if you want use our OS then you must
> buy a copy of our hardware. (Apple doesn't allow you virtualize the OS).
>
> As it stands at the moment you'll need to actually be on a Mac OS X to
> create
>
> a DMG file. NBI was cleverly designed to be platform agnostic, meaning you
> can
> build an installer package for Windows on say Linux. So you don't need
> a build farm with each of your target platforms. This is actually what sets
> NBI apart from the competition. But on OS X it means that the clever people
> who designed NBI had to stop at ZIP files and App Bundles.
>
> So, how does netbeans.org manage to create a DMG installer for the
>
> IDE itself?  Because they "cheat". They have an additional proprietary
> process which is executed on some Mac OS X box they must have access to.
> By proprietary I mean it is outside of what NBI is able to do and not
>
> documented. You can probably peak at what they do and then replicate
>
> their process.
>
>
> Peter
>
>
>
>
>
>
>
>
>
>
>
>
> On Wednesday, April 19, 2017 7:55 PM, Emilian Bold <emilian.b...@gmail.com>
> wrote:
>
>
>
> > The one difference I remember from that nb-javac conversation was that
> the JRE / JDK itself can be considered as "platform
> dependencies".  Am I right to assume that still rules out the IDE binaries
> shipping with the JDK, from an Apache perspective at least?
>
> I think there is something more refined here wrt the GPL and Apache.
> nbjavac as a module dependency doesn't seem to me the same as JRE as a
> runtime dependency we could bundle.
>
> Perhaps some mentor or legal can jump in?
>
> The Classpath exception is explicitly written for this situation.
>
> > If so, that might render this thread moot - an installer that can
> download and install the JDK would probably be more user friendly then?
>
> Not to me. I already have the JDK installed and I don't want to type my
> admin password for NetBeans. A drag and drop Mac image would be perfect.
>
> Somebody doing PHP or JavaScript will not have a JDK so
> bundling/installing the JRE there makes sense.
>
> Platform apps might also prefer the drag and drop approach.
>
> --emi
>
> Pe 19 apr. 2017, la 20:21, Neil C Smith <neil

Re: Aw: Status of Apache NetBeans process

[Peter Hansson]

> I think you're on the same page here. PicoCMS is, as I understand it, a
> basic flat-file static site generator. pages would be stored in git or
> svn and built by a buildbot on change.



I'm not sure that wording is correct. PicoCMS requires a PHP enabled server. 

It builds content on-the-fly from .md files. Therefore, there's no buildbot.
PicoCMS will render the .md file into html every time the page is 

requested, afaik.
By default there's no caching going on. Don't think it is really a problem.
Seems to be very fast even so.


Compare to Jekyll which has no webserver at all and works as you describe,
i.e. it needs something external to actually convert from markup language
into html.

Pros and cons, I guess.

/Peter