Re: Maven bits for Apache NetBeans (incubating) 11.0

[Jaroslav Tulach]

Dne pátek 5. dubna 2019 16:57:58 CEST, Eric Barboni napsal(a):
> Thanks a lot for the release!!!
> 
> And ... maven artefacts are staging at
> https://repository.apache.org/content/repositories/orgapachenetbeans-1013
> for people wanting them.

Great. I confirm that Apache NetBeans HTML/Java API builds with the bits:
https://github.com/apache/incubator-netbeans-html4j/compare/
master...jtulach:UsingNetBeans110

Thanks Eric.
-jt

PS: I am looking forward to the removal of "" specification

> -Message d'origine-
> De : Antonio 
> Envoyé : jeudi 4 avril 2019 22:39
> À : dev@netbeans.incubator.apache.org
> Objet : Re: [ANNOUNCE] Apache NetBeans (incubating) 11.0 released
> 
> Should be ready.
> 
> There was a problem pushing to asf-site so I triggered another build.
> 
> Cheers,
> Antonio
> 
> El 04/04/2019 a las 22:23, Laszlo Kishalmi escribió:
> > Well, I do not know how long the site would take to be updated
> > (hopefully soon).
> > This announcement is just sent to this dev list first. When the site
> > is up with the 11.0 changes, I'm going to post similar announcements
> > to the general incubator and the other announcement lists.
> > 
> > On 4/4/19 1:16 PM, Laszlo Kishalmi wrote:
> >> The Apache NetBeans team is proud to announce the release of Apache
> >> NetBeans (incubating) 11.0.
> >> 
> >> Apache NetBeans (incubating) 11.0 constitutes all cluster in the
> >> Apache NetBeans Git repo, which together provide the NetBeans
> >> Platform (i.e., the underlying application framework), as well as all
> >> the modules that provide the Java SE, Java EE, PHP, JavaScript and
> >> Groovy features of Apache NetBeans.
> >> 
> >> In short, Apache NetBeans (incubating) 11.0 is a full IDE for Java
> >> SE, Java EE, PHP and JavaScript development with some Groovy language
> >> support.
> >> 
> >> Read more on our download page:
> >> 
> >> https://netbeans.apache.org/download/nb110/nb110.html
> >> 
> >> New & Noteworthy features of the 11.0 Release:
> >> 
> >> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+
> >> 11.0+New+and+Noteworthy
> >> 
> >> 
> >> See the below for the donation status of features that have not been
> >> donated or included in Apache builds yet, i.e., are not part of
> >> Apache NetBeans (incubating) 11.0, e.g., features for working with
> >> C/C++, JavaCard, and more:
> >> 
> >> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+Transitio
> >> n
> >> 
> >> Work is being done on bringing netbeans.org to Apache. In the
> >> meantime, refer to the below for all details related to Apache
> >> NetBeans:
> >> 
> >> https://cwiki.apache.org/confluence/display/NETBEANS
> >> 
> >> Laszlo Kishalmi
> >> on behalf of Apache NetBeans PPMC
> >> 
> >> 
> >> Apache NetBeans is an effort undergoing incubation at The Apache
> >> Software Foundation (ASF), sponsored by the Apache Incubator.
> >> Incubation is required of all newly accepted projects until a further
> >> review indicates that the infrastructure, communications, and
> >> decision making process have stabilized in a manner consistent with
> >> other successful ASF projects. While incubation status is not
> >> necessarily a reflection of the completeness or stability of the
> >> code, it does indicate that the project has yet to be fully endorsed by
> >> the ASF.
> >> 
> >> 
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> >> For additional commands, e-mail:
> >> dev-h...@netbeans.incubator.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.incubator.apache.org
> > For additional commands, e-mail:
> > dev-h...@netbeans.incubator.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.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: 

Re: [MENTORS] Apache NetBeans maven artifacts groupId and process

[Jaroslav Tulach]

Great! I have successfully used both repositories (1012 and 1013) to build my 
projects.
-jt

Dne pátek 5. dubna 2019 19:09:48 CEST, Eric Barboni napsal(a):
> Hi,
> 
>  I would notify  that we have now Apache NetBeans (incubating) 11 maven
> artefacts
> https://repository.apache.org/content/repositories/orgapachenetbeans-1013
> 
>  and the 10 version here
>  https://repository.apache.org/content/repositories/orgapachenetbeans-1012
> 
> they are respectively build by Jenkins at apache according to the respective
> tag that was voted +1.
> 
> I removed the former repository with org.apache.netbeans groupid
> 
> Regards
> Eric
> 
> -Message d'origine-
> De : Jaroslav Tulach 
> Envoyé : vendredi 29 mars 2019 10:26
> À : Apache NetBeans 
> Objet : Re: [MENTORS] Apache NetBeans maven artifacts groupId and process
> 
> Ate wrote:
> > Hi Mark,
> > Thanks a ton for the detailed reply, which makes a lot of sense to me.
> > 
> > Given that, I see no strong argument or reason to further hold up the
> 
> (re)quest to keep using org.netbeans for Maven GroupId.
> 
> > Assuming of course all the technical and administrative hurdles with
> 
> Nexus and Sonatype can and will be dealt with appropriately.
> 
> > So +1 on this from me.
> 
> Thank you Ate and Mark for looking at the Apache NetBeans groupId issue so
> through-fully. Thanks Ate, for giving us a go to proceed.
> Eric Barboni  wrote:
> > I would like to know how to present or handle the vote for a this
> > staged items
> 
> I personally suggest to hold the vote few weeks to not conflict with the
> current vote about NetBeans 11 release, but...
> > The content is on apache nexus like that
> > https://repository.apache.org/content/repositories/orgapachenetbeans-1
> > 012 the build is based on source from a git tag equals to the voted
> > Apache NetBeans (incubating) 10 and I sign the artefacts with my key.
> > Is this enough for a vote ? (nothing more on  dist.apache.org as
> > source zip already done, not sha512 as nexus not support it)
> 
> ...count with my +1 for the
> https://repository.apache.org/content/repositories/orgapachenetbeans-1012
> repository anytime you call the vote!
> -jt
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Sharing user dir but not cache dir was: NetBeans UserDir vs. Releases

[Jaroslav Tulach]

Dne čtvrtek 4. dubna 2019 14:17:57 CEST, Junichi Yamamoto napsal(a):
> The user directory includes plugins. The cache directory has a splash
> screen. So, probably, problems occur if a user uses NetBeans IDEs of
> different versions, I suppose.

## Problem with Caches

Right. Using two different versions of NetBeans on top of the same cache 
directory will effectively disable the caches (or worse, break their 
behavior).

## Backward Compatibility

Reusing user directory in newer version directly was always my dream, but we 
never got it working properly - hence the QA required the "import of previous 
version" behavior to import only what is explicitly requested and tested.

Sharing the user directory is technically possible. Future versions of the 
code just have to be able to read older settings. That is achievable if good 
coding practices are obeyed. 

## Future Compatibility

However using the same directory by older versions is even more tricky. That 
requires proper versioning and/or extensible settings format and not many 
developers really think about that. Consider reading more in my [notes about 
protocols](http://wiki.apidesign.org/wiki/Protocols) and related articles.

## Non Fixable Bug Reports

The problem with sharing the user directory is that we will get bug reports 
that aren't reproducible without the actual user directory. E.g. there'll be 
bugs nobody will be able to fix. We have been in such situation in the past - 
when the upgrade was automatic, a lot of debris got into the new version and 
the new code was not really to deal with it.

## Conclusion

If you want to share the user dir, you can. It will work to some extent. 

In any case, don't share the cache directory between different versions. 
Luckily there is a way to place caches elsewhere than under the user 
directory...

Best regards and good luck.
-jt




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Maven repository is down

[Jaroslav Tulach]

Hi.
My build
https://builds.apache.org/job/incubator-netbeans-html4j-linux/71/console

Failed to collect dependencies at
org.netbeans.api:org-openide-util-lookup:jar:RELEASE82:
Failed to read artifact descriptor for
org.netbeans.api:org-openide-util-lookup:jar:RELEASE82:
Could not transfer artifact
org.netbeans.api:org-openide-util-lookup:pom:RELEASE82 from/to
netbeans (http://bits.netbeans.org/maven2/): Failed to transfer
file:
http://bits.netbeans.org/maven2/org/netbeans/api/org-openide-util-lookup/RELEASE82/org-openide-util-lookup-RELEASE82.pom.

Return code is: 502 , ReasonPhrase:Bad Gateway. -> [Help 1]

Looks like the Maven repository is down. Can we fix that? Many people rely
on that repository to be available, for example:
https://twitter.com/JaroslavTulach/status/1113313978258796544

-jt

Re: [MENTORS] Apache NetBeans maven artifacts groupId and process

[Jaroslav Tulach]

Ate wrote:
> Hi Mark,
> Thanks a ton for the detailed reply, which makes a lot of sense to me.
>
> Given that, I see no strong argument or reason to further hold up the
(re)quest to keep using org.netbeans for Maven GroupId.
> Assuming of course all the technical and administrative hurdles with
Nexus and Sonatype can and will be dealt with appropriately.
> So +1 on this from me.

Thank you Ate and Mark for looking at the Apache NetBeans groupId issue so
through-fully. Thanks Ate, for giving us a go to proceed.

Eric Barboni  wrote:

> I would like to know how to present or handle the vote for a this staged
> items
>

I personally suggest to hold the vote few weeks to not conflict with the
current vote about NetBeans 11 release, but...


> The content is on apache nexus like that
> https://repository.apache.org/content/repositories/orgapachenetbeans-1012
> the build is based on source from a git tag equals to the voted Apache
> NetBeans (incubating) 10 and I sign the artefacts with my key. Is this
> enough for a vote ? (nothing more on  dist.apache.org as source zip
> already done, not sha512 as nexus not support it)
>

...count with my +1 for the
https://repository.apache.org/content/repositories/orgapachenetbeans-1012
repository anytime you call the vote!
-jt

Re: [MENTORS] Apache NetBeans maven artifacts groupId and process

[Jaroslav Tulach]

Thanks Ate. It is great to hear that using org.netbeans.* groupId is
legally OK and that it is not against any Apache policy.

[APIs are like stars](http://wiki.apidesign.org/wiki/Star) - they are with
us "forever" (or at least until their users/observers are alive). It is the
goal of the maintainers to make sure the APIs evolve well. Code changes
driven by marketing/branding purposes are the most harmful and useless
changes to any API. Nobody wants to repeat the com.sun.swing -> javax.swing
rename disaster.

It is important, especially right now, to make the migration of NetBeans
Platform 8.2 to Apache NetBeans Platform as smooth as possible. We don't
want people to ask questions like: "Should I upgrade or should I rather
stay with pre-Apache version?" Keeping the artifact co-ordinates is
essential part of making the migration of Maven based projects on top of
NetBeans Platform "no brainer".

Many Apache projects are [kept in historical co-ordinates](
https://repository.apache.org/content/groups/public/) - freemarker, log4j,
etc. It is not fair to not allow NetBeans to do the same. Especially when
backward compatibility has always been a major focus of everything we did
in the NetBeans Platform.

Dear mentors, please guide me on my quest to keep the Maven co-ordinates
unchanged. Thanks you.
Jaroslav Tulach
NetBeans Founder
NetBeans Platform Architect

po 25. 3. 2019 v 0:57 odesílatel Ate Douma  napsal:

>
>
> On 19/03/2019 18.34, Eric Barboni wrote:
> > Hi,
> >
> >Prior to any process for voting/releasing the Apache Netbeans maven
> > artefacts  would be sure on one point. We may use groupId
> > org.apache.netbeans or org.netbeans as we have the grant to do so.
> >
> >   It would be easier and more backward compatible to use org.netbeans as
> > groupId for Apache NetBeans artefacts. Can we use that groupId forever
> even
> > if we became a TLP. Or was it only for transitioning purpose.
>
> I think you must ask this on tradema...@apache.org.
>
> The Apache Branding Policy says [1] that podlings may request to keep
> non apache domain names (e.g. netbeans.org) for *limited uses* once the
> podling graduates to TLP.
>
> That primarily concerns website and domain usages, but the Policy isn't
> really clear/explicit in how far the "limited uses" is, or may be
> extended to 'forever' usage when such a domain has been transferred to
> the ASF. My gut feeling is: only in exceptional cases, as explained at
> [1] for openoffice.org and groovy-lang.org.
>
> In how far this extends (or not) to the usage of non apache Maven
> GroupId, temporarily or 'forever', is really not addressed nor answered
> there, nor anywhere else I searched for it.
> Legally, I think it should be fine, because netbeans.org has been
> transferred to the ASF. But it might still not be desired or allowed
> from ASF (branding) Policy POV.
> So again, I advise to explicitly ask this to be answered and agreed upon
> first by the Apache Trademark (and Branding) Committee.
>
> Possibly other mentors may have more experience/knowledge in this area
> how other podlings dealt with this, and can chime in as well?
>
> Note: I understand the wish to retain the usage of org.netbeans as Maven
> GroupId for backwards compatibility. But even if this will be allowed,
> is it really needed to stick to using it 'forever'?
> If not yet now, IMO it is advisable to at least discuss and plan to
> migrate and transition to using org.apache.netbeans for future
> Maven artifacts / NetBeans releases.
> If not, do you want to use org.netbeans also for new Maven artifacts?
> Otherwise you'll end up with an even more 'messy' Maven/Nexus artifact
> management, using 2 different (base) GroupIds...
>
>
> [1] https://www.apache.org/foundation/marks/pmcs#nonapache
>
> >
> >
> >
> >
> >
> >One second question is concerning process to vote/release the
> artefacts.
> > The artefacts are built using the same tag as the official release of
> Apache
> > NetBeans (incubating)   for example for version 10 its tag is 10.0-vc5.
> >
> >   The only element to vote on would be a staged repository with a bunch
> of
> > artefacts at
> > (
> https://repository.apache.org/content/repositories/orgapachenetbeans-1011/
> )
> > as the source are already released (signed by two different people).
> >
> >Will that work the Apache way ? How to make it comply.
> >
> >
> >
> > Best Regards
> >
> > Eric
> >
> >
> >
> > PS:
> >
> >   (The donated mavenutilities plugins will be at org.apache.netbeans
> because
> > they are new artefacts as the previous release netbeans-parent)
> >
> >
> >
> >
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Where are the sources for the NetBeans Platform? Release Apache Netbeans 11.0 (incubating) [vote candidate 4]

[Jaroslav Tulach]

Laszlo,
I don't see sources for just the NetBeans Platform at
https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-11.0-vc4/

Having src.zip with just NetBeans Platform sources would greatly help
downstream packagers like Debian. The Debian source for
netbeans-platform.deb package could be <40MB, while now it needs to contain
the whole source code.
-jt

čt 21. 3. 2019 v 8:41 odesílatel Laszlo Kishalmi 
napsal:

> Dear all,
>
> This is our 4th voting candidate for the 11.0 release of Apache NetBeans.
> This time everything went through my smoke tests, so let's vote on it.
>
> Apache NetBeans 11.0 (incubating) constitutes all clusters in the Apache
> NetBeans Git repo, which together provide the NetBeans Platform (i.e., the
> underlying application framework), as well as all the modules that provide
> the Java SE, Java EE, PHP, JavaScript and Groovy features of Apache
> NetBeans.
>
> In short, Apache NetBeans 11.0 (incubating) is a full IDE for Java SE,
> Java EE, PHP and JavaScript development with some Groovy language support.
>
> Build artifacts available here:
>
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-11.0-vc4/
>
> Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and
> NOTICE files, as well as a README file with build instructions, which are
> the same as these:
>
> https://github.com/apache/incubator-netbeans/blob/release110/README.md
>
> We are voting on:
>
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-11.0-vc4/incubating-netbeans-11.0-vc4-source.zip
>
> SHA512:
> e1ffe7873142bf6718f4365480501bec81126dc8e90884ea74f0cbc5d86a034ae3182515c4b78ccb250786bf84774d600f0b9451a6c518f773ca611cf82e4197
> ./incubating-netbeans-11.0-vc4-source.zip
>
> KEYS file:
>
> https://dist.apache.org/repos/dist/release/incubator/netbeans/KEYS
>
> Apache NetBeans Git Repo tag: 11.0-vc4 :
> https://github.com/apache/incubator-netbeans/tree/11.0-vc4
>
> Note: NetBeans license violation checks are managed via the
> rat-exclusions.txt file:
>
>
> https://github.com/apache/incubator-netbeans/blob/release110/nbbuild/rat-exclusions.txt
>
> Rat report shows no unknown licenses, except for license files:
>
>
> https://builds.apache.org/job/incubator-netbeans-release/404/artifact/rat-release-temp/nbbuild/build/rat-report.txt
>
> Included as a convenience binary, not relevant for the voting purposes
> (unzip it, run it and you'll see Apache NetBeans):
>
>
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-11.0-vc4/incubating-netbeans-11.0-vc4-bin.zip
>
> SHA512:
> 9d7fbe5c6bcf781fc1d3f8e2aee62db0435dd716c60dc73ef900ee2817473cc5b0a8e12c1453b7e57aedcece70cff778673a8cf563c1fa4eea816d9636955d4b
> ./incubating-netbeans-11.0-vc4-bin.zip
>
> Release specific wiki page:
>
> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+11.0
>
> How (and what) to try out the release:
>
> 1. Download the artifact to be voted on and unzip it.
> 2. Check that the artifact does not contain any jar files,
> save the:
> platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/empty.jar
> and
> enterprise/glassfish.common/test/unit/data/nottaDir-4_1_2.jar and
> enterprise/glassfish.common/test/unit/data/subdir/nottaDir-5.0.jar which
> are only jars by their name
> 3. Verify the cryptographic signatures, the NOTICE and LICENSE file
> 4. Build it using the README provided by the artifact.
> 5. Look in nbbuild/netbeans for the NetBeans installation created by the
> build process.
>
>
> This vote is going to be open at least 72 hours, vote with +1, 0, and -1
> as usual. This vote round would determine if we carry on this release to
> the next IPMC vote . Binding votes are going to be carried over.
>
> Thank you for the hard work!
>
> Laszlo Kishalmi
> Volunteer Release Manager of Apache NetBeans 11.0
>
>

Re: Apache NetBeans (incubating) 10 maven artefacts

[Jaroslav Tulach]

Amazing work, Eric!
I've just changed my project to use Lexer from your RELEASE100 artifacts:

https://github.com/JaroslavTulach/SelfGraal/commit/e247277f7c4cb592060b174f544254381f0c372d

and everything works like a charm! Having these artifacts in the Maven
central repository would be a tremendous step for the NetBeans project:

- new projects could use these bits easily - lexer and/or lookup or
filesystems would be available in the central
- old projects could make the switch just by changing to RELEASE100 and
removing special repository section

I am ready to +1 on the
https://repository.apache.org/content/repositories/orgapachenetbeans-1012/
bits. Thanks.
-jt


čt 21. 3. 2019 v 19:10 odesílatel Eric Barboni  napsal:

> Hi
>  I have populated a staged repostory with org.netbeans as prefix groupID
>
>  https://repository.apache.org/content/repositories/orgapachenetbeans-1012
>
>  I hope this is more backward compatible.
>
>  Any test welcome
>
> Regards
> Eric
>
> On 2019/03/19 09:19:07, "Eric Barboni"  wrote:
> > Hi Patrik>
> >
> > New  harness is not uses yet. The 8.2 is used for now>
> >
> >  >
> >
> > Regards>
> >
> > Eric>
> >
> >  >
> >
> > On 2019/03/16 17:44:54, Patrik Karlström < >
> > mailto:p...@trixon.se> wrote: >
> >
> > > Thanks, I'm now able to run Mapton based on NetBeans 10 for the first>
> > time.> >
> >
> > > >
> >
> > > I did notice the error and skipped as per your instructions.> >
> >
> > > Private classes referenced in module:> >
> >
> > > [org.netbeans.modules.options.OptionsWindowAction]> >
> >
> > > Project depends on packages not accessible at runtime in module> >
> >
> > >
> org.apache.netbeans.api:org-netbeans-modules-options-api:jar:RELEASE100>
> >
> >
> > > As far as I can see it's all looking good when running the options>
> > dialog.> >
> >
> > > >
> >
> > > 'clean install' failed on the harness, is it really needed?> >
> >
> > > >
> >
> > > mvn clean install> >
> >
> > > [INFO] Scanning for projects...> >
> >
> > > [INFO]> >
> >
> > > [INFO] --< org.apache.netbeans.utilities:nbm-maven-harness> >
> >
> > > >---> >
> >
> > > [INFO] Building Apache NetBeans Maven Utilities - NBM Harness for
> Maven>
> >
> >
> > > 9.0-SNAPSHOT> >
> >
> > > [INFO] [ jar> >
> >
> > > ]-> >
> >
> > > [INFO]> >
> >
> > > [INFO] --- maven-clean-plugin:3.1.0:clean (default-clean) @> >
> >
> > > nbm-maven-harness ---> >
> >
> > > [INFO] Deleting> >
> >
> > > /atlas/data/git/incubator-netbeans-mavenutils/nbm-maven-harness/target>
> >
> >
> > > [INFO]> >
> >
> > > [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-version)
> @> >
> >
> > > nbm-maven-harness ---> >
> >
> > > [INFO]> >
> >
> > > [INFO] --- maven-remote-resources-plugin:1.5:process> >
> >
> > > (process-resource-bundles) @ nbm-maven-harness ---> >
> >
> > > [INFO]> >
> >
> > > [INFO] --- maven-dependency-plugin:2.4:get (unpack-harness) @> >
> >
> > > nbm-maven-harness ---> >
> >
> > > [INFO]> >
> >
> > >
> >
> >
> >
> > > [INFO] BUILD FAILURE> >
> >
> > > [INFO]> >
> >
> > >
> >
> >
> >
> > > [INFO] Total time:  1.971 s> >
> >
> > > [INFO] Finished at: 2019-03-16T18:41:01+01:00> >
> >
> > > [INFO]> >
> >
> > >
> >
> >
> >
> > > [ERROR] Failed to execute goal> >
> >
> > > org.apache.maven.plugins:maven-dependency-plugin:2.4:get
> (unpack-harness)>>
> >
> >
> > > on projec> >
> >
> > > t nbm-maven-harness: Couldn't download artifact: Failure to find> >
> >
> > > org.netbeans.modules:org-netbeans-modules-apisupp> >
> >
> > > ort-harness:nbm:${netbeans.version} in>
> > 
> https://repo.maven.apache.org/maven2>>
> >
> >
> > > was cached in the local repository, re> >
> >
> > > solution will not be reattempted until the update interval of central
> has>>
> >
> >
> > > elapsed or updates are forced> >
> >
> > > [ERROR]> >
> >
> > > [ERROR] Try downloading the file manually from the project website.> >
> >
> > > [ERROR]> >
> >
> > > [ERROR] Then, install it using the command:> >
> >
> > > [ERROR] mvn install:install-file -DgroupId=org.netbeans.modules> >
> >
> > > -DartifactId=org-netbeans-modules-apisupport-h> >
> >
> > > arness -Dversion=${netbeans.version} -Dpackaging=nbm
> -Dfile=/path/to/file>>
> >
> >
> > > [ERROR]> >
> >
> > > [ERROR] Alternatively, if you host your own repository you can deploy
> the>>
> >
> >
> > > file there:> >
> >
> > > [ERROR] mvn deploy:deploy-file -DgroupId=org.netbeans.modules> >
> >
> > > -DartifactId=org-netbeans-modules-apisupport-har> >
> >
> > > ness -Dversion=${netbeans.version} -Dpackaging=nbm
> -Dfile=/path/to/file>
> >
> >
> > > -Durl=[url] -DrepositoryId=[id]> >
> >
> > > [ERROR]> >
> >
> > > [ERROR]> >
> >
> 

Re: [VOTE] PMC chair for Apache NetBeans

[Jaroslav Tulach]

+1

Without Geertjan's enthusiasm, passion for the NetBeans project and his hard 
work inside of Oracle as well as his endless promotion of the brand 
externally, there would be no Apache NetBeans as we know it now.

Geertjan fully deserves to be the PMC chair. His only drawback (e.g. being an 
Oracle employee[1]) is negligible compared to the achievements he has made!

My vote goes to Geertjan, the NetBeans Saviour!

Jaroslav Tulach
NetBeans founder and initial architect

[1] It is not drawback per se, it just may be perceived as a drawback by some.

Dne pátek 1. března 2019 15:28:52 CET, Glenn Holmer napsal(a):
> This voting thread is to confirm Geertjan Wielenga as the first PMC
> chair of NetBeans as we leave incubation and begin our journey as a
> top-level Apache project. As an Oracle employee, Geertjan has been in a
> unique position to help guide the project to independence and is the
> best choice to complete that process.
> 
> As a reminder, here are the duties of the PMC chair:
> 
> http://www.apache.org/dev/pmc.html#chair
> 
> Please indicate your vote with +1, 0, or -1.





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [VOTE] Release Apache NetBeans (incubating) parent pom 1

[Jaroslav Tulach]

+1

Eric, please comment and/or approve 
https://github.com/apache/incubator-netbeans-html4j/pull/16 - it seems the pom 
works for HTML/Java API.

-jt


Dne pátek 22. února 2019 15:42:19 CET, Eric Barboni napsal(a):
> Dear members of the Apache NetBeans community.
> 
> 
> 
> In order to prepare release of Apache NetBeans (incubating) maven Artefacts
> (RELEASE100 and RELEASE090)  as well as Apache NetBeans (incubating)
> mavenutilities (incubating)  such as nbm-maven-plugin:
> 
> 
> 
> I want to call a vote on releasing Apache NetBeans (incubating) maven parent
> version 1.
> 
> 
> 
> This is a maven pom containing the basic information needed like mailing
> list, licence.
> 
> 
> 
> 
> 
> The release is staged at the following place:
> 
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbean
> s-mavenutils/apache-netbeans-parent-1/
> 
> incubating-apache-netbeans-parent-1-source-release.zip
> 
> 
> 
> sha512 is
> 
> incubating-apache-netbeans-parent-1-source-release.zip.sha512
> 
> dfdf51ecaea0bc4481effd0184c52ebb371ea190b073d8ea147f4bb19b19210c89909c06a76e
> 8da672457b98e4f3bafac58a984ca090685e19f420c738437235
> 
> 
> 
> tag on scm https://github.com/apache/incubator-netbeans-mavenutils is
> 
> org-apache-netbeans-parent-1-vc1
> 
> 
> 
> 
> 
> Staged maven repository exists at the following url:
> 
> https://repository.apache.org/content/repositories/orgapachenetbeans-1009/
> 
> 
> 
> 
> 
> Vote open for at least 72 hours.
> 
> 
> 
> [ ] +1
> 
> [ ] +0
> 
> [ ] -1
> 
> 
> 
> Best Regards
> 
> Eric
> 
> 
> 
> PS: this will not impact Apache NetBeans 11.0 release.





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Revert Fragments for libs.javafx with JavaFX 11 implementation #917 (was: Re: Apache NetBeans 11.0 has been Branched!)

[Jaroslav Tulach]

Thanks for the mailing list heads-up! I talked to Toni and explained that
20 days silence in an issue resolution is undesirable. Hopefully a way to
avoid that in the future has been agreed upon.

PR-1143 seems to resolve the licensing problem, so I've just merged it.
-jt

st 20. 2. 2019 v 4:46 odesílatel Jaroslav Tulach 
napsal:

> -1 (e.g. veto) to the revert proposal.
>
> Dne středa 20. února 2019 1:03:36 CET, Matthias Bläsing napsal(a):
> > Hello all,
> >
> > Am Mittwoch, den 13.02.2019, 20:01 +0100 schrieb Matthias Bläsing:
> > > Am Mittwoch, den 13.02.2019, 10:44 -0800 schrieb Laszlo Kishalmi:
> > > > BTW, as we are not really going to release this build and that would
> be
> > > > true for the next one.
> > > > Shall we play the release dance and upload everything to the staging
> > > > area and create vote threads?
> > >
> > > we can skip this. We have a release blocker right in the LICENSE file:
> > >
> > > [JavaFX binaries are packaged with Apache NetBeans]
> > >
> > > @Toni, could you please have a look at the comments in the JavaFX PR:
> > >
> > > https://github.com/apache/incubator-netbeans/pull/917
> > >
> > > and the corresponding issue:
> > >
> > > https://issues.apache.org/jira/browse/NETBEANS-1995
> >
> > I intent to revert the changes that were committed as the PR titled
> > "Fragments for libs.javafx with JavaFX 11 implementation #917".
> >
> > The primary reason: the PR messes with the build process
>
> OK, as far as I can see build is slightly complicated. That is not a
> reason
> for revert.
>
> > and let it
> > look like GPLv2-CP runtime libraries are pulled into the build.
>
> "look like" isn't reason for revert.
>
> > Secondary reasons:
> >
> > - the local maven repository is hardcoded to $HOME/.m2
>
> OK, feel free to propose a fix. Not a revert.
>
>
> > => Anyone using a windows installation with roaming profiles and a not
> > so fast network will know, that having .m2 at the default location is a
> > bad idea
> >
> > - the m2 url handler will not handle non Maven-Central URLs
>
> As far as I can tell, that is not a bug, but feature.
>
> > => There are other popular maven repositories (bintray), that might be
> > relevant for us.
>
> "might be" isn't reason for revert.
>
> Best regards.
> -jt
>
>
> > While looking into this, I noticed, that the generation of license file
> > needs rereview, as the per-nbm files also contain per-file licenses for
> > files not included in that nbm. Maybe both problems can be tackled
> > togehter.
> >
> >
> > Greetings
> >
> > Matthias
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
>

Re: Revert Fragments for libs.javafx with JavaFX 11 implementation #917 (was: Re: Apache NetBeans 11.0 has been Branched!)

[Jaroslav Tulach]

-1 (e.g. veto) to the revert proposal.

Dne středa 20. února 2019 1:03:36 CET, Matthias Bläsing napsal(a):
> Hello all,
> 
> Am Mittwoch, den 13.02.2019, 20:01 +0100 schrieb Matthias Bläsing:
> > Am Mittwoch, den 13.02.2019, 10:44 -0800 schrieb Laszlo Kishalmi:
> > > BTW, as we are not really going to release this build and that would be
> > > true for the next one.
> > > Shall we play the release dance and upload everything to the staging
> > > area and create vote threads?
> > 
> > we can skip this. We have a release blocker right in the LICENSE file:
> > 
> > [JavaFX binaries are packaged with Apache NetBeans]
> > 
> > @Toni, could you please have a look at the comments in the JavaFX PR:
> > 
> > https://github.com/apache/incubator-netbeans/pull/917
> > 
> > and the corresponding issue:
> > 
> > https://issues.apache.org/jira/browse/NETBEANS-1995
> 
> I intent to revert the changes that were committed as the PR titled
> "Fragments for libs.javafx with JavaFX 11 implementation #917".
> 
> The primary reason: the PR messes with the build process 

OK, as far as I can see build is slightly complicated. That is not a reason 
for revert.

> and let it
> look like GPLv2-CP runtime libraries are pulled into the build.

"look like" isn't reason for revert.

> Secondary reasons:
> 
> - the local maven repository is hardcoded to $HOME/.m2

OK, feel free to propose a fix. Not a revert.

 
> => Anyone using a windows installation with roaming profiles and a not
> so fast network will know, that having .m2 at the default location is a
> bad idea
> 
> - the m2 url handler will not handle non Maven-Central URLs

As far as I can tell, that is not a bug, but feature.

> => There are other popular maven repositories (bintray), that might be
> relevant for us.

"might be" isn't reason for revert.

Best regards.
-jt


> While looking into this, I noticed, that the generation of license file
> needs rereview, as the per-nbm files also contain per-file licenses for
> files not included in that nbm. Maybe both problems can be tackled
> togehter.
> 
> 
> Greetings
> 
> Matthias
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Release Apache NetBeans parent pom 1.0

[Jaroslav Tulach]

Dne pondělí 18. února 2019 16:55:52 CET, Ate Douma napsal(a):
> This *new* maven artifact is using Maven groupId: org.netbeans.maven.
> Which IMO can and should at least use the org.apache.netbeans prefix.
> There is no existing usage, yet, so *not* using the org.apache. prefix
> as expected seems weird and wrong to me.

As a strong proponent of compatibility, I am ready to defend existing co-
ordinates for existing artifacts.

However in this case I agree with Ate. Let's use org.apache.netbeans:parent:1

My voice isn't a vote. I just want to support Ate's argumentation in this 
case: When in ASF behave like Apache!
-jt




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Netbeans future platform and IDE packaging and design - brainstorming

[Jaroslav Tulach]

My 2 Kč:

Versioning of individual JAR files produced by NetBeans is already semantic
versioning friendly. However such versioning is completely independent from
the version of the final IDE.

Version of the whole NetBeans IDE has always been a "marketing number", not
a technical one. E.g. no rules apply, changes are made chaotically just to
impress, not to mean something. Certainly they aren't predictable - a
necessary attribute of semantic versioning.

-jt


út 29. 1. 2019 v 1:23 odesílatel hanas...@gmail.com 
napsal:

> May I also suggest the following pattern for future release consideration?
>
> Maven'like / semver.org : using X.Y.Z
>
> * The netbeans "product" would be X.Y  with any value for Z being 100%
> compatible with X.Y
>
> * Thus an executable netbeans jar of netbeans-x.y.z.jar and maybe
> netbeans-x.y.jar  which wraps and executes the newest x.y.z.jar
> available (maybe downloading it from the netbeans site for auto-upgrade
>
> * the executable JAR would be the slim netbeans application framework
> with the following unremovable plugins:
> - plugin manager
> - plugin for 'distributions' like
> : ee
> : base
> : php
> : the different setups as the old netbeans.org
> * Each distribution specifies a set of plugins
> - each plugin has an x.y.z
>
> If needed, netbeans...jar and each plugin...jar may be basically a BOM
> (bill of materials) that contains required JAR files (think of a FAT
> JAR, shade, or SpringBoot executable JAR)
>
> Thank you, Frederick Bloom
> hanasaki
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>

Package NetBeans as Mac OS X application

[Jaroslav Tulach]

Hello guys,
I've just reconfigured NetBeans to present itself as a Mac OS X
Application. I followed stackoverflow advice
https://stackoverflow.com/questions/281372/executing-shell-scripts-from-the-os-x-dock/281389#281389

If you don't need a Terminal window, you can make any executable file an
Application just by moving example.sh to
example.sh.app/Contents/MacOS/example.sh. You can place the Application in
your dock like any other, and execute it with a click.


E.g. after unzipping, I renamed

$ mv netbeans netbeans.app

and created the necessary subdirectory:

$ mkdir -p netbeans.app/Contents/MacOS/

and then created a symlink:

$ cd netbeans.app/Contents/MacOS/
$ ln -s ../../bin/netbeans .

That's all and now my computer recognizes Apache NetBeans 10 as an
application...

-jt

Cannot compile NetBeans because of Gradle

[Jaroslav Tulach]

I on Linux, behind a corporate proxy. I could get though it with
nbbuild.*DownloadBinaries, but since the integration of Gradle I cannot
build NetBeans anymore. Can this be fixed?
-jt


-copy-gradle-wrapper:

-uptodate-tooling:

build-tooling-lib:
 [java] Downloading
https://services.gradle.org/distributions/gradle-4.10.2-bin.zip
 [java]
 [java] Exception in thread "main" java.net.ConnectException:
Connection timed out (Connection timed out)
 [java] at java.net.PlainSocketImpl.socketConnect(Native Method)
 [java] at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
 [java] at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
 [java] at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
 [java] at
java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
 [java] at java.net.Socket.connect(Socket.java:589)
 [java] at
sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:673)
 [java] at
sun.security.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:173)
 [java] at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
 [java] at
sun.net.www.http.HttpClient.openServer(HttpClient.java:463)
 [java] at
sun.net.www.http.HttpClient.openServer(HttpClient.java:558)
 [java] at
sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:264)
 [java] at
sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:367)
 [java] at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191)
 [java] at
sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1156)
 [java] at
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1050)
 [java] at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177)
 [java] at
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
 [java] at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
 [java] at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
 [java] at
org.gradle.wrapper.Download.downloadInternal(Download.java:67)
 [java] at org.gradle.wrapper.Download.download(Download.java:52)
 [java] at org.gradle.wrapper.Install$1.call(Install.java:62)
 [java] at org.gradle.wrapper.Install$1.call(Install.java:48)
 [java] at
org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:69)
 [java] at org.gradle.wrapper.Install.createDist(Install.java:48)
 [java] at
org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:107)
 [java] at
org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:62)
  [nbmerge] Failed to build target: all-gradle

BUILD FAILED

Help, JavaScript fans! was: Use Graal.js (parser) for NetBeans 11

[Jaroslav Tulach]

I assume there is a lot of people interested in support of modern
JavaScript, right? We need you help:

čt 24. 1. 2019 v 5:59 odesílatel Jaroslav Tulach 
napsal:
>
> The PR-1011 is in.
>
> Somebody needs to start working on rewriting the `webcommon/
> javascript2.editor/` to use the parser in `webcommon.libs.graaljs`.



Sváťa created a PR: https://github.com/apache/incubator-netbeans/pull/1099,
but it cannot be merged until the code is rewritten to use the new version
of the parser and work correctly. There is a Jenkins job that tracks the
status:

https://builds.apache.org/job/incubator-netbeans-jsparser/

Right now we have 693 failures. Please help us fix them. The instructions
are given in the job description, and it should be fairly easy. Get the
repository:

git clone https://github.com/sdedic/incubator-netbeans.git
cd incubator-netbeans
git checkout experimental/graaljs_parser

and then build it all and check the tests:

ant build
for i in webcommon/*; do
  (cd $i; ant test-unit -Dcontinue.after.failing.tests=true)
done

You can open any module under webcommon in the NetBeans IDE, select a test
and run or debug it.

If you care about JavaScript, please help: Fix a test. Make NetBeans better!
-jt



> Dne neděle 13. ledna 2019 5:24:04 CET, Jaroslav Tulach napsal(a):
> > Hello Emilian, Matthias & everyone.
> >
> > Dne sobota 12. ledna 2019 9:38:53 CET, Emilian Bold napsal(a):
> > > I see the parser source is here
> > >
> https://github.com/graalvm/graaljs/tree/master/graal-js/src/com.oracle.js.
> > > pa rser but it's not compiled as an independent JAR available in Maven
> > > Central. Could the GraalVM project do this?
> > >
> > > The whole org.graalvm.js:js seems pretty big and has many
> > > dependencies. We just need the parser.
> >
> > Let's consider this in the context of 371465581f2011 and PR-1011 and
> > NETBEANS-1009.
> >
> > #1 - Nashorn isn't the future of JavaScript engines on JDK. We will need
> > another engine anyway in the future.
> >
> > #2 - Emilian commented in PR-1011 that using Graal.js from bootclasspath
> > isn't appropriate
> >
> > #3 - We need parts of Graal.js anyway for the editing support
> >
> > #4 - OracleLabs (my employer) supports wider use of Graal.js
> >
> > When I look at the parser issue from a broader perspective, I propose to:
> >
> > * modify PR-1011 to bundle whole Graal.js and necessary libraries
> >
> > that will solve #1, #2, #4. Then we need another PR to modify the
> JavaScript
> > editing infrastructure to use the new version of the Graal.js parser. I
> was
> > hoping Svatopluk Dědic could take care of that, but as he is busy with
> > other tasks, help from community would be more than welcomed. Anyone
> > interested in supporting EcmaScript7 features (syntax of which the newest
> > version of Graal.js handles) in NetBeans?
> >
> > I'll work on modifying the PR-1011 to include Graal.js as a library on
> > Monday, next week.
> > -jt
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Javadoc for 9 and 10

[Jaroslav Tulach]

čt 24. 1. 2019 v 15:15 odesílatel Eric Barboni  napsal:

> Javadoc for 9.0 and 10.0 are regenerated according to Jaroslav comments
>

Oh, that is nice a quick. Thanks.

There are still wrong case with the following api's belonging to stable but
> rendered as "under dev" or "friend"
> Base Utilities API ( javadoc )
>

The stability is decided based on  tags present in the arch.xml
document. If there is:



then the whole API is treated as stable. Alas, when Utilities API was split
into two, this  tag disappeared.
-jt



> Filesystems NetBeans Client ( javadoc )
> Java Source ( javadoc )
> UI Gestures Collector Infrastructure ( javadoc )
> UI Handler Library ( javadoc )
>
> What should we do there
>
> Regards
> Eric
> -Message d'origine-
> De : Eric Barboni 
> Envoyé : jeudi 24 janvier 2019 09:27
> À : dev@netbeans.incubator.apache.org
> Objet : RE: Javadoc for 9 and 10
>
> Hi
>  I will commit the changes to the respective branches.
>  I thinks the https://bits.netbeans.org/8.2/javadoc/ was bad generated
> and I base my previous branding on that :/
>
> Regards
> Eric
> -Message d'origine-
> De : László Kishalmi  Envoyé : jeudi 24
> janvier 2019 06:03 À : Apache NetBeans 
> Objet : Re: Javadoc for 9 and 10
>
> Got that! Thanks!
>
> On Wed, Jan 23, 2019, 20:46 Jaroslav Tulach  wrote:
>
> > Dne neděle 20. ledna 2019 16:49:45 CET, Geertjan Wielenga napsal(a):
> > > Fantastic work as always. :-)
> >
> > Thanks for the Javadocs  at
> >
> > http://bits.netbeans.org/dev/javadoc/
> > https://bits.netbeans.org/9.0/javadoc/
> > https://bits.netbeans.org/10.0/javadoc/
> >
> > Btw. The Javadoc for releases should only contain stable modules.
> > There should be no "under development" warning and modules like
> > bootstrap, core, etc.
> > shouldn't be listed there. They were not listed in 8.0 and prior
> releases:
> >
> > http://bits.netbeans.org/8.0/javadoc/
> >
> > This can be done by modifying `nbbuild/build.properties` and removing
> > other than stable from
> >
> > config.javadoc.all=\
> > ${config.javadoc.stable},\
> > ${config.javadoc.devel},\
> > ${config.javadoc.friend},\
> > ${config.javadoc.deprecated}
> >
> > Probably something for the release coordianator to do after branching
> > next time.
> >
> > Thanks again for publishing the Javadocs.
> > -jt
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> > For additional commands, e-mail:
> > dev-h...@netbeans.incubator.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.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Use Graal.js (parser) for NetBeans 11

[Jaroslav Tulach]

The PR-1011 is in.

Somebody needs to start working on rewriting the `webcommon/
javascript2.editor/` to use the parser in `webcommon.libs.graaljs`.

Any volunteers?
-jt


Dne neděle 13. ledna 2019 5:24:04 CET, Jaroslav Tulach napsal(a):
> Hello Emilian, Matthias & everyone.
> 
> Dne sobota 12. ledna 2019 9:38:53 CET, Emilian Bold napsal(a):
> > I see the parser source is here
> > https://github.com/graalvm/graaljs/tree/master/graal-js/src/com.oracle.js.
> > pa rser but it's not compiled as an independent JAR available in Maven
> > Central. Could the GraalVM project do this?
> > 
> > The whole org.graalvm.js:js seems pretty big and has many
> > dependencies. We just need the parser.
> 
> Let's consider this in the context of 371465581f2011 and PR-1011 and
> NETBEANS-1009.
> 
> #1 - Nashorn isn't the future of JavaScript engines on JDK. We will need
> another engine anyway in the future.
> 
> #2 - Emilian commented in PR-1011 that using Graal.js from bootclasspath
> isn't appropriate
> 
> #3 - We need parts of Graal.js anyway for the editing support
> 
> #4 - OracleLabs (my employer) supports wider use of Graal.js
> 
> When I look at the parser issue from a broader perspective, I propose to:
> 
> * modify PR-1011 to bundle whole Graal.js and necessary libraries
> 
> that will solve #1, #2, #4. Then we need another PR to modify the JavaScript
> editing infrastructure to use the new version of the Graal.js parser. I was
> hoping Svatopluk Dědic could take care of that, but as he is busy with
> other tasks, help from community would be more than welcomed. Anyone
> interested in supporting EcmaScript7 features (syntax of which the newest
> version of Graal.js handles) in NetBeans?
> 
> I'll work on modifying the PR-1011 to include Graal.js as a library on
> Monday, next week.
> -jt





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: build process

[Jaroslav Tulach]

Dne sobota 19. ledna 2019 16:06:42 CET, joe schmo napsal(a):
> Thank you for your response, my question may have sounded stupid, I am aware
> how to redirect screen output, I guess I was wondering if there was any
> available documentation for the build process.

The apisupport harness is documented here

https://github.com/apache/incubator-netbeans/blob/
dc92644eeb9000fd76de1bd9432519063cca94c0/harness/apisupport.harness/release/
README

the NetBeans own build system[1] builds on that. Most of the Ant task and 
script code is under `nbbuild` directory.

Btw. NetBeans offers decent Ant script debugger. Just right click on 
`build.xml` and select "Debug -> target".
-jt

[1] see nbbuild/templates/projectized.xml with additions and changes. 

> 
> Regards,
> 
> BC
> 
> From: Emilian Bold 
> Sent: January 19, 2019 7:38 AM
> To: NetBeans Dev@
> Cc: d...@netbeans.apache.org
> Subject: Re: build process
> 
> ant | tee logfile.txt
> 
> (cd submodule; ant)
> 
> --emi
> 
> http://coolbeans.xyz/ - CoolBeans: An IDE for Java, JavaEE, PHP and more!
> 
> On Sat, Jan 19, 2019 at 12:31 PM joe schmo  wrote:
> > I'll try again.  Is there any documentation on the build process?  I'm
> > wondering if there is a way to generate a log file during the build,
> > also, I'm wondering if there is a way to build individual modules with
> > the ant script.
> > 
> > Thanks
> > BC
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Javadoc for 9 and 10

[Jaroslav Tulach]

Dne neděle 20. ledna 2019 16:49:45 CET, Geertjan Wielenga napsal(a):
> Fantastic work as always. :-)

Thanks for the Javadocs  at

http://bits.netbeans.org/dev/javadoc/
https://bits.netbeans.org/9.0/javadoc/
https://bits.netbeans.org/10.0/javadoc/

Btw. The Javadoc for releases should only contain stable modules. There should 
be no "under development" warning and modules like bootstrap, core, etc. 
shouldn't be listed there. They were not listed in 8.0 and prior releases:

http://bits.netbeans.org/8.0/javadoc/

This can be done by modifying `nbbuild/build.properties` and removing other 
than stable from 

config.javadoc.all=\
${config.javadoc.stable},\
${config.javadoc.devel},\
${config.javadoc.friend},\
${config.javadoc.deprecated}

Probably something for the release coordianator to do after branching next 
time.

Thanks again for publishing the Javadocs.
-jt




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: API change causes signature test failure

[Jaroslav Tulach]

Dne čtvrtek 24. ledna 2019 4:08:37 CET, Jaroslav Tulach napsal(a):
> The easiest way is to not make *incompatible* API changes.

I've just written a new essay summarizing the advices: 
http://wiki.apidesign.org/wiki/Never_update_tests

-jt




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Separate convenience binaries

[Jaroslav Tulach]

Dne neděle 20. ledna 2019 13:13:49 CET, Geertjan Wielenga napsal(a):
> And only ‘all’ would include ergonomics.

Reconsider:

Java benefits from ergonomics to download nbjavac. So does webcommon right 
now.
-jt





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: API change causes signature test failure

[Jaroslav Tulach]

Dne středa 23. ledna 2019 14:03:48 CET, Mark Phipps napsal(a):
> Hi Folks,
> 
> I created the pr below, but as it includes an API change, the build
> fails (as it did on my local copy - see output below) due to an invalid
> API signature?
> 
> https://github.com/apache/incubator-netbeans/pull/1095
> 
> How does one fix that?

The easiest way is to not make *incompatible* API changes.
-jt

PS: The check has been integrated by 
https://github.com/apache/incubator-netbeans/pull/1064

PPS: Is it a shameless promo of my website and book?
http://apidesign.org

> sigtest check: platform/openide.windows; cnb: org-openide-windows;
> email: api-chan...@netbeans.org; type: check
> check-sigtest:
> /home/mark/Development/github/incubator-netbeans/platform/openide.windows/bu
> ild/test/sigtest/results/org.openide.windows Packages: org.openide.windows.*
> email: api-chan...@netbeans.org
> SignatureTest report
> Base version: 6.79.1
> Tested version: 6.80
> Check mode: bin [throws removed]
> Constant checking: on
> Class org.openide.windows.Mode
>"E2.1 - Interface method added" : method public abstract
> java.lang.String org.openide.windows.Mode.toXml()
> Class org.openide.windows.WindowManager
>"E5.2 - Adding abstract methods" : method public abstract void
> org.openide.windows.WindowManager.updateModeContraintsFromXml(java.lang.Stri
> ng) "E5.2 - Adding abstract methods" : method public abstract boolean
> org.openide.windows.WindowManager.removeMode(org.openide.windows.Mode)
> "E5.2 - Adding abstract methods" : method public abstract void
> org.openide.windows.WindowManager.createModeFromXml(java.lang.String)
> /home/mark/Development/github/incubator-netbeans/platform/openide.windows/bu
> ild/test/sigtest/results/org-openide-windows.xml: 1 failures in
> /home/mark/Development/github/incubator-netbeans/platform/openide.windows/nb
> project/org-openide-windows.sig
> /home/mark/Development/github/incubator-netbeans/nbbuild/templates/projecti
> zed.xml:768: Signature tests return code is wrong (1), check the messages
> above BUILD FAILED (total time: 0 seconds)
> 
> 
> 
> *Mark Phipps |***Front Office Development Manager
> *Sucden Financial Limited |*Plantation Place South***|***60 Great Tower
> Street***| *London EC3R 5AZ
> 
> *Telephone (DDI): *+44 (0)20 3207 5140* | Switchboard:***+44 (0)20 3207 5000
> *Email: *mark.phi...@sucfin.com  |
> *Website:* www.sucdenfinancial.com 
> 
> 
> Description: signature20170705.jpg 
> 
> Twitter | LinkedIn
> 
> 
> www.sucdenfinancial.com
> 
> Sucden Financial Limited, Plantation Place South, 60 Great Tower Street,
> London EC3R 5AZ Telephone +44 203 207 5000
> 
> Registered in England no. 1095841
> VAT registration no. GB 446 9061 33
> 
> Authorised and Regulated by the Financial Conduct Authority (FCA) and
> entered in the FCA register under no. 114239
> 
> This email, including any files transmitted with it, is confidential and may
> be privileged. It may be read, copied and used only by the intended
> recipient. If you are not the intended recipient of this message, please
> notify postmas...@sucfin.com immediately and delete it from your computer
> system.
> 
> We believe, but do not warrant, that this email and its attachments are
> virus-free, but you should check.
> 
> Sucden Financial Limited may monitor traffic data of both business and
> personal emails. By replying to this email, you consent to Sucden Financial
> 's monitoring the content of any emails you send to or receive from Sucden
> Financial . Sucden Financial is not liable for any opinions expressed by
> the sender where this is a non-business email.
> 
> The contents of this e-mail do not constitute advice and should not be
> regarded as a recommendation to buy, sell or otherwise deal with any
> particular investment. Where any trade ideas are made by an employee of
> Sucden Financial in an electronic communication, these are made
> incidentally to your dealing relationship with us and are provided solely
> to enable you to make your own investment decisions and do not amount to
> advice. Please note that the employee may have had many, varied trade ideas
> over the past 12 months, including contrary ideas. Any trade ideas are
> solely based on the employee’s market knowledge and experience and may not
> be tailored to your specific circumstances or investment objectives. Please
> contact the employee who made the trade idea if you would like to see any
> of his/her trade ideas made in the previous 12 months for comparative
> purposes. Please visit our website to view our full risk warnings and
> disclaimers: www.sucdenfinancial.com.
> 
> This message has been scanned for viruses by Mimecast.





-
To unsubscribe, e-mail: 

Javadoc for 9 and 10

[Jaroslav Tulach]

Hi webmasters and release coordinators!

I can see our latest Javadoc at

https://netbeans.apache.org/javadoc/dev/index.html

but we don't seem to have pages for Javadoc 9 and Javadoc 10. E.g. I cannot 
link to those versions from the above index page. The last version with 
Javadoc that I found is:

http://bits.netbeans.org/8.2/javadoc/

-jt




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Use Graal.js (parser) for NetBeans 11

[Jaroslav Tulach]

Hello Emilian, Matthias & everyone.

Dne sobota 12. ledna 2019 9:38:53 CET, Emilian Bold napsal(a):
> I see the parser source is here
> https://github.com/graalvm/graaljs/tree/master/graal-js/src/com.oracle.js.pa
> rser but it's not compiled as an independent JAR available in Maven
> Central. Could the GraalVM project do this?
> 
> The whole org.graalvm.js:js seems pretty big and has many
> dependencies. We just need the parser.

Let's consider this in the context of 371465581f2011 and PR-1011 and 
NETBEANS-1009.

#1 - Nashorn isn't the future of JavaScript engines on JDK. We will need 
another engine anyway in the future.

#2 - Emilian commented in PR-1011 that using Graal.js from bootclasspath isn't 
appropriate

#3 - We need parts of Graal.js anyway for the editing support

#4 - OracleLabs (my employer) supports wider use of Graal.js

When I look at the parser issue from a broader perspective, I propose to:

* modify PR-1011 to bundle whole Graal.js and necessary libraries

that will solve #1, #2, #4. Then we need another PR to modify the JavaScript 
editing infrastructure to use the new version of the Graal.js parser. I was 
hoping Svatopluk Dědic could take care of that, but as he is busy with other 
tasks, help from community would be more than welcomed. Anyone interested in 
supporting EcmaScript7 features (syntax of which the newest version of 
Graal.js handles) in NetBeans?

I'll work on modifying the PR-1011 to include Graal.js as a library on Monday, 
next week.
-jt





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Use Graal.js parser for NetBeans 11 was: Where is `Oracle JS Parser Implementation` built from?

[Jaroslav Tulach]

Dne pátek 11. ledna 2019 22:14:41 CET, Emilian Bold napsal(a):
> This means that we could actually include it in Apache NetBeans,
> correct? No need for the run-time plugin.

Newer version of lib.nashorn parser is available as org.graalvm.js[1] in Maven 
repository. 
It is licensed under friendly UPL license. It is "just" necessary to modify the 
code to use 
the new version.

I've put that not to https://issues.apache.org/jira/browse/NETBEANS-2

We have just one problem: find somebody who does the work...
-jt




[1] https://search.maven.org/search?q=g:org.graalvm.js

Re: Absolute paths written to all-resources.dat which break the IDE if moved entirely

[Jaroslav Tulach]

Dne pátek 4. ledna 2019 12:01:58 CET, Emilian Bold napsal(a):
> Oh, I found the bug. I had a script call ./bin/netbeans but it was
> using the full path with a lower-case typo. Now, since macOS usually
> has a case-insensitive filesystem, the script did launch the IDE
> correctly.
> 
> *But*, it seems netbeans.home copied the path with the typo and then
> the Java code could no longer compute the relative path (since the
> strings didn't startWith) and stored the full path.

Great you can reproduce it. Try to insert some "equalsIgnoreCase" or 
"toLowerCase" or rather File.getCanonicalFile() in the caching code. It would 
be great if this got improved and also (if we are lucky) fixed the Windows 
Jenkins job failures.

-jt




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Feedback: Release Management of Apache NetBeans (incubating) 10.0

[Jaroslav Tulach]

Dne sobota 29. prosince 2018 1:11:36 CET, Laszlo Kishalmi napsal(a):
> I was honored being your release manager of Apache NetBeans (incubating)
> 10.0.

Good work.

> good enough. As of the future, if the community trusts me I apply as a
> volunteer release manager for the upcoming Apache NetBeans 11.0 release.

Great.

> After last minute changes...Please do not
> hesitate mark every legal related concerns as BLOCKER in JIRA, even if
> it is not a BLOCKER at all, we can't really let legal issues flying
> under our radar.

I'd like to see a page (or rather a link to a live JIRA query) that lists all 
the issues that prevent us to release next version of NetBeans. A single, well 
known place, where anyone can go and see the current BLOCKERs. It would be 
good to know what one has to do to include own issue on the list. With such 
page, I would make sure the Nashorn parser issue is BLOCKER in summer, not in 
November.

> I think Apache NetBeans (incubating) 10.0 is a great release!

+1 




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Absolute paths written to all-resources.dat which break the IDE if moved entirely

[Jaroslav Tulach]

There should be no absolute paths in the caches for anything under regular 
cluster installation and userdir. There are even tests to make sure that is 
true. They pass OK on Linux. One of them is known to fail on Windows:

https://builds.apache.org/job/incubator-netbeans-windows/lastCompletedBuild/
testReport/org.netbeans.core.startup.layers/CachingPreventsFileTouchesTest/
testCachesDontUseAbsolutePaths/

We don't test on Mac OS X as far as I know.
-jt


Dne středa 2. ledna 2019 0:22:29 CET, Emilian Bold napsal(a):
> If somebody downloads to ~/Downloads and starts the app from there the
> userdir on macOS will be in ~/Library/Application Support/ so there's
> no relative path between them and the paths are stored as absolute
> ("abs" identification).
> 
> I suspect the saving netbeans.home in lastModified/all-checksum.txt
> fixes the problem since it will invalidate the cache:
> 
> diff --git a/platform/o.n.bootstrap/src/org/netbeans/Stamps.java
> b/platform/o.n.bootstrap/src/org/netbeans/Stamps.java
> index e41c90897..7231bd827 100644
> --- a/platform/o.n.bootstrap/src/org/netbeans/Stamps.java
> +++ b/platform/o.n.bootstrap/src/org/netbeans/Stamps.java
> @@ -313,6 +313,7 @@ public final class Stamps {
>  String[] relativeDirs = Clusters.relativeDirsWithHome();
>  String home = System.getProperty ("netbeans.home"); // NOI18N
>  if (home != null) {
> +sb.append("home=").append(home).append("\n");
>  long stamp = stampForCluster (new File (home), result,
> newestFile, processedDirs, checkStampFile, true, null);
> 
> sb.append(relativeDirs[0]).append('=').append(stamp).append('\n'); }
> 
> Does this make sense? I wonder why I can't reproduce it with 8.2?
> 
> --emi
> 
> http://coolbeans.xyz/ - CoolBeans: An IDE for Java, JavaEE, PHP and more!
> 
> On Tue, Jan 1, 2019 at 11:58 PM Emilian Bold  wrote:
> > I'm still investigating but it seems to me that under some conditions
> > absolute paths are saved in all-resources.dat (and the other .dat
> > files).
> > 
> > Problem is that if the user moves the application to another folder
> > (like from the Desktop to /Applications) then the IDE doesn't start
> > because it can't find any module! (Module could not be found...
> > ignoring).
> > 
> > So, is there something rather obvious to anyone going on here?
> > 
> > I suspect I will best reproduce this with a Platform app packaged as
> > macOS, but that script has another (unrelated) error which I also have
> > to report.
> > 
> > --emi
> > 
> > http://coolbeans.xyz/ - CoolBeans: An IDE for Java, JavaEE, PHP and more!





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Felix and JDK11 and API related news

[Jaroslav Tulach]

Hi.
I wanted to do something refreshing and useful during the Christmas break and 
as such I took a look at the here in discussed Felix & JDK11 problem. By 
upgrading to version 6.0.1 I think the problem is solved:

https://github.com/apache/incubator-netbeans/pull/1063

the tests of platform/core.netigso module (that use Felix as an OSGi 
container) pass OK with my local JDK11 installation.

When at it I also decided to setup a Jenkins builder to build and test the 
NetBeans Platform on JDK11. Here it is together with PR that contains majority 
of the related changes:

https://builds.apache.org/job/incubator-netbeans-linux-jdk11/
https://github.com/apache/incubator-netbeans/pull/1068

as you can see there is still a lot of failing tests. Your help investigating 
what is wrong and fixing them is more than welcomed! We want Apache NetBeans 
to build and run also on JDK11 at the end, right?

I was a bit sad to see that the NetBeans Linux Jenkins job
https://builds.apache.org/job/incubator-netbeans-linux/
is no longer blue. Then I realized that it is because of J2EE licenses. Hence 
I moved the licenses tests away:
https://builds.apache.org/job/incubator-netbeans-license/lastCompletedBuild/
testReport/
please track the licenses cleanup progress there. As a result the NetBeans 
Linux Jenkins job is blue again!

Last, but not least, I integrated snapshots of Apache NetBeans 10.0 APIs into 
the master branch. That should help us to keep backward compatibility:

https://github.com/apache/incubator-netbeans/pull/1064#discussion_r244659441

Accidentally removing an API element should break module build (F11 in the 
IDE). Please contact me (by CCing) directly if you find some problems with 
this approach.

Happy New Year. NetBeans never dies!
-jt




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Maven 1st was: Gradle Support for Apache NetBeans

[Jaroslav Tulach]

Dne sobota 29. prosince 2018 20:57:14 CET, Laszlo Kishalmi napsal(a):
> I would like to donate my Gradle works to Apache NetBeans.

Having Gradle support is important. Thanks for working on that.

However I'd like to also know how it will work with the proposed "Maven first" 
approach and Toni's realization of it 
https://github.com/apache/incubator-netbeans/pull/1038 ?

-jt




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Netbinox install area?

[Jaroslav Tulach]

Dne neděle 23. prosince 2018 12:49:39 CET, Peter Nabbefeld napsal(a):
> sters/docstree"), but I'd like to know if I could change the installation
> folder for Netbinox?

The best way to find out is to put breakpoint to platform/netbinox module and 
see how Equinox is configured when started.
-jt

PS: http://wiki.apidesign.org/wiki/Debugger




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [VOTE] Release Apache Netbeans 10.0 (incubating) [vote candidate 5]

[Jaroslav Tulach]

+1

I support the release in this form. It works well for me.
-jt

PS: Only JNA, testing and OSGi as external dependencies of the NetBeans
Platform, good:

nb10$ find netbeans/platform/ | grep /ext/
netbeans/platform/modules/ext/jna-4.4.0.jar
netbeans/platform/modules/ext/junit-jupiter-params-5.3.1.jar
netbeans/platform/modules/ext/jna-platform-4.4.0.jar
netbeans/platform/modules/ext/org.eclipse.osgi_3.9.1.nb9.jar
netbeans/platform/modules/ext/testng-6.8.1-dist.jar
netbeans/platform/modules/ext/hamcrest-core-1.3.jar
netbeans/platform/modules/ext/junit-jupiter-api-5.3.1.jar
netbeans/platform/modules/ext/updater.jar
netbeans/platform/modules/ext/junit-4.12.jar
netbeans/platform/modules/ext/osgi.core-5.0.0.jar
netbeans/platform/modules/ext/org.osgi.compendium-4.2.0.jar
netbeans/platform/modules/ext/junit-jupiter-engine-5.3.1.jar
netbeans/platform/modules/ext/org.apache.felix.main-4.2.1.jar


út 18. 12. 2018 v 5:38 odesílatel Laszlo Kishalmi 
napsal:

> Dear all,
>
> Please vote on our 5th voting candidate for the 10.0 release of Apache
> NetBeans (incubating).
>
> If this voting candidate passes, another similar voting will be started
> ongene...@incubator.apache.org, and if that passes too, then we can
> release this version.
>
> Apache NetBeans 10.0 (incubating) constitutes all but the enterprise
> cluster in the Apache NetBeans Git repo, which together provide the
> NetBeans Platform (i.e., the underlying application framework), as well as
> all the modules that provide the Java SE, PHP, JavaScript and Groovy
> features of Apache NetBeans.
>
> In short, Apache NetBeans 10.0 (incubating) is a full IDE for Java SE, PHP
> and JavaScript development with some Groovy language support.
>
> Build artifacts available here:
>
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-10.0-vc5/
>
> This voting is on the following artifact:
>
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-10.0-vc5/incubating-netbeans-10.0-vc5-source.zip
>
> Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and
> NOTICE files, as well as a README file with build instructions, which are
> the same as these:
>
> https://github.com/apache/incubator-netbeans/blob/10.0-vc5/README.md
>
> SHA1: 028b47ca10118e616208e4949fb79c2e38d74fd5
>
> KEYS file:
>
> https://dist.apache.org/repos/dist/release/incubator/netbeans/KEYS
>
> Apache NetBeans Git Repo tag: 10.0-vc5 :
> https://github.com/apache/incubator-netbeans/tree/10.0-vc5
>
> Note: NetBeans license violation checks are managed via the
> rat-exclusions.txt file:
>
>
> https://github.com/apache/incubator-netbeans/blob/10.0-vc5/nbbuild/rat-exclusions.txt
>
> Rat report shows no unknown licenses, except for license files:
>
>
> https://builds.apache.org/job/incubator-netbeans-release/380/artifact/rat-release-temp/nbbuild/build/rat-report.txt
>
> Included as a convenience binary, not relevant for the voting purposes
> (unzip it, run it and you'll see Apache NetBeans):
>
>
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-10.0-vc5/incubating-netbeans-10.0-vc5-bin.zip
>
> Release specific wiki page:
>
> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+10
>
> How (and what) to try out the release:
>
> 1. Download the artifact to be voted on and unzip it.
> 2. Check that the artifact does not contain any jar files,
> save the:
> platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/empty.jar
> 3. Verify the cryptographic signatures, the NOTICE and LICENSE file
> 4. Build it using the README provided by the artifact.
> 5. Look in nbbuild/netbeans for the NetBeans installation created by the
> build process.
>
>

Re: Adding build-javadoc to incubator-netbeans-linux jenkins?

[Jaroslav Tulach]

Dne pondělí 10. prosince 2018 22:08:53 CET, Antonio napsal(a):
> Hi all,
> 
> So I did this experiment by adding an additional line to the list of ant
> tasks like so:
> 
> build-javadoc -Djavadoc.web.root=http://bits.netbeans.org/dev/javadoc/
> -Dbuildnumber=latest
> 
> (I set the build number to "latest" so the generated javadoc zip has a
> known URL).
> 
> And the build (#935) failed:
> 
> https://builds.apache.org/view/Incubator%20Projects/job/incubator-netbeans-l
> inux/935/console
> 
> I'll take a look to try to find out what happened (any ideas appreciated).

It might be wiser to disable javadoc generation for newly added 3rd party 
libraries:

c.google.gson/src

-jt


> 
> Meanwhile I removed the line and fired a new build (#936).
> 
> Cheers,
> Antonio
> 
> El 10/12/2018 a las 12:42, Geertjan Wielenga escribió:
> > Excellent. Let's see what happens, how much time, etc.
> > 
> > Thanks,
> > 
> > Gj
> > 
> > On Mon, Dec 10, 2018 at 12:40 PM Antonio  wrote:
> >> I agree. I don't think this can be made optional. We want to deliver the
> >> javadocs whenever a merge is performed against master, right?
> >> 
> >> Building javadoc in my box takes about 30 minutes, but this is so
> >> because you need to build the IDE before generating the javadocs (that's
> >> why I thought it would be a good idea to add it to
> >> incubator-netbeans-linux job, immediately after the build finishes).
> >> 
> >> If nobody oposes I'll add this by the end of the day to the job, try it
> >> out, and then report here how longer the build is.
> >> 
> >> Cheers,
> >> Antonio
> >> 
> >> El 10/12/2018 a las 12:35, Neil C Smith escribió:
> >>> On Mon, 10 Dec 2018, 11:00 Geertjan Wielenga
> >>> 
> >>>   Sounds great. Does that add a lot of time to the build, could it be run
>  optionally i.e., not part of the standard automated run, assuming it
> >> 
> >> takes
> >> 
>  a long time?
> >>> 
> >>> I'm not sure optional is an option given the plan for using this. Be
> >>> good
> >>> to keep an eye on times and be prepared to revert for a plan B though,
> >> 
> >> but
> >> 
> >>> the bulk of the time for generating Javadoc from scratch appears to be
> >>> tasks already done in the build task.
> >>> 
> >>> Ideally this should also go in the release build task? We need to ship
> >> 
> >> the
> >> 
> >>> Javadoc zip alongside source and convenience binaries for NB10.
> >>> 
> >>> Best wishes,
> >>> 
> >>> Neil
> >> 
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> >> For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

[CANCELLED][VOTE] Re: [REJECTED] Release Apache NetBeans HTML/Java API version 1.6

[Jaroslav Tulach]

Resending with [CANCELLED][VOTE] in the subject to properly cancel the first 
(early November) vote on version 1.6.

The second vote (finished in December) isn't affected by this email and still 
remains approved.
-jt

Dne sobota 10. listopadu 2018 15:53:43 CET, Jaroslav Tulach napsal(a):
> OK, the proposed bits are rejected then. I'll prepare new ones and initiate
> new vote. Thanks for testing.
> -jt
> 
> út 6. 11. 2018 v 8:09 odesílatel Anton Epple 
> 
> napsal:
> > -1 In the meantime I had some failing tests when testing with dukescript
> > presenters and I confirmed with Jaroslav that the issue is in the proposed
> > 1.6 release
> > 
> > Toni
> > 
> > Am 04.11.18, 16:05 schrieb "Anton Epple" :
> > +1
> > 
> > Tested running with DukeScript Demos Project (
> > 
> > https://github.com/dukescript/dukescript-demos)
> > 
> > All 5 Demos build fine. I tested running 5 of them with WebView
> > 
> > Presenter and one with bck2brwsr without any problems.
> > 
> > Thanks for the great work!
> > 
> > Toni
> > 
> > Am 04.11.18, 08:27 schrieb "Jaroslav Tulach" <
> > 
> > jaroslav.tul...@gmail.com>:
> > Dear members of Apache NetBeans community.
> > I have finally found some spare time and managed to upload
> > 
> > HTML/Java API
> > 
> > bits to [Apache Nexus](https://repository.apache.org/) staging
> > 
> > repository.
> > 
> > The upload is the final piece in the whole HTML/Java API donation
> > 
> > process -
> > 
> > it was only possible now, when the netbeans.org domain (and thus
> > org.netbeans.html groupId) has been donated to Apache Foundation.
> > 
> > To finish the whole process, I am calling for a vote on Apache
> > 
> > NetBeans
> > 
> > HTML/Java 1.6 release. The release is staged at
> > 
> > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbe
> > ans-html4j/incubating-netbeans-html4j-1.6/> 
> > In addition to that the Maven artifacts built from the same
> > 
> > changeset
> > 
> > [release-1.6](
> > 
> > https://github.com/apache/incubator-netbeans-html4j/tree/release-1.6)
> > 
> > are available at the following staging repository:
> > https://repository.apache.org/content/repositories/orgapachenetbeans-1001/
> > 
> > Please do some testing and cast your vote by Wednesday Nov 7,
> > 
> > 2018. Thanks
> > 
> > for your support.
> > -jt
> > 
> > PS: This release of HTML/Java API doesn't influence release 10 of
> > 
> > Apache
> > 
> > NetBeans in any way
> > PPS: You can test the Maven bits by adding following snippet (with
> > appropriate XML closing tags) to your $HOME/.m2/settings.xml file:
> > 
> > 
> > http://maven.apache.org/SETTINGS/1.0.0;
> > 
> > xmlns:xsi="
> > 
> > http://www.w3.org/2001/XMLSchema-instance;
> > 
> >   xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> > 
> > http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > .
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > html-java-api-1.6
> > 
> > 
> > https://repository.apache.org/content/repositories/orgapachenetbeans-1001/
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > html-java-api-1.6
> > 
> > 
> > https://repository.apache.org/content/repositories/orgapachenetbeans-1001/
> > 
> > 
> > 
> > 
> > 
> >  

HTML/Java API doesn't propagate from repository.apache.org to Maven Central was: Release 1.6 of NetBeans HTML/Java API

[Jaroslav Tulach]

Thanks for your reply Maxim. I've been advised at infra chat to send an email 
to this mailing list with my inquiry. I apologize for the wrong subject - now 
it is corrected.

Dne neděle 2. prosince 2018 5:51:57 CET, Maxim Solodovnik napsal(a):
> Hello Jaroslav,
> 
> why are you sending this [RESULT] to builds@a.o?
> 
> According to your release artifacts: they are absent in Maven Central since
> they are absent in Apache Releases repo ...

I can see the bits at https://repository.apache.org/content/repositories/
releases/org/netbeans/html/net.java.html.boot.fx/1.6/ - isn't this area inside 
the Apache Releases repository?

> This is weird since Nexus reports they were released
> Maybe the issue is caused by the fact you haven't drop the staging repo?
> (I usually drop staging repo while "Release" process)

I tried twice. On Thursday I optimistically dropped the staging repository. 
However then I had no clue what happened. Thus on Saturday I kept the repo as 
a proof that the error isn't between "my chair and keyboard". 

-jt

> On Sun, 2 Dec 2018 at 11:44, Jaroslav Tulach 
> > I also tried to release the bits on Maven Central, but I hit a problem:
> > 
> > https://issues.apache.org/jira/browse/INFRA-17347
> > 
> > as a result of that the Maven bits are only available from
> > 
> > https://repository.apache.org/content/repositories/releases/
> > 
> > repository as
> > https://repository.apache.org/content/repositories/releases/org/
> > netbeans/html/net.java.html.boot.fx/1.6/
> > <https://repository.apache.org/content/repositories/releases/org/netbeans/
> > html/net.java.html.boot.fx/1.6/> & co.
> > 
> > I hope we find a way to propagate them to Maven central. Thanks you all
> > for
> > your never-ending support of Apache NetBeans (incubating) project!
> > -jt




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [RESULT] [VOTE] Release 1.6 of NetBeans HTML/Java API

[Jaroslav Tulach]

Hi.
I the vote had been successfully closed and as such I uploaded the bits to:

https://dist.apache.org/repos/dist/release/incubator/netbeans/incubating-netbeans-html4j/incubating-netbeans-html4j-1.6/

I also tried to release the bits on Maven Central, but I hit a problem:

https://issues.apache.org/jira/browse/INFRA-17347

as a result of that the Maven bits are only available from

https://repository.apache.org/content/repositories/releases/

repository as https://repository.apache.org/content/repositories/releases/org/
netbeans/html/net.java.html.boot.fx/1.6/ & co.

I hope we find a way to propagate them to Maven central. Thanks you all for 
your never-ending support of Apache NetBeans (incubating) project!
-jt


Dne úterý 27. listopadu 2018 6:10:18 CET, Jaroslav Tulach napsal(a):
> On 2018/11/23 17:36:27, Jaroslav Tulach  wrote:
> > Thank you Justin and Ate for your votes. Now we are +2 binding, but I
> > guess
> > I still need one more, right?
> > Anyone else willing to cast another  +1 binding vote?>
> 
> Bertrand voted +1 on Monday.
> 
> Votes by Justin, Ate and Bertrand make me believe the release 1.6 of
> NetBeans HTML/Java API has been approved. I perform necessary release
> actions over the weekend.
> 
> Thank you for your reviews.
> -jt
> 
> > I've reported https://issues.apache.org/jira/browse/NETBEANS-1739 to track
> 
> the >
> 
> > issues found by Justin. I'll keep that in mind and fix it by next release.
> > > Thanks for the findings.>
> > 
> > -jt>
> > 
> > On 2018/11/21 05:00:56, Justin Mclean  wrote: >
> > 
> > > Hi,> >
> > > 
> > > +1 binding but there’s a LICENSE issue than needs to be fixed in the
> > > next
> > 
> > release.> >
> > 
> > > I checkered:> >
> > > - incubating in name> >
> > > - signatures and hashes correct> >
> > > - DISCLAIMER exists (although name of the project inside is a little
> > > odd)>
> > > 
> > > - LICENSE and NOTICE have a few minor issues (see below)> >
> > > - No unexpected binary files> >
> > > - All ASF file have ASF headers> >
> > > - Can compile from source> >
> > > 
> > > The tests also passed.> >
> > > 
> > > The NOTICE copyright year is “2017-2017” that should be 2017-2018
> > > right?>
> > > 
> > > 
> > > The LICENSE is missing mention of (and license text) of MIT licensed >
> > 
> > Knockout [1]> >
> > 
> > > Thanks,> >
> > > Justin> >
> > > 
> > > 1. incubator-netbeans-html4j/ko4j/src/main/resources/org/netbeans/html/
> 
> ko4j/>
> 
> > knockout-3.4.0.js> >
> > 
> > > -> >
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org> >
> > > For additional commands, e-mail: general-h...@incubator.apache.org> >
> > 
> > ->
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org>
> > For additional commands, e-mail: general-h...@incubator.apache.org>





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [RESULT] Release 1.6 of NetBeans HTML/Java API

[Jaroslav Tulach]

On 2018/11/23 17:36:27, Jaroslav Tulach  wrote: 
> Thank you Justin and Ate for your votes. Now we are +2 binding, but I guess
> I still need one more, right? 
> Anyone else willing to cast another  +1 binding vote?> 

Bertrand voted +1 on Monday.

Votes by Justin, Ate and Bertrand make me believe the release 1.6 of NetBeans 
HTML/Java API has been approved. I perform necessary release actions over the 
weekend.

Thank you for your reviews.
-jt

> I've reported https://issues.apache.org/jira/browse/NETBEANS-1739 to track 
the > 
> issues found by Justin. I'll keep that in mind and fix it by next release. > 
> Thanks for the findings.> 
> 
> -jt> 
> 
> On 2018/11/21 05:00:56, Justin Mclean  wrote: > 
> > Hi,> > 
> > > 
> > +1 binding but there’s a LICENSE issue than needs to be fixed in the next 
> 
> release.> > 
> > > 
> > I checkered:> > 
> > - incubating in name> > 
> > - signatures and hashes correct> > 
> > - DISCLAIMER exists (although name of the project inside is a little odd)> 
> 
> > - LICENSE and NOTICE have a few minor issues (see below)> > 
> > - No unexpected binary files> > 
> > - All ASF file have ASF headers> > 
> > - Can compile from source> > 
> > > 
> > The tests also passed.> > 
> > > 
> > The NOTICE copyright year is “2017-2017” that should be 2017-2018 right?> 
> 
> > > 
> > The LICENSE is missing mention of (and license text) of MIT licensed > 
> Knockout [1]> > 
> > > 
> > Thanks,> > 
> > Justin> > 
> > > 
> > 1. incubator-netbeans-html4j/ko4j/src/main/resources/org/netbeans/html/
ko4j/> 
> knockout-3.4.0.js> > 
> > > 
> > > 
> > > 
> > > 
> > -> > 
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org> > 
> > For additional commands, e-mail: general-h...@incubator.apache.org> > 
> > > 
> > > 
> 
> 
> 
> -> 
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org> 
> For additional commands, e-mail: general-h...@incubator.apache.org> 
> 
> 



-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

72h was: 10-vc5

[Jaroslav Tulach]

Dne sobota 24. listopadu 2018 19:52:02 CET, Matthias Bläsing napsal(a):
> Hi,
> 
> Am Samstag, den 24.11.2018, 10:35 -0800 schrieb Laszlo Kishalmi:
> > Hi all PR-973 broke HTML5, PHP. Going to revert the patch from
> > release100
> 
> please wait and give Svatopluk some time to react - else I see the next
> one voting -1 because the old Javascript parser is bundled (with GPLv2-
> CPE license...)

The usual Apache deadline is 72h. It would be good to slow down before 
accepting/removing PRs and going back and forth in circles.

-jt

PS: I'd like to also see NetBeans 10 released on Dec 10 or sooner, but we 
won't get there if we start to panic.




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

NetBeans - the UI for Maven

[Jaroslav Tulach]

Hi guys,
the Apache NetBeans release 10 is (almost) finished and ready for download. 
Time to look forward: Long live Apache NetBeans - the UI for Apache Maven!

NetBeans is known for its excellent Maven support. Time to bring it to new 
level - time to lead all NetBeans newbies directly into Maven hands:

Whenever one creates new Java project from scratch a Maven project should be 
created.

Currently the default project type is Ant based, but as Jesse Glick (the 
author of the Ant based projects integration) once asked: "Is anybody still 
using that!?" That is the question! Newcomers use it, but otherwise it is 
useless dead end road. Starting new Ant based project in a year 2018 is a 
nonsence!

The current duality of Ant/Maven project support also wastes precious NetBeans 
development resources - features are usually implemented for Ant based 
projects first and only then ported to Maven. That's misfocused and upside 
down. 

Let's make the switch and offer Maven projects by default. Maven is well 
suited for the task: it is standard, well adopted build system. Maven comes 
with project archetypes that will serve as great starting templates for our 
newly generated project. 

What will change? Not the code, but the presentation: When one invokes "New 
Project" in NetBeans 11, there should be:

Java:
  - Java Application
  - Java Frontend Application
  - Project from Archetype
  - POM Project
  - NetBeans Application

Ant(ic)/Java:
  - Java Free-Form Project
  - Java Modular Project
  - Java Project with Existing Sources
  - Java Class Library
  - Java Application

Ant(ic)/JavaFX:
  - JavaFX Application
  - JavaFX Preloader
  - JavaFX FXML Application
  - JavaFX in Swing Application
  - JavaFX Project with Existing Sources

Ant(ic)/NetBeans Modules:
  - Module
  - Module Suite
  - Library Wrapper Module
  - NetBeans Platform Application

PHP:
  // unchanged

HTML5/JavaScript:
  // unchanged


The "Java" category will offer only Maven based projects. I hope this change 
will be welcomed by NetBeans as well as Maven supporters and will help Apache 
NetBeans to move forward and focus on support of technology that matters!

Best regards and thanks in advance for your support.
Jaroslav Tulach
NetBeans founder & initial architect




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [VOTE] Release Apache Netbeans 10.0 (incubating) [vote candidate 4]

[Jaroslav Tulach]

-1

We shouldn't attempt to release with known blockers. The installation of
GPL code without a confirmation (e.g. NETBEANS-1733) is a blocker. I'll fix
it over the weekend.
The presence of Nashorn parser code (reported as NETBEANS-1159) taken from
JDK8  - e.g. licensed under GPLwCP - is a blocker in my opinion too:

$ unzip -v incubating-netbeans-10.0-vc4-bin.zip | grep js.parser
  278471  Defl:N   260484   7% 2018-11-21 18:36 8ab5b536
netbeans/webcommon/modules/ext/com.oracle.js.parser.jar

On a general note: What is the process of identifying blockers? Being
around and vote "-1" every time somebody calls for a vote? Wouldn't it be
better to have a query into JIRA to locate the blockers as (open) high
priority issues? At least NetBeans were doing that before the move to
Apache...
-jt

čt 22. 11. 2018 v 7:02 odesílatel Jan Lahoda  napsal:

> I wonder if (when we are doing new votes) we should consider cherrypicking
> some other stuff, like:
> https://github.com/apache/incubator-netbeans/pull/973
>
> Jan
>
> On Thu, Nov 22, 2018 at 12:50 AM Laszlo Kishalmi <
> laszlo.kisha...@gmail.com>
> wrote:
>
> > Dear all,
> >
> > This is our 4th voting candidate for the 10.0 release of Apache NetBeans.
> > The content of this voting candidate is the same as the previous voting
> > candidate 3, the only difference is the accidentally included binaries
> got
> > removed (with some build script modifications).
> > See more at: https://issues.apache.org/jira/browse/NETBEANS-1719
> >
> > Apache NetBeans 10.0 (incubating) constitutes all but the enterprise
> > cluster in the Apache NetBeans Git repo, which together provide the
> > NetBeans Platform (i.e., the underlying application framework), as well
> as
> > all the modules that provide the Java SE, PHP, JavaScript and Groovy
> > features of Apache NetBeans.
> >
> > In short, Apache NetBeans 10.0 (incubating) is a full IDE for Java SE,
> PHP
> > and JavaScript development with some Groovy language support.
> >
> > Build artifacts available here:
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-10.0-vc4/
> >
> > Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and
> > NOTICE files, as well as a README file with build instructions, which are
> > the same as these:
> >
> > https://github.com/apache/incubator-netbeans/blob/release100/README.md
> >
> > SHA1: 028b47ca10118e616208e4949fb79c2e38d74fd5
> >
> > KEYS file:
> >
> > https://dist.apache.org/repos/dist/release/incubator/netbeans/KEYS
> >
> > Apache NetBeans Git Repo tag: 10.0-vc4 :
> > https://github.com/apache/incubator-netbeans/tree/10.0-vc4
> >
> > Note: NetBeans license violation checks are managed via the
> > rat-exclusions.txt file:
> >
> >
> >
> https://github.com/apache/incubator-netbeans/blob/release100/nbbuild/rat-exclusions.txt
> >
> > Rat report shows no unknown licenses, except for license files:
> >
> >
> >
> https://builds.apache.org/job/incubator-netbeans-release/370/artifact/rat-release-temp/nbbuild/build/rat-report.txt
> >
> > Included as a convenience binary, not relevant for the voting purposes
> > (unzip it, run it and you'll see Apache NetBeans):
> >
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-10.0-vc4/incubating-netbeans-10.0-vc4-bin.zip
> >
> > Release specific wiki page:
> >
> > https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+10
> >
> > How (and what) to try out the release:
> >
> > 1. Download the artifact to be voted on and unzip it.
> > 2. Check that the artifact does not contain any jar files,
> > save the:
> >
> platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/empty.jar
> > 3. Verify the cryptographic signatures, the NOTICE and LICENSE file
> > 4. Build it using the README provided by the artifact.
> > 5. Look in nbbuild/netbeans for the NetBeans installation created by the
> > build process.
> >
> >
>

[RESULT]: [VOTE] Release Apache NetBeans HTML/Java API version 1.6 (2nd attempt)

[Jaroslav Tulach]

+3

Thanks a lot Junichi, John and Jan for verification and testing. Now is
time to pass the vote to IPMC. I'll do that in a separate email.

> BTW, I came across the following error but I'm not sure whether it is a
problem:
> Configuring TestNG with: TestNG652Configurator
> java.lang.Exception: Error
> at
org.netbeans.html.json.impl.OnReceiveTest.performErrorJSONCallNoHandling(OnReceiveTest.java:64)

There is a test that checks behavior of a broken connection to a REST end
point and logs the problem to System.err. Thus the error is logged, but
then it is properly processed. I've reported myself a bug to track it:
https://issues.apache.org/jira/browse/NETBEANS-1703

čt 15. 11. 2018 v 21:06 odesílatel Jan Lahoda  napsal:

> +1
>
> I was looking at incubating-netbeans-html4j-1.6.zip, SHA1 sum
> 46b8679e780d2dc07927f23dba1deefd557ea7af. The hash matches, looking at the
> mandatory files, looks OK. Maybe NOTICE should have 2017-2018 as copyright
>

Yes, it should. Hopefully it can pass the vote anyway. I promise to make
sure it is increased by two to 2019 when publishing the next release.

Thank you all for your testing.
-jt


> years? I can build. I've seen the same exception as Junichi during the
> build, but the build passes.
>
> Jan
>
> On Sat, Nov 10, 2018 at 6:21 PM Jaroslav Tulach  >
> wrote:
>
> > Dear members of the Apache NetBeans community.
> > I have prepared second attempt of HTML/Java 1.6 bits and uploaded them
> > to [Apache Nexus](https://repository.apache.org/) staging repository.
> > The upload is the final piece in the whole HTML/Java API donation
> process -
> > it was only possible now, when the netbeans.org domain (and thus
> > org.netbeans.html groupId) has been donated to Apache Foundation.
> >
> > To finish the whole process, I am calling for a vote on Apache NetBeans
> > HTML/Java 1.6 release. The release is staged at
> >
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-html4j/incubating-netbeans-html4j-1.6/
> >
> > In addition to that the Maven artifacts built from the same changeset
> > [release-1.6](
> > https://github.com/apache/incubator-netbeans-html4j/tree/release-1.6)
> > are available at the following staging repository:
> >
> >
> https://repository.apache.org/content/repositories/orgapachenetbeans-1002/
> >
> > Please do some testing and cast your vote by Tuesday Nov 13, 2018. Thanks
> > for your support.
> > -jt
> >
> > PS: This release of HTML/Java API doesn't influence release 10 of Apache
> > NetBeans in any way
> > PPS: You can test the Maven bits by adding following snippet (with
> > appropriate XML closing tags) to your $HOME/.m2/settings.xml file:
> >
> > 
> > http://maven.apache.org/SETTINGS/1.0.0;
> > xmlns:xsi="
> > http://www.w3.org/2001/XMLSchema-instance;
> >   xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> > http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> > 
> > 
> > 
> > 
> > .
> > 
> > 
> > 
> > 
> > html-java-api-1.6
> > 
> >
> >
> https://repository.apache.org/content/repositories/orgapachenetbeans-1002/
> > 
> > 
> > 
> > 
> > 
> > html-java-api-1.6
> > 
> >
> >
> https://repository.apache.org/content/repositories/orgapachenetbeans-1002/
> > 
> > 
> > 
> > 
> >
>

Re: How important is OSGi support?

[Jaroslav Tulach]

ne 11. 11. 2018 v 20:34 odesílatel Emilian Bold 
napsal:

> > There are two OSGi containers in NetBeans. Felix and Netbinox. The
> platform
> can use any of them. IDE uses Netbinox (as for example Mylyn bundles do not
> run on Felix).
>
> Netbinox being a patched Equinox.
>
> So, if the IDE uses Equinox (or, Netbinox), why do we bundle Felix
> for? I case some other Platform application prefers the Felix OSGi
> runtime? (In which case the OSGi part of the IDE will run in Felix, I
> assume? Or, are we advanced enough that we can bridge between multiple
> OSGi containers at the same time?).
>

No, we cannot (currently) bridge between multiple OSGi containers.
Interesting idea ;-), but no.

The short answer is Felix was first, then we also needed Netbinox. More
resources:

http://wiki.apidesign.org/wiki/Netbinox
http://wiki.apidesign.org/wiki/Mylyn
http://wiki.apidesign.org/wiki/JDeveloper
http://wiki.apidesign.org/wiki/Felix

-jt


>
> --emi
> On Sun, Nov 11, 2018 at 9:13 AM Jaroslav Tulach
>  wrote:
> >
> > There are two OSGi containers in NetBeans. Felix and Netbinox. The
> platform
> > can use any of them. IDE uses Netbinox (as for example Mylyn bundles do
> not
> > run on Felix).
> >
> > Updating containers is a matter of replacing the JARs and passing all the
> > module tests.
> > -jt
> >
> >
> > so 10. 11. 2018 v 13:29 odesílatel Neil C Smith 
> > napsal:
> >
> > > On Sat, 10 Nov 2018 at 09:35, Emilian Bold 
> wrote:
> > > > Having a hybrid module system is a neat trick yet I don't see people
> > > > raving about it. I wonder if it wouldn't help simplify this long
> term.
> > >
> > > How does all this relate to things like this, and the comments about
> > > using third-party libraries as OSGi bundles directly?  Are we sure
> > > this isn't impacting any IDE functionality?
> > >
> > >
> > >
> https://github.com/apache/incubator-netbeans/commit/0733bfa50a2ab70c06f3c3b65067a6f0276de801#diff-b67e908d5abd92c256d46d7b1edf5ae5
> > >
> > > On Sat, 10 Nov 2018 at 12:06, Oliver Rettig 
> wrote:
> > > > what are the features we will lost, if we use OSGI? Are the features
> we
> > > can win with OSGI?
> > > > Maybe we can start a wiki page to collect the things.
> > >
> > > There are quite a few pages on OSGi <> NetBeans features and interop
> > > on the old wiki.  I'm not sure how much has been migrated there as
> > > yet.
> > >
> > > The page on NBM package stability has some interesting observations on
> > > this, and links across to some other useful things -
> > > http://wiki.netbeans.org/NbmPackageStability
> > >
> > > Best wishes,
> > >
> > > Neil
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> > > For additional commands, e-mail:
> dev-h...@netbeans.incubator.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.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: How important is OSGi support?

[Jaroslav Tulach]

There are two OSGi containers in NetBeans. Felix and Netbinox. The platform
can use any of them. IDE uses Netbinox (as for example Mylyn bundles do not
run on Felix).

Updating containers is a matter of replacing the JARs and passing all the
module tests.
-jt


so 10. 11. 2018 v 13:29 odesílatel Neil C Smith 
napsal:

> On Sat, 10 Nov 2018 at 09:35, Emilian Bold  wrote:
> > Having a hybrid module system is a neat trick yet I don't see people
> > raving about it. I wonder if it wouldn't help simplify this long term.
>
> How does all this relate to things like this, and the comments about
> using third-party libraries as OSGi bundles directly?  Are we sure
> this isn't impacting any IDE functionality?
>
>
> https://github.com/apache/incubator-netbeans/commit/0733bfa50a2ab70c06f3c3b65067a6f0276de801#diff-b67e908d5abd92c256d46d7b1edf5ae5
>
> On Sat, 10 Nov 2018 at 12:06, Oliver Rettig  wrote:
> > what are the features we will lost, if we use OSGI? Are the features we
> can win with OSGI?
> > Maybe we can start a wiki page to collect the things.
>
> There are quite a few pages on OSGi <> NetBeans features and interop
> on the old wiki.  I'm not sure how much has been migrated there as
> yet.
>
> The page on NBM package stability has some interesting observations on
> this, and links across to some other useful things -
> http://wiki.netbeans.org/NbmPackageStability
>
> Best wishes,
>
> Neil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: [VOTE] Release Apache Netbeans 10.0 (incubating) [vote candidate 3]

[Jaroslav Tulach]

+1
It works fine for me.
-jt


čt 8. 11. 2018 v 18:56 odesílatel Ludovic HOCHET  napsal:

> +1
> Thanks for the Windows launcher fix.
>
> Le mar. 6 nov. 2018 à 07:50, Laszlo Kishalmi  a
> écrit :
>
> > Hi all,
> >
> > Please vote on releasing Apache NetBeans 10.0 (incubating)!
> >
> > If this voting candidate passes, another similar voting will be started
> > ongene...@incubator.apache.org, and if that passes too, then we can
> > release this version. This build will also undergo validation through
> > NetCAT.
> >
> > Apache NetBeans 10.0 (incubating) constitutes all but the enterprise
> > cluster in the Apache NetBeans Git repo, which together provide the
> > NetBeans Platform (i.e., the underlying application framework), as well
> as
> > all the modules that provide the Java SE, PHP, JavaScript and Groovy
> > features of Apache NetBeans.
> >
> > In short, Apache NetBeans 10.0 (incubating) is a full IDE for Java SE and
> > PHP, JavaScript development with some Groovy language support.
> >
> > Build artifacts available here:
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-10.0-vc3
> >
> > The specific artifact to be voted on:
> >
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-10.0-vc3/incubating-netbeans-10.0-vc3-source.zip
> >
> > Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and
> > NOTICE files, as well as a README file with build instructions, which are
> > the same as these:
> >
> > https://github.com/apache/incubator-netbeans/blob/release100/README.md
> >
> > SHA1: 028b47ca10118e616208e4949fb79c2e38d74fd5
> >
> > KEYS file:
> >
> > https://dist.apache.org/repos/dist/release/incubator/netbeans/KEYS
> >
> > Apache NetBeans Git Repo tag: 10.0-vc3 :
> >
> > https://github.com/apache/incubator-netbeans/tree/10.0-vc3
> >
> > Note: NetBeans license violation checks are managed via the
> > rat-exclusions.txt file:
> >
> >
> >
> https://github.com/apache/incubator-netbeans/blob/release100/nbbuild/rat-exclusions.txt
> >
> > Rat report shows no unknown licenses, except for license files:
> >
> >
> >
> https://builds.apache.org/job/incubator-netbeans-release/365/artifact/rat-release-temp/nbbuild/build/rat-report.txt
> >
> > Included as a convenience binary, not relevant for the voting purposes
> > (unzip it, run it and you'll see Apache NetBeans):
> >
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-10.0-vc3/incubating-netbeans-10.0-vc1-bin.zip
> >
> >
> >
> > Release specific wiki page:
> >
> > https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+10
> >
> > How (and what) to try out the release:
> >
> > 1. Download the artifact to be voted on and unzip it.
> > 2. Verify the cryptographic signatures, the NOTICE and LICENSE file
> > 3. Build it using the README provided by the artifact.
> > 4. Look in nbbuild/netbeans for the NetBeans installation created by the
> > build process.
> >
> >
> > If the above succeeds, i.e., Apache NetBeans installs and starts up vote
> > +1 in this thread.
> >
> > Note that according tohttp://
> > www.apache.org/legal/release-policy.html#release-approval  :
> >
> > > Before casting +1 binding votes, individuals are REQUIRED to download
> all
> > > signed source code packages onto their own hardware, verify that they
> > meet
> > > all requirements of ASF policy on releases as described below, validate
> > all
> > > cryptographic signatures, compile as provided, and test the result on
> > their
> > > own platform.
> > Please try out the package, using the instructions above, and vote! The
> > vote is open for a minimum of 72 hours or until the necessary number of
> > votes (3 binding +1s) is reached.
> >
> > [ ] +1 Release this package as Apache NetBeans 10.0 (incubating)
> > [ ] 0 I don't feel strongly about it, but I'm okay with the release
> > [ ] -1 Do not release this package because...
> >
> > Please add "(binding)" if your vote is binding, i.e., you are an Apache
> > NetBeans PPMC member, i.e., your name is on this page:
> > http://home.apache.org/committers-by-project.html#netbeans , although
> > note the only real binding votes in the incubator are those of the IPMC,
> > i.e., in the next vote thread, after this one passes.
> >
> > Laszlo Kishalmi
> > on behalf of the Apache NetBeans PPMC
> >
>

[VOTE] Release Apache NetBeans HTML/Java API version 1.6 (2nd attempt)

[Jaroslav Tulach]

Dear members of the Apache NetBeans community.
I have prepared second attempt of HTML/Java 1.6 bits and uploaded them
to [Apache Nexus](https://repository.apache.org/) staging repository.
The upload is the final piece in the whole HTML/Java API donation process -
it was only possible now, when the netbeans.org domain (and thus
org.netbeans.html groupId) has been donated to Apache Foundation.

To finish the whole process, I am calling for a vote on Apache NetBeans
HTML/Java 1.6 release. The release is staged at

https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-html4j/incubating-netbeans-html4j-1.6/

In addition to that the Maven artifacts built from the same changeset
[release-1.6](
https://github.com/apache/incubator-netbeans-html4j/tree/release-1.6)
are available at the following staging repository:

https://repository.apache.org/content/repositories/orgapachenetbeans-1002/

Please do some testing and cast your vote by Tuesday Nov 13, 2018. Thanks
for your support.
-jt

PS: This release of HTML/Java API doesn't influence release 10 of Apache
NetBeans in any way
PPS: You can test the Maven bits by adding following snippet (with
appropriate XML closing tags) to your $HOME/.m2/settings.xml file:


http://maven.apache.org/SETTINGS/1.0.0; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;>




.




html-java-api-1.6


https://repository.apache.org/content/repositories/orgapachenetbeans-1002/





html-java-api-1.6


https://repository.apache.org/content/repositories/orgapachenetbeans-1002/

[REJECTED] Release Apache NetBeans HTML/Java API version 1.6

[Jaroslav Tulach]

OK, the proposed bits are rejected then. I'll prepare new ones and initiate
new vote. Thanks for testing.
-jt

út 6. 11. 2018 v 8:09 odesílatel Anton Epple 
napsal:

> -1 In the meantime I had some failing tests when testing with dukescript
> presenters and I confirmed with Jaroslav that the issue is in the proposed
> 1.6 release
>
> Toni
>
>
>
> Am 04.11.18, 16:05 schrieb "Anton Epple" :
>
> +1
>
> Tested running with DukeScript Demos Project (
> https://github.com/dukescript/dukescript-demos)
>
> All 5 Demos build fine. I tested running 5 of them with WebView
> Presenter and one with bck2brwsr without any problems.
>
> Thanks for the great work!
>
> Toni
>
> Am 04.11.18, 08:27 schrieb "Jaroslav Tulach" <
> jaroslav.tul...@gmail.com>:
>
> Dear members of Apache NetBeans community.
> I have finally found some spare time and managed to upload
> HTML/Java API
> bits to [Apache Nexus](https://repository.apache.org/) staging
> repository.
> The upload is the final piece in the whole HTML/Java API donation
> process -
> it was only possible now, when the netbeans.org domain (and thus
> org.netbeans.html groupId) has been donated to Apache Foundation.
>
> To finish the whole process, I am calling for a vote on Apache
> NetBeans
> HTML/Java 1.6 release. The release is staged at
>
>
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-html4j/incubating-netbeans-html4j-1.6/
>
> In addition to that the Maven artifacts built from the same
> changeset
> [release-1.6](
>
> https://github.com/apache/incubator-netbeans-html4j/tree/release-1.6)
> are available at the following staging repository:
>
>
> https://repository.apache.org/content/repositories/orgapachenetbeans-1001/
>
> Please do some testing and cast your vote by Wednesday Nov 7,
> 2018. Thanks
> for your support.
> -jt
>
> PS: This release of HTML/Java API doesn't influence release 10 of
> Apache
> NetBeans in any way
> PPS: You can test the Maven bits by adding following snippet (with
> appropriate XML closing tags) to your $HOME/.m2/settings.xml file:
>
> 
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> 
> 
> 
> 
> .
> 
> 
> 
> 
> html-java-api-1.6
> 
>
> https://repository.apache.org/content/repositories/orgapachenetbeans-1001/
> 
> 
> 
> 
> 
> html-java-api-1.6
> 
>
> https://repository.apache.org/content/repositories/orgapachenetbeans-1001/
> 
> 
> 
> 
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail:
> dev-h...@netbeans.incubator.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.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

[VOTE] Release Apache NetBeans HTML/Java API version 1.6

[Jaroslav Tulach]

Dear members of Apache NetBeans community.
I have finally found some spare time and managed to upload HTML/Java API
bits to [Apache Nexus](https://repository.apache.org/) staging repository.
The upload is the final piece in the whole HTML/Java API donation process -
it was only possible now, when the netbeans.org domain (and thus
org.netbeans.html groupId) has been donated to Apache Foundation.

To finish the whole process, I am calling for a vote on Apache NetBeans
HTML/Java 1.6 release. The release is staged at

https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-html4j/incubating-netbeans-html4j-1.6/

In addition to that the Maven artifacts built from the same changeset
[release-1.6](
https://github.com/apache/incubator-netbeans-html4j/tree/release-1.6)
are available at the following staging repository:

https://repository.apache.org/content/repositories/orgapachenetbeans-1001/

Please do some testing and cast your vote by Wednesday Nov 7, 2018. Thanks
for your support.
-jt

PS: This release of HTML/Java API doesn't influence release 10 of Apache
NetBeans in any way
PPS: You can test the Maven bits by adding following snippet (with
appropriate XML closing tags) to your $HOME/.m2/settings.xml file:


http://maven.apache.org/SETTINGS/1.0.0; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;>




.




html-java-api-1.6

https://repository.apache.org/content/repositories/orgapachenetbeans-1001/





html-java-api-1.6

https://repository.apache.org/content/repositories/orgapachenetbeans-1001/

Re: [Mentors] Removing old vote candidate bits?

[Jaroslav Tulach]

Right now the staging area occupies 6.5GB...
-jt


ne 4. 11. 2018 v 7:35 odesílatel Jaroslav Tulach 
napsal:

> Hi.
> I've noticed that there is a significant amount of binaries in the SVM
> staging area at https://dist.apache.org/repos/dist/dev/incubator/netbeans/
> - I am trying to upload new bits in there, but running `svm update` takes
> half an hour right now and is hardly in the middle. Here is the list of
> directories in the staging area that I find superfluous:
>
> incubating-netbeans-java
>
>- incubating-9.0-beta/
>
> <https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-beta/>
>- incubating-9.0-beta-rc2/
>
> <https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-beta-rc2/>
>- incubating-9.0-beta-rc3/
>
> <https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-beta-rc3/>
>- incubating-9.0-rc1-rc1/
>
> <https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-rc1-rc1/>
>- incubating-9.0-vc1/
>
> <https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-vc1/>
>- incubating-9.0-vc2/
>
> <https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-vc2/>
>- incubating-9.0-vc3/
>
> <https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-vc3/>
>
> incubating-netbeans-platform
>
>- incubating-9.0-beta/
>
> <https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-platform/incubating-9.0-beta/>
>- incubating-9.0-beta-rc2/
>
> <https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-platform/incubating-9.0-beta-rc2/>
>- incubating-9.0-beta-rc3/
>
> <https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-platform/incubating-9.0-beta-rc3/>
>- incubating-9.0-rc1-rc1/
>
> <https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-platform/incubating-9.0-rc1-rc1/>
>- incubating-9.0-vc1/
>
> <https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-platform/incubating-9.0-vc1/>
>- incubating-9.0-vc2/
>
> <https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-platform/incubating-9.0-vc2/>
>- incubating-9.0-vc3/
>
> <https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-platform/incubating-9.0-vc3/>
>
> nothing against keeping 10.0-vcX in there until it is approved and moved
> to release area at
> https://dist.apache.org/repos/dist/release/incubator/netbeans/, but
> keeping there the old 9.0-vcX just complicates working with the staging
> directory.
> Shouldn't they be removed?
>
> What is the Apache policy, dear mentors? Remove? Keep? Thanks.
> -jt
>
>

[Mentors] Removing old vote candidate bits?

[Jaroslav Tulach]

Hi.
I've noticed that there is a significant amount of binaries in the SVM
staging area at https://dist.apache.org/repos/dist/dev/incubator/netbeans/
- I am trying to upload new bits in there, but running `svm update` takes
half an hour right now and is hardly in the middle. Here is the list of
directories in the staging area that I find superfluous:

incubating-netbeans-java

   - incubating-9.0-beta/
   

   - incubating-9.0-beta-rc2/
   

   - incubating-9.0-beta-rc3/
   

   - incubating-9.0-rc1-rc1/
   

   - incubating-9.0-vc1/
   

   - incubating-9.0-vc2/
   

   - incubating-9.0-vc3/
   


incubating-netbeans-platform

   - incubating-9.0-beta/
   

   - incubating-9.0-beta-rc2/
   

   - incubating-9.0-beta-rc3/
   

   - incubating-9.0-rc1-rc1/
   

   - incubating-9.0-vc1/
   

   - incubating-9.0-vc2/
   

   - incubating-9.0-vc3/
   


nothing against keeping 10.0-vcX in there until it is approved and moved to
release area at
https://dist.apache.org/repos/dist/release/incubator/netbeans/, but keeping
there the old 9.0-vcX just complicates working with the staging directory.
Shouldn't they be removed?

What is the Apache policy, dear mentors? Remove? Keep? Thanks.
-jt

NetBeans History Tour at GeeCON - Wed, Oct 17, 19.00

[Jaroslav Tulach]

There seems to be quite a lot of NetBeans supporters at incoming GeeCON in
Prague. As such:

Dear Apache NetBeans fans,
let's meet on Wed Oct 17, at 19.00 on Malostranské square:
https://mapy.cz/zakladni?x=14.4034410=50.0881222=18=stre=120483=malostransk%C3%A9%20n%C3%A1m%C4%9Bst%C3%AD
and let's do a little tour around Faculty of Mathematics and Physics where
NetBeans (at that time project Xelfi) was created. Then let's visit pub [U
bílé kuželky](http://lokal-ubilekuzelky.ambi.cz/) where the initial design
of NetBeans was lively discussed and shaped. Let's use this opportunity
for a meetup of former and new NetBeans maintainers.

Let's meet at 19.00 on the tram station (trams 12, 15, 20, 22 can be used
to get there). Be there at time - we can't delay the tour much, as at 19.30
we have to be in the pub [U bílé kuželky](http://lokal-ubilekuzelky.ambi.cz/
).
Who misses the tour can go directly to the pub. I did a reservation of few
places.

See you!
Jaroslav Tulach
NetBeans Founder and one of the initial Xelfi project students

Re: Pre-register 8.2 UC was: New InfoQ article on Apache NetBeans status

[Jaroslav Tulach]

Interesting idea. It solves the problem too. Maybe even in a better way.
-jt

Dne ne 19. 8. 2018 7:18 uživatel Jan Lahoda  napsal:

> On Fri, Aug 17, 2018 at 8:46 AM, Jaroslav Tulach <
> jaroslav.tul...@gmail.com>
> wrote:
>
> > Dne Pá 17. srpna 2018 07:51:34, Geertjan Wielenga napsal(a):
> > > I think the thinking was to not do this because it would create a false
> > > impression of those plugins being approved and verified for the 9.0
> > release.
> >
> > I see. Then I would suggest to pre-register the update center, but leave
> > it
> > disabled. Simpler to use, but clearly not part of the core release.
> >
>
> I wonder if we shouldn't upload the extra 8.2 plugins to plugin portal for
> 9.0?
>
> Jan
>
>
> > > However, I agree with you that, seeing as how many have been asking
> about
> > > this, it would help to do this.
> > >
> > > The question is, now that we have released, how do we do this update,
> > i.e.,
> > > after we make this change, how do we publish it?
> >
> > I was thinking about making the change in a daily build only. Then it
> > could be
> > tested and be ready for the next release.
> >
> > > We need a process for that
> > > so that we all know how to follow it.
> >
> > How do we release patches/updates to a release, that's the question! I
> > have no
> > answer right now. It certainly requires co-ordination with our AU catalog
> > URL
> > masters. It requires upload of new version of some NBM files somewhere.
> > Effectively it is a release (forked off the release90 branch?), possibly
> > without the main binary ZIP file...
> >
> > -jt
> >
> > > On Fri, Aug 17, 2018 at 7:39 AM, Jaroslav Tulach <
> > jaroslav.tul...@gmail.com>
> > > wrote:
> > > > Dne Čt 16. srpna 2018 09:15:37, Geertjan Wielenga napsal(a):
> > > > > https://www.infoq.com/news/2018/08/netbeans-apache-update-aug18
> > > >
> > > > I can see the continuing effort to explain "where have all the
> modules
> > > > gone?"
> > > > in the article. Rather than writing long blog posts with howtos, why
> > not
> > > > add
> > > > the 8.2 update center to the default installation?
> > > >
> > > > https://github.com/apache/incubator-netbeans/blob/
> > > > master/updatecenters/src/org/netbeans/modules/
> > updatecenters/resources/mf-
> > > > layer.xml
> > > >
> > > > https://github.com/apache/incubator-netbeans/blob/
> > > >
> master/updatecenters/src/org/netbeans/modules/updatecenters/resources/
> > > > Bundle.properties
> > > >
> > > > Just register new update center there, let it point to 8.2 catalog.
> > Either
> > > > disable it by default or even enable it by default. Then no URL
> copying
> > > > and
> > > > pasting will be needed to activate C, C++, JavaEE & co. and they will
> > be
> > > > seen
> > > > more as more natural part of the upcoming Apache NetBeans releases
> than
> > > > they
> > > > are right now.
> > > >
> > > > -jt
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail:
> dev-unsubscr...@netbeans.incubator.apache.org
> > > > For additional commands, e-mail: dev-help@netbeans.incubator.
> > 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.incubator.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>

Re: Heads up: #536: Per-cluster repository layout

[Jaroslav Tulach]

Thanks for your opinion, Tim.

Dne So 18. srpna 2018 21:11:13, Tim Boudreau napsal(a):
> Given that clusters occasionally get split, I'm not sure cluster is the
> right splitting criterion - it just cements the current layout in place.
> 
> If the problem being solved is just to make the github home page pretty,
> just moving the current root contents into a src/ directory would do the
> job.

True, that solves the root folder problem. However it still leaves us with a 
directory too big to be handled by GitHub. Splitting into cluster based 
subdirectories solves this second problem as well.

> The reason everything is flat was that we tried a hierarchical layout way
> back, and the practical consequence was that new developers had to
> constantly ask where things were. Many things straddle the line between
> general infrastructure and cluster specific stuff. Take, for example,
> simple.project.templates - it lets you define a project template with a
> properties file. It has friends that use it. It has nothing to do with
> javacard, but is part of the javacard cluster by accident of what first
> used it.

True, innovation can happen elsewhere. I know quite a lot of examples of good 
ideas being spread at various modules. Most of them share the same destiny: 
their authors never starved for turning them into official NetBeans APIs. 
Should there have been a will to make them official NetBeans API, the modules 
would probably end up in platform or ide clusters or they would get merged 
with existing, similar functionality providing modules.

> 
> Will someone who could benefit from it ever find it there?
> 
> In short, clusters are arbitrary. 

Clusters form the  distribution and functional unit of Apache NetBeans. With 
the introduction of ergonomics they are becoming quite visible even for end 
users. In no way I'd dare to call them arbitrary.

> Something more function-related would be
> more useful. Or just move it all down one folder and github will be pretty
> and maybe that's enough.
> 
> -1 from me.

I do remember the previous mess with subdirectories in our old CVS repository. 
The placement of modules was really arbitrary back then. I agree it used to be 
painful.

However that cannot be said about cluster based subdirectories - they provide 
a deterministic structure. The location of sources will actually match their 
final placement in the product. At the end it may actually be easier for 
developers to find the module they search for.

-jt

> On Sat, Aug 18, 2018 at 5:44 PM Junichi Yamamoto 
> 
> wrote:
> > > I know, I should write a wiki page howto.
> > 
> > +1
> > 
> > Thanks,
> > Junichi
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
> > 
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> > 
> > 
> > 
> > --
> 
> http://timboudreau.com


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Instructions to move modules to subclusters was: #536: Per-cluster repository layout

[Jaroslav Tulach]

Dne Ne 19. srpna 2018 06:44:24, Junichi Yamamoto napsal(a):
> > I know, I should write a wiki page howto.
> 
> +1

Here is a PR that can serve as a howto:
https://github.com/apache/incubator-netbeans/pull/719
Moving bigger clusters may not be as simple, but the core steps shall stay the 
same.
-jt


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: nb-javac source / signing

[Jaroslav Tulach]

Great questions and concerns, Neil.

> Also, what are the barriers to having nb-javac signed in such a way
> that it doesn't provoke a self-signed warning for NetBeans end users?

+10, the module should be properly signed!

Apache can't sign it itself. Somebody else has to. Currently Reema and co. do 
sign the module. I am fine with that, we just need to make sure it is 
recognized as regularly (e.g. not self) signed. There are two ways:

- Reema & co. can obtain signing certificate from an approved signing 
authority

- or we can take Reema & co. public key and add it to the list of trusted keys 
in the Apache NetBeans


> Not sure if I've missed some info somewhere, but is a source repo link
> and relevant tag for the nb-javac that users are prompted to install
> documented somewhere they (or I for that matter) can easily find? 

Instructions how to build nbjavac are desirable. It would be good if the 
repository URL and revision was part of the NBM or JAR file.

> Is
> it still at http://hg.netbeans.org/main/nb-javac ?  What revision /
> branch?  Specifically I'm personally looking at updating my IDE
> project to use NetBeans 9.0 but want to ship with nb-javac
> pre-included.

Download it from update center automatically with the autoupdate Ant task. 
That's what we do in Oracle Labs.


-jt


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Heads up: #536: Per-cluster repository layout

[Jaroslav Tulach]

Dne So 18. srpna 2018 13:30:28, Geertjan Wielenga napsal(a):
> Also, how would I build and run after git cloning
> https://github.com/apache/incubator-netbeans/tree/master/platform?

There is no way to clone a subtree in Git.

> 
> I.e., it would be great if there'd be a way to build and run the 'platform'
> root folder, i.e., I'd then have a very clear unit of features for building
> my platform applications on top of.

# this remained unchanged and can be built as usual:
nbbuild$ ant build-platform
# or
nbbuild$ ant -Dcluster.config=php build

> geertjan.wiele...@googlemail.com> wrote:
> > My key concern is now how can someone else take, for example, all the php
> > modules, and create a pull request to put them all into a root php folder?

I know, I should write a wiki page howto.
-jt


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Heads up: #536: Per-cluster repository layout

[Jaroslav Tulach]

Dear colleagues,
I am pushing PR-536 forward while I am on vacation and I am free to do what I 
love:

https://github.com/apache/incubator-netbeans/pull/536

I believe the goal of the change is sound: we want to cleanup the enormously 
large root directory to be GitHub & newcomers friendly. Structuring the source 
code per clusters is a natural way to do it. I've just updated the PR to 
reflect current changes in master. It is ready to be integrated.

On the other hand, this is just a first step towards the ultimate goal. The 
change only moves `platform` and `harness` modules. However I am afraid that 
next week I'll be forced to return back to my regular duties and I will not 
have the capacity to convert more clusters or to keep my branch up-to-date 
with further changes in the master branch. It is very painful to keep track 
with bigger master changes and merge files in different locations properly. As 
such I'd like to integrate just this part and leave the rest for later and for 
you guys. I hope Junichi will handle php, Jan Lahoda could do java cluster and 
hopefully I talk somebody into doing the ide cluster. Volunteers are indeed 
more than welcomed!

Once the change is integrated, you'll need Apache NetBeans 9.0 to work with 
the NetBeans sources. I assume that shouldn't be a problem - we all love to 
use the latest release, right?

Thanks for your contributions to Apache NetBeans and your support of this per-
cluster source re-organization change.

Jaroslav Tulach
NetBeans founder and initial architect


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Pre-register 8.2 UC was: New InfoQ article on Apache NetBeans status

[Jaroslav Tulach]

Dne Pá 17. srpna 2018 07:51:34, Geertjan Wielenga napsal(a):
> I think the thinking was to not do this because it would create a false
> impression of those plugins being approved and verified for the 9.0 release.

I see. Then I would suggest to pre-register the update center, but leave it 
disabled. Simpler to use, but clearly not part of the core release.

> However, I agree with you that, seeing as how many have been asking about
> this, it would help to do this.
> 
> The question is, now that we have released, how do we do this update, i.e.,
> after we make this change, how do we publish it? 

I was thinking about making the change in a daily build only. Then it could be 
tested and be ready for the next release.

> We need a process for that
> so that we all know how to follow it.

How do we release patches/updates to a release, that's the question! I have no 
answer right now. It certainly requires co-ordination with our AU catalog URL 
masters. It requires upload of new version of some NBM files somewhere. 
Effectively it is a release (forked off the release90 branch?), possibly 
without the main binary ZIP file...

-jt

> On Fri, Aug 17, 2018 at 7:39 AM, Jaroslav Tulach 
> wrote:
> > Dne Čt 16. srpna 2018 09:15:37, Geertjan Wielenga napsal(a):
> > > https://www.infoq.com/news/2018/08/netbeans-apache-update-aug18
> > 
> > I can see the continuing effort to explain "where have all the modules
> > gone?"
> > in the article. Rather than writing long blog posts with howtos, why not
> > add
> > the 8.2 update center to the default installation?
> > 
> > https://github.com/apache/incubator-netbeans/blob/
> > master/updatecenters/src/org/netbeans/modules/updatecenters/resources/mf-
> > layer.xml
> > 
> > https://github.com/apache/incubator-netbeans/blob/
> > master/updatecenters/src/org/netbeans/modules/updatecenters/resources/
> > Bundle.properties
> > 
> > Just register new update center there, let it point to 8.2 catalog. Either
> > disable it by default or even enable it by default. Then no URL copying
> > and
> > pasting will be needed to activate C, C++, JavaEE & co. and they will be
> > seen
> > more as more natural part of the upcoming Apache NetBeans releases than
> > they
> > are right now.
> > 
> > -jt
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Cleanup of old pending PRs

[Jaroslav Tulach]

Dne Pá 17. srpna 2018 06:30:28, Peter Steele napsal(a):
> So my thoughts on this would be to decide on a more formal PR approach and
> apply it to this situation

Great, that is what I am calling for!

Let's automatically close PRs that are silent for 60 days and more.

Simple. Formal. Well defined. Easy to understand and implement approach.
-jt


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Pre-register 8.2 UC was: New InfoQ article on Apache NetBeans status

[Jaroslav Tulach]

Dne Čt 16. srpna 2018 09:15:37, Geertjan Wielenga napsal(a):
> 
> https://www.infoq.com/news/2018/08/netbeans-apache-update-aug18
> 

I can see the continuing effort to explain "where have all the modules gone?" 
in the article. Rather than writing long blog posts with howtos, why not add 
the 8.2 update center to the default installation?

https://github.com/apache/incubator-netbeans/blob/master/updatecenters/src/org/netbeans/modules/updatecenters/resources/mf-layer.xml

https://github.com/apache/incubator-netbeans/blob/master/updatecenters/src/org/netbeans/modules/updatecenters/resources/Bundle.properties

Just register new update center there, let it point to 8.2 catalog. Either 
disable it by default or even enable it by default. Then no URL copying and 
pasting will be needed to activate C, C++, JavaEE & co. and they will be seen 
more as more natural part of the upcoming Apache NetBeans releases than they 
are right now.

-jt


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Cleanup of old pending PRs

[Jaroslav Tulach]

Hi.
I've noticed that there is few pull requests that haven't seen any activity in 
last forty seven days:

https://github.com/apache/incubator-netbeans/pulls?utf8=%E2%9C%93=is%3Apr+is%3Aopen+updated%3A%3C2018-06-01+-label%3Awork-in-progress+

Shouldn't there be some policy to close them automatically? Assuming there is 
a way to reopen them again, it should do no harm and would keep the list of 
open PR actual.

Best regards.
-jt


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Does Travis and/or Jenkins run the NetBeans test suite?

[Jaroslav Tulach]

FYI:
https://builds.apache.org/job/incubator-netbeans-linux/
and
https://builds.apache.org/job/incubator-netbeans-windows
run platform tests.

-jt


Dne neděle 15. července 2018 18:47:51 CEST, Eirik Bakke napsal(a):
> When I make a pull request on GitHub, there is a nice little checkmark
> saying "All checks have passed", with a link to a Travis CI build (e.g.
> https://travis-ci.org/apache/incubator-netbeans/builds/395547620?utm_source
> =github_status_medium=notification ).
> 
> Looking at the raw output of the Travis build, am I correct that this does
> _not_ actually run the NetBeans test suite? I searched the console output
> and did not find expected messages such as "Tests run:" or "do-junit" or
> "[junit]".
> 
> Is this also the case for the Jenkins builds at
> https://builds.apache.org/view/Incubator%20Projects/job/incubator-netbeans-> 
> release ?
> 
> Is the current codebase supposed to pass all tests at this point? When I
> check out the 9.0-vc3 tag, for instance, both of the following fail with
> various errors:
> 
> ant commit-validation
> ant -Dtest-unit-sys-prop.ignore.random.failures=true test
> 
> Are these supposed to work?
> 
> -- Eirik





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Public vs. Friend API?

[Jaroslav Tulach]

Dne sobota 14. července 2018 6:46:06 CEST, Tim Boudreau napsal(a):
> There are friend APIs in NetBeans that have not seen a single change in
> going on a decade.  All of those IMO, should simply get the "friend" label
> removed from them - if it hasn't changed in that long, it's clearly stable
> in every practical meaning of the word.  I'm just suggesting a way to make
> that automatic, 

Turn all current [Friend APIs](http://wiki.netbeans.org/API_Stability#Friend) 
into [Under development ones](http://wiki.netbeans.org/API_Stability#Devel).

Before you do the above change:
- [snapshot current APIs](http://wiki.netbeans.org/SignatureTest) of 9.0 
release
- make sure the build fails on an accidental change in such APIs

That's my 2 Kč suggestion.
-jt





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Indexing API change causing existing plugin to severely degrade performance

[Jaroslav Tulach]

Dne středa 6. června 2018 0:45:40 CEST, Jeffrey Morlan napsal(a):
> Hi,
> 
> I'm the author of the "nbts" TypeScript Editor plugin (
> http://plugins.netbeans.org/plugin/60605/typescript-editor,
> https://github.com/Everlaw/nbts).

Typescript plugin is (going to be) more and more important, I'd say! I am 
forwarding this message directly to Tomáš Zezula, the guy from #270667...

Tomáši, can you please look at Jeffrey's inquiry?
-jt


> 
> When I tested it in NetBeans 9.0 RC1, I saw major performance problems with
> saving files, due to the change made to indexing in
> https://netbeans.org/bugzilla/show_bug.cgi?id=270667. nbts needs to know
> about all .ts files in a source root, so I return false from
> CustomIndexerFactory#scanStarted - this used to only be applicable to the
> initial scan when the root is first opened, but now it also affects live
> changes. And on live changes, it affects ALL indexers! So, for example,
> saving one .java file would end up recompiling the whole project.
> 
> I'll fix this in the next version of nbts (diff:
> https://github.com/jeffreymorlan/nbts/commit/504f3dc6c7e721387b5597b66b0c0bc
> 6fa30440b). But, if someone using an existing version (<= 2.9.1.0) updates
> to NetBeans 9, they will get a severely degraded experience without the
> cause being obvious.
> 
> Does NetBeans have a plugin blacklist that can prevent old versions from
> being used?
> 
> (Also, was it really intentional that after the initial scan, scanStarted
> returning false affects unrelated indexers?)
> 
> Thanks
> Jeffrey





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Proposed plan for final release of 9.0

[Jaroslav Tulach]

> I.e., this means the idea is to not create an rc2 release, but instead to
> focus on the next release that we do to be the final release of 9.0.
>
>
This is a bit up-side-down, but given the way the system works, it is
probably correct. One does all the work and prepares the final bits and
uploads them to staging repository. The vote begins:
- when approved - the bits are made to public download area and the release
is announced.
- when rejected - the bits are removed and one tries again

As such +1 to fix the stoppers and prepare bits for 9.0 vote candidate.
-jt

Installations vs. users was: NetBeans celebrates 1.7 million active users

[Jaroslav Tulach]

2018-05-31 19:51 GMT+02:00 Jiří Kovalský :

>
> And how we calculate the numbers? We collect Apache log files from all
> download servers, parse them to extract entries when somebody downloaded
> catalog.xml.gz file i.e. Update Center which is by default scheduled to
> happen on a weekly basis and then store the records to database. Every GET
> request sends unique ID identifying single NetBeans installation which we
> then use to distinguish users from each other and if we identify the same
> ID in the DB twice in a month we increment the counter of unique active
> users. :)
>

One comment that I got on this approach is that this approach is not
counting the number of active users, but number of active installations.
The objection was that usually one user has two or more computers and we
have no way to attribute these usages to a single user.

-jt

PS: I have NetBeans installed on three computers that I use regularly.

Keeping the DNS in netbeans.org domain was: Upload Maven bits

[Jaroslav Tulach]

Hello Emilian,
I'd even argue that once netbeans.org domain gets transfered to Apache, it
is important (for the smoothness of migration) to keep DNS names of certain
IP addresses. For example

hg.netbeans.org
wiki.netbeans.org

shall in my opinion continue to work and point to the same machines, while
they are on. This shall not be done to save Apache any resources - all new
development of Apache NetBeans shall use Apache infrastructure, but these
old machines contain a lot of knowledge and keeping their DNS records helps
us to transfer the important parts of wisdom in an incremental fashion to
the proper Apache infrastructure.

-jt


2018-05-28 19:25 GMT+02:00 Emilian Bold :

> Considering there is no public Apache NetBeans 9 that users may freely
> download it might be a very good idea that netbeans.org is still under
> Oracle control and users at least get to see some download button with an
> installer. (I would also be curious to see, at least on private@ some
> statistics for that download button while we still can).
>
> Once we do have an Apache NetBeans 9 for users to download, including
> "convenience binaries" then we can say it makes perfect sense to want the
> whole netbeans.org domain too.
>
> --emi
>
> ‐‐‐ Original Message ‐‐‐
>
> On 28 May 2018 6:33 PM, Jaroslav Tulach  wrote:
>
> > Back to mailing list...
> >
> > Looks like my attempt to upload org.netbeans.html and other org.netbeans
> >
> > binaries to Maven repository hasn't succeeded. One of the reasons is that
> >
> > Oracle hasn't donated NetBeans trademark and netbeans.org domain to
> Apache
> >
> > yet. Surprising! I thought this was donated together with the 1st code
> >
> > donation. Obviously it wasn't. At least we (as Oracle employees) have
> >
> > something on to work on...
> >
> > 2018-05-16 20:38 GMT+02:00 Chris Lambertus (JIRA) j...@apache.org:
> >
> > > [ https://issues.apache.org/jira/browse/INFRA-16435?page=
> > >
> > >
> > > com.atlassian.jira.plugin.system.issuetabpanels:comment-
> > >
> > > tabpanel=16477884#comment-16477884 ]
> > >
> > > Chris Lambertus commented on INFRA-16435:
> > > -
> > >
> > > Per discussion with Joel Orlina/Brian Fox/Sonatype, the existing Infra
> > >
> > > tooling for repository.a.o apparently does not allow for the standard
> > >
> > > staging/release process for coordinates outside of org.apache. I do not
> > >
> > > know how those other artifacts are being pushed or managed. This is
> not my
> > >
> > > area of expertise,
> >
> > ...looks like Chris cannot explain why artifacts innon-apache.org
> >
> > namespace appear in the repository. But it is clear such artifacts can be
> >
> > uploaded as https://repository.apache.org/content/repositories/releases/
> org/
> >
> > proves. I guess the TODO for us (as the Apache gang) is to find out how
> >
> > that is possible?
> >
> > Once both TODOs (Oracle donates the domain and we find out how for
> example
> >
> > freemarker appears on the Maven repo) are marked as done, we can request
> >
> > help from infra again.
> >
> > -jt
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Upload Maven bits was: Enable Nexus Access For NetBeans

[Jaroslav Tulach]

Back to mailing list...

Looks like my attempt to upload org.netbeans.html and other org.netbeans
binaries to Maven repository hasn't succeeded. One of the reasons is that
Oracle hasn't donated NetBeans trademark and netbeans.org domain to Apache
yet. Surprising! I thought this was donated together with the 1st code
donation. Obviously it wasn't. At least we (as Oracle employees) have
something on to work on...

2018-05-16 20:38 GMT+02:00 Chris Lambertus (JIRA) :

>
> [ https://issues.apache.org/jira/browse/INFRA-16435?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=16477884#comment-16477884 ]
>
> Chris Lambertus commented on INFRA-16435:
> -
>
> Per discussion with Joel Orlina/Brian Fox/Sonatype, the existing Infra
> tooling for repository.a.o apparently does not allow for the standard
> staging/release process for coordinates outside of org.apache. I do not
> know how those other artifacts are being pushed or managed. This is not my
> area of expertise,
>

 ...looks like Chris cannot explain why artifacts in non-apache.org
namespace appear in the repository. But it is clear such artifacts can be
uploaded as https://repository.apache.org/content/repositories/releases/org/
proves. I guess the TODO for us (as the Apache gang) is to find out how
that is possible?

Once both TODOs (Oracle donates the domain and we find out how for example
freemarker appears on the Maven repo) are marked as done, we can request
help from infra again.

-jt

Apache on Apache was: Build systems [WAS: Re: [VOTE] Release Apache NetBeans 9.0 RC1 (incubating) rc1]

[Jaroslav Tulach]

2018-05-25 16:58 GMT+02:00 Neil C Smith :

> On Fri, 25 May 2018 at 02:02 Tim Boudreau  wrote:
>
> > IMO, Gradle is a step backward for build systems - scriptability leads to
> > fragile systems, and ones that are impossible for tools to reason about.
> >
> > https://timboudreau.com/blog/maven/read
> >
> >
> Nice article!  I know you link it in a comment, but also worth posting
> Jaroslav's page on this too - http://wiki.apidesign.org/wiki/Gradle
>
>
Now I see! I've noticed quite a lot of activity on twitter with respect  to
this article. Now I know where it is coming from. Thanks for sharing!

When discussing[1] the build systems, have we also considered the Apache
view point - e.g. running Apache on Apache? From this perspective Ant and
Maven are +10...
-jt

[1] I assume this thread is just a discussion as nobody has the guts to
really rework the whole build system for all the (including not yet
donated) code, right?

Re: HTML/Java API goes to Gradle

[Jaroslav Tulach]

Thanks a lot Hans, for connecting me with potential reviewers.

Hello Piotr, Eric, [my PR](https://github.com/apache/
incubator-netbeans-html4j/pull/6) has already been merged, but I'll be
thankful for any comments. I can fix them in another PR. Especially the way
I [hook between compile and jar targets](
https://github.com/apache/incubator-netbeans-html4j/pull/6/files#diff-1c983dc3ce8878c646f01e6fe5001845R42)
feels slightly hacky. I just don't know a better solution.

Thanks for any advice.
-jt


2018-05-25 20:44 GMT+02:00 Hans Dockter <h...@gradle.com>:

> Hi Jaroslav,
>
> Sorry for the late response. I'm adding Piotr and Eric from the Gradle
> build tool team to have a look at this and see what we can do to help.
>
> Hans
>
> On Thu, Apr 19, 2018 at 11:58 AM Jaroslav Tulach <
> jaroslav.tul...@gmail.com> wrote:
>
>> Hello guys, hello Laszlo.
>>
>> For a while I was considering to expand the reach of the HTML/Java class
>> post processing. So far we could do that from a command line and via a
>> Maven plugin. There is a pull request https://github.com/apache/
>> incubator-netbeans-html4j/pull/6 that tries to do the same for Gradle.
>> It works to some extent, but a review is needed. It is my first real Gradle
>> plugin... Especially the way it inserts itself between compilation and
>> packaging feels wild...
>>
>> Thanks in advance for your advices at https://github.com/apache/
>> incubator-netbeans-html4j/pull/6
>> -jt
>>
>> PS: The challenge was to build the plugin with Maven. It is not easy to
>> find proper Gradle JARs in Maven repositories. As such I decided to resort
>> to a bit of reflection in some situations.
>>
> --
>
> [image: email-signat...@2x.png]
>
> Hans Dockter
>
> CEO & Founder
>
> Gradle Inc.
>
> W. gradle.com
>

Re: AW: The IDE for DevOps was: IntelliJ IDEA vs Netbeans

[Jaroslav Tulach]

Tim,
its 21th century and we are using GitHub. If you want to contribute, please
do it via PR.
Thanks.
-jt


2018-04-25 13:31 GMT+02:00 Tim Boudreau :

> To follow up on this a bit, since I spent a bit of time attempting to
> optimize this - the two big performance wins are:
>
>  1. Cache a byte[] and reuse it for every JAR entry (pass in a lambda to
> read() rather than get out a Map)
>  2. Maven's DefaultScanner will pass the indexer *every single file* in the
> repository it's indexing, while NetBeans is likely uninterested in .sha1
> files and similar;  filtering the list of files to things NetBeans is
> likely to be interested offers large benefits
>
> These two optimizations cut scanning time of my ~/.m2/repository dir (~2700
> JAR files) from 42304ms to 30100ms, which is a 29% performance improvement
> with
>
> That said, I have some tests to get passing before this is patch-worthy, so
> we'll see if those results hold up.
>
> Of course, this only helps local indexing - whatever "Unpacking indexes" is
> doing with remote repositories won't be helped by this.
>
> Still, it seems like something that could be optimized quite a bit before
> giving up on it.  If anyone's interested in poking at this:
> https://timboudreau.com/files/maven-indexer.diff
>
> -Tim
>

Re: which build?

[Jaroslav Tulach]

I've updated description of the -linux and -windows ones. Their primary
usage is for testing. Up to Jan Lahoda to update the description of the
release job.
-jt


2018-04-26 15:18 GMT+02:00 Glenn Holmer :

> What's the difference between the builds from incubator-netbeans-linux
> and those from incubator-netbeans-release?
>
> --
> Glenn Holmer (Linux registered user #16682)
> "After the vintage season came the aftermath -- and Cenbe."
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

History in Git was:: The IDE for DevOps was: IntelliJ IDEA vs Netbeans

[Jaroslav Tulach]

2018-04-24 13:32 GMT+02:00 Tim Boudreau :

> could seriously impact performance.  Unfortunately with a Git checkout, I
> don't have the history to figure out why.


Read the (end of) README.md.
-jt

Re: AW: The IDE for DevOps was: IntelliJ IDEA vs Netbeans

[Jaroslav Tulach]

2018-04-23 8:40 GMT+02:00 Laszlo Kishalmi :

> Dear all,
>
> I just experimented some stuff for that yesterday using bintray API for
> their repositories. I was able to retrieve a list of packages by
> group/artifact ID-s and even query artifacts by package/class names, though
> the later one might need to use the "I feel lucky!" heuristics, as I
> searched for the new JUnit5 package and that gave me 14000+ matches and
> returned the first 50.


Excellent. If you put this query in and change the default for the
download/update of local indexer to "never", I'd be happy.
-jt

PS: Maybe there will be some bugs, but the current indexer performance is
"buggy" too and a lot!


> On 04/22/2018 11:28 PM, Christian Lenz wrote:
>
>> Hey Jaroslav,
>>
>> I think now it is the best time to do the Approach again under Apache 
>>
>
PPS: Probably. It has just one issue: There needs to be somebody to do it.

The IDE for DevOps was: IntelliJ IDEA vs Netbeans

[Jaroslav Tulach]

> I just spent the past 2 weeks using IntelliJ IDEA exclusively (having used
> it sporatically before). I'm going to share some brief thoughts in the
> hopes that it helps.
>
> As far as I can tell, IntelliJ's killer feature is their debugger (more
> broadly, their UI). Our killer feature is our profiler, and Maven
> integration (more broadly, bundling more functionality standard).
>
>  * Netbeans drives development of Maven projects through Maven. This
>results in better integration than IntelliJ provides (e.g. good luck
>trying to start a debugging session through Maven)
>

Yeah, I can confirm setting up debugging (for Maven) in IntelliJ is so
complicated...

Once I called NetBeans the [IDE for devops and admins](
http://wiki.apidesign.org/wiki/DevOps) and this is what I meant. If you
care about your overall project structure, there shall be benefits of using
NetBeans+Maven. If you just care about the code, the IntelliJ's editor
focus may give you better experience.

Moreover the NetBeans approach is more fragile. Structures of pom.xml files
differ wildly and when they get out of expectations, things may get broken
or slow...

>  indexing and performance levels can be done with the
> code currently in Apache NetBeans Git. Jaroslav Tulach will have insights
> as well as gratitude for help in this area

My thought is simple: there should be no Maven index processing on the
client (by default). There should be a webservice the IDE would query
instead. However my idea was rejected by last Oracle NetBeans performance
team last time I proposed it. It was found too complicated. Anybody wants
to pick that challenge up now?

-jt

Re: HTML/Java API goes to Gradle

[Jaroslav Tulach]

Hello Emilian,
thanks for taking a look.

Dne neděle 22. dubna 2018 7:42:08 CEST, Emilian Bold napsal(a):
> I can't help with the patch. Just 2 remarks:
> 
> * didn't notice HTML4J is Maven-based.

I tried to avoid any dependencies on NetBeans Platform in the HTML4J. Thus I 
started from scratch. When starting from scratch I have chosen standard build 
system over NetBeans Ant Harness.

> * I suppose the Platform does not depend on html4j-mavan-plugin so this new
> Gradle dependency doesn't matter.

Right. The platform consumes just the binaries of the libraries. Instead of 
the Maven plugin it uses own special Ant task:
https://github.com/emilianbold/netbeans-releases/commit/a7b3e0732c078

-jt


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

HTML/Java API goes to Gradle

[Jaroslav Tulach]

Hello guys, hello Laszlo.

For a while I was considering to expand the reach of the HTML/Java class
post processing. So far we could do that from a command line and via a
Maven plugin. There is a pull request
https://github.com/apache/incubator-netbeans-html4j/pull/6 that tries to do
the same for Gradle. It works to some extent, but a review is needed. It is
my first real Gradle plugin... Especially the way it inserts itself between
compilation and packaging feels wild...

Thanks in advance for your advices at
https://github.com/apache/incubator-netbeans-html4j/pull/6
-jt

PS: The challenge was to build the plugin with Maven. It is not easy to
find proper Gradle JARs in Maven repositories. As such I decided to resort
to a bit of reflection in some situations.

Re: Time to branch for the release candidate?

[Jaroslav Tulach]

Yeah, there are changes in the queue for the master branch that could be
too destabilizing. To avoid something like that to negatively influence the
9.0 release, I'd suggest to create a branch release/9.0 and put only the
safe fixes ready for 9.0 there. The wild development would continue in the
master branch.

Maybe this is an overkill, but it would make me feel safer.
-jt


2018-04-17 13:04 GMT+02:00 Geertjan Wielenga <
geertjan.wiele...@googlemail.com>:

> Hi all,
>
> Is it time to create a branch for the release candidate?
>
> If yes, or after questions and discussions, who will do it?
>
> Thanks,
>
> Gj
>

Re: Freezing platform API changes until second donation is complete?

[Jaroslav Tulach]

Hello Antonio.
Preventing any API changes would de-facto stop most of the development for
an unknown period (who knows how long the 2nd donation will take, I don't
dare to estimate). However I understand your concern I also use many
modules from 8.2 (JavaScript, Python, Eclipse formatter, etc.) in the
latest development build and I want them to work.

Luckily we don't have to freeze the API. We just need it to be compatible.
Thus I suggest to ban any _incompatible changes_ (especially to publicly
available signature).

We do that most of the time, but these days it is more important. We really
have a "business reason" to keep compatibility. There are tons of plugins
written against 8.2 and nobody is going to rewrite them to new NetBeans
version anytime soon (never in some cases).

If we keep binary backward compatibility, we will be sure that old plugins
(at least) link with new NetBeans.
-jt


2018-03-16 8:52 GMT+01:00 Antonio :

> Hi all,
>
> I was wondering if we should freeze PRs that change the platform API until
> the second code donation is complete: many users still use plugins from
> NetBeans 8.2 on top of the Apache NetBeans 9.0 Beta Platform (through the
> update center).
>
> Thanks,
> Antonio
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: What Coding Conventions Should We Follow Now? What should the IDE default to?

[Jaroslav Tulach]

Here is my user comment.

My colleagues at OracleLabs integrated Eclipse formatter into our continuous 
build. As far as I know it is the only formatter that works in headless mode 
and is sort of standardized and a bit stable.

As it is annoying to always reformat from command line,  I integrated Benny's 
excellent formatter 
http://plugins.netbeans.org/plugin/70382/eclipse-java-code-formatter-eclipse-neon-4-6-1a
 into our NetBeans projects.

Rather than discussing the actual conventions, make sure the IDE can read and 
apply settings from Eclipse easily and exactly.

My 2 Kč.
-jt


14. 3. 2018 v 8:22, Emilian Bold :

> The coding conventions NetBeans follows and provides are "as-is". People that 
> what to customize it have some options to toggle or could use 3rd party 
> plugins.
> 
> Particularly since there is no global Java standard I don't believe we should 
> be looking for extra work for nothing. For reference, the Google Java Style 
> Guide is rather good.
> 
> Which standardised coding conventions do the Eclipse and IntelliJ IDEs follow?
> 
> --emi
> 
> ‐‐‐ Original Message ‐‐‐
> 
>> On 12 March 2018 7:25 PM, Wade Chandler  wrote:
>> 
>> I noticed that Oracle has not maintained a convention for the Java language 
>> like other groups have for their ecosystems. This also has not materialized 
>> from OpenJDK:
>> 
>> http://www.oracle.com/technetwork/java/codeconvtoc-136057.html 
>> http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
>> 
>> http://openjdk.java.net/guide/codeConventions.html 
>> http://openjdk.java.net/guide/codeConventions.html
>> 
>> https://wiki.openjdk.java.net/display/OpenJFX/Code+Style+Rules 
>> https://wiki.openjdk.java.net/display/OpenJFX/Code+Style+Rules
>> 
>> http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html 
>> http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html
>> 
>> Contrast this to:
>> 
>> https://www.python.org/dev/peps/pep-0008/ 
>> https://www.python.org/dev/peps/pep-0008/
>> 
>> https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions
>>  
>> https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions
>> 
>> So, it just seems wrong to follow those links; the Java conventions were a 
>> great example for years. I think the Google ones seem reasonable myself 
>> unless we or others in the Java community take that up:
>> 
>> https://google.github.io/styleguide/javaguide.html 
>> https://google.github.io/styleguide/javaguide.html
>> 
>> Any thoughts or other information? Am I missing something?
>> 
>> Thanks,
>> 
>> Wade
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> 
> 
> 

Images & bugs was: Think Java, not Electron! was: Apache HTML/Java UI instead of

[Jaroslav Tulach]

Hello Dmitriy,
One more note. Your images didn't make it through. Probably they were blocked 
by the mailing list filter.

> elect: File -> New Project -> JavaFX -> Java HTML5 Application (again, only 
> because I knew from this thread where to click)
> Read description: "Generates a WebView based DukeScript application".
> 
> DukeScript? WebView based?... huh...
> Click, wizard opens. Font is different, project type selector radio buttons 
> not aligned to text (image):
> 
> 


Maybe you can report this to JIRA. It would be something for Toni to 
investigate.

> 
> Select "Visual HTML/Java example", project opens, immediately get warning 
> about project problems (Export-Package/Provate-Package contains packages from 
> dependencies) (image):
> 
> 

Here I am not sure what to imagine, but possibly the priming build has to 
finish first and download necessary libs. That would be a bug for me.

> 
> It did run, but not that I understand the structure of 5 projects

I assume this is the old NetBeans problem of showing all (Maven) project next 
to each other. Fine for [build masters](http://wiki.apidesign.org/wiki/DevOps), 
but you want to code, not manage scripts, right?

Feel free to report it as well, although I am afraid the general fix'd be 
complex and I am out of ideas for some shortcuts.

> that got created or how to use it. I can start "... Client for Web" project 
> from the IDE, but how do I build a runnable application? (image)

Open Pop up menu on the project, select (extra Maven) Goals, Build Zip - is the 
action. Quite well hidden, true.

> 
> 
> 
> So yeah, I totally understand people googling for "Java Vaadin Electron 
> tutorial". As a matter of fact I was one of those people just 2 weeks ago, 
> even though I have built NB 9 previously.

Thanks in advance for the bugs.
-jt

Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

[Jaroslav Tulach]

Hello Dmitry,
thanks a lot for trying it out!

2018-03-15 2:50 GMT+01:00 Dmitry Avtonomov :

> I find it incredible that Jaroslav is saying "... people aren't willing to
> dedicate 10minutes of their personal time to try HTML/Java API in action
> ...". How are they supposed to discover that?
>

To be fair, I also mentioned "... do you have recent version of NetBeans
9.0..." - e.g. the build time doesn't count.

Let's try it out with time logging:
>
> 15:33 - Setting out to search for NetBeans on google, landed on
> https://netbeans.org/, latest version 8.2
> 15:34 - Search for "netbeans apache" (only did this because I knew what to
> search for), landed on https://netbeans.apache.org/
> 15:34 - Go to downloads (https://netbeans.apache.org/download/index.html)
> - no binaries
> 15:35 - I've already built v9 once, just deleting it took several minutes
> 15:41 - Start clone `git clone https://github.com/apache/
> incubator-netbeans.git` 
> 15:44 - Clone + checkout done
> 15:44 - `ant` (i had ant 1.10 installed, jdk - oracle 1.8, core i7 6700hq)
> ...
> compilation took 24 minutes 29 seconds
> ...
> `ant tryme`. Popup message:
>
> "Java features limited":
> - install nb-javac library (highly recommended)
> - run NetBeans on JDK 9 or later
>
> Click button to install nb-javac plugin.
> Warnings about unsigned plugins.
> Restart IDE.
>

Alas, this is the nb-javac licensing problem, that will be hard to mitigate
anytime soon.


> That's already quite some trouble that would stop 99.5% of people who
> might have wanted to try it out.
>
>
> Select: File -> New Project -> JavaFX -> Java HTML5 Application (again,
> only because I knew from this thread where to click)
> Read description: "Generates a WebView based DukeScript application".
>
> DukeScript? WebView based?... huh...
>

Geertjan also suggested to make the wizard more prominent. I noticed that
Toni is currently thinking of some adjustments... personally I would split
the wizard into few: "Java Desktop App", "Java iOS App", "Java Android
App", "Java SPA App", etc. That would promote that NetBeans does support
development/deployment to all important platforms of these days.


> Click, wizard opens. Font is different, project type selector radio
> buttons not aligned to text (image):
>
> Select "Visual HTML/Java example", project opens, immediately get warning
> about project problems (Export-Package/Provate-Package contains packages
> from dependencies) (image):
>
> It did run, but not that I understand the structure of 5 projects that got
> created or how to use it. I can start "... Client for Web" project from the
> IDE, but how do I build a runnable application? (image)
>

This is a great usability study. Toni has written a [getting started
tutorial and a book](https://dukescript.com/documentation.html), but yes,
it would be better if the system was usable without reading anything. I
always advocate supporting "cluelessness" (and I hope I did support it when
designing the HTML/Java API), but I never verified whether people building
on top of it (e.g. Toni and his projects and wizards) do the same thing.


> So yeah, I totally understand people googling for "Java Vaadin Electron
> tutorial". As a matter of fact I was one of those people just 2 weeks ago,
> even though I have built NB 9 previously.
>
> The samples I was able to run were running either in my default browser
> (so it depends on system browser) or in, presumably, javafx webview
> window(?), which lacked significantly in performance (the examples ran,
> judging visually, at 10-20fps, while in the browser it was smooth, so I
> couldn't tell the frame rate). I guess something like electron can be used,
> but I have no idea how to achieve this.
>
> It needs:
> - basic documentation
>

I am trying to make the Javadoc entertaining
http://bits.netbeans.org/html+java/, but +1 - more is needed

- geertjan style tutorials
>

+10, Geertjan, do you hear it?

It needs examples of:
> - how to feed large amounts of data from Java to JS running the view
>

Yes, this is often needed and I and Toni did some experiments with it. In
fact we even proposed a paper about it to ManLang conference. The trick to
improve throughput of Java -> JS communication would be:
http://bits.netbeans.org/html+java/1.5/net/java/html/js/JavaScriptBody.html#wait4js()

Btw. how much data you are talking about?


> - how to communicate data back from the view into the java program
>

The low level API is here:
http://bits.netbeans.org/html+java/1.5/net/java/html/js/package-summary.html


> - how to build and run the application outside of the ide
>

I am not sure if Toni described that somewhere, but I remember there was a
blog about "redeploys" done from outside of the IDE...

https://dukescript.com/best/practices/2015/04/12/no-redeploys.html
and maybe
https://dukescript.com/update/2017/01/14/trybuypresenter.html


> - preferably show how to create an 

API Design was: Apache HTML/Java UI instead of

[Jaroslav Tulach]

2018-03-15 4:26 GMT+01:00 cowwoc :

> Chuck,
>
> My main beef with AWT/Swing is one of API design first, bugs second, and
> performance last.
>
> I think there is a real opportunity here but it is a difficult one to
> solve in an open-source context. I think open-source communities are great
> for fixing bugs and implementing features but they are not great for API
> design. I wish we had someone like Joshua Bloch in charge of designing a
> new API


Dear Gili, let me point out that there is a person among this community who
has some API design experience. The person may not be well known and may be
to shy to speak up, but I am sure he is watching. After gathering a lot of
experience with his first long term API design project, he even wrote a
book about the topic. The first API Design book ever published...

> My goal is to make UI development as easy under Java as it is for the web.

...after that he started to design slick APIs to make UI development for
Web in Java smooth, rapid, and as type-safe as possible. Maybe he failed,
maybe his work is underestimated and undervalued in the community. Possibly
he will live and die miserably.

Because, after all the hard work I put into designing HTML/Java API and in
spite I used all the experience I gained while designing NetBeans as
described in my http://practical.apidesign.org book, I don't seem to be
able to convince anyone that HTML/Java is the most slick Java API ever
designed for creating portable UIs and a way to go!

Best regards.
-jt


that would sit on top of AWT/Swing, provide equivalent functionality as the
> original, but with a clean API. I also believe that it is vital to
> gradually break backwards compatiblity over time (as Google Guava does) in
> order to end up with a better API long-term.
>
> My goal is to make UI development as easy under Java as it is for the web.
> For the vast majority of use-cases, technical performance is not the
> bottleneck. Developer productivity is. I want an API that faciliates
> building Filthy Rich Clients, similar to Android/iOS applications we're all
> familiar with that ooze UI goodness.
>
> Gili
>
>

The Importance of Being Portable was: Think Java, not Electron!

[Jaroslav Tulach]

Hello guys,
thanks again for all your replies. Rather than answering them one by one
I'd like to provide following "classification summary". Looks like there
are three major streams of opinions:

1. Experienced Swing/FX developers willing/being forced to move closer to
Web
2. Experienced Swing/FX developers (sort of) OK with current state
3. Experienced Web developers wishing to code for NetBeans with their
technology

I belong into the category #1 - while I like Swing and I see its value for
development of desktop applications, I know that these days projects don't
start with desktop being the primary target. Everyone wants to get to
cloud, and the remaining ones want to get mobile. None of that can be done
with Swing. Even Zoran admits that he'd like to write his application in a
style that would allow him to run it from a web site as well as NetBeans.
That (in my opinion) rules Swing out and that is the reason why I designed
HTML/Java API & co.

The category #3 isn't huge. Why would somebody who have seen "the future"
looked back? Why would a Java developer tried to learn COBOL? In spite of
that we have one active voice among us - Christian. I am thankful for
having him around and I wish him to survive our attacks against JavaScript
and HTML well. If we want to move forward with support of HTML(/Java) in
NetBeans we need his knowledge of contemporary build and coding practices
used by the web developers.

The category #2 is surprisingly (to me) huge (I am counting suggestions to
use SWT or OpenGL here as well), but there is a truth in such position:
Swing and JavaFX are here and they aren't going away. If they work for you,
there is no reason to search for something else. They will always continue
to work.


Knowing the categories, I'd like to offer something to each of you with the
goal to keep you motivated to work with us towards a goal you can agree to:

The NetBeans Platform roots are built around Swing - e.g. #2 category - and
I am 100% sure we want to keep those roots untouched. If you are happy with
NetBeans Platform as it is, don't worry - it will continue to work for you.
We have a long time track of keeping backward compatibility while moving
the system forward (for example the HTML/Java is already in and nothing bad
happened), so we can promise that your Swing/FX usecase isn't going to be
affected.

I am dedicated to move more and more HTML based UI into the system. I have
to: I am asked to develop web based solutions and I don't want to write my
code twice. I want to write code that works in the web as well as in
NetBeans. I am looking at that from a category #1 perspective - e.g. I want
Java oriented tools most of the time. On the other hand I understand the
desire of Christian to improve the #3 point of view. That shall happen as
well: make sure web developers can extend NetBeans without major problems.
Hopefully Christian will be able to help with that.

Geertjan asked for a vision for the NetBeans Platform, here is one: ideally
I want to have a replacement of core.windows module (which organizes Swing
based TopComponent, menu and toolbars in a Swing JFrame) with
core.htmlwindows reimplementation (that would show a browser and rendered
everything - menu, toolbar, components - via browser pipeline). Of course
such module would be fully optional. Right now we can mix Swing and HTML
based UI next to each other in a JFrame context, with the above module the
same shall be possible[1] in an browser-like renderer.

It is a long term vision, but if there is enough will, it is not
unrealistic to achieve it. In any case, thanks for a lively and inspiring
discussion we had so far.
-jt


[1] There was a request to render Swing in HTML. I am glad to say that I
have a Graphics that renders in HTML and I managed to render Visual Library
scene this way. The result was 1:1 and the branch of my experiment is here:
https://github.com/apache/incubator-netbeans/compare/master...JaroslavTulach:jtulach/PortableVisualLibrary?expand=1
- help with improving the Graphics context to render JButton (for example)
is more than welcomed.

The IDE for DevOps was: NetBeans at 8.2% in the StackOverflow 2018 developer survey

[Jaroslav Tulach]

2018-03-14 14:40 GMT+01:00 Paul Franz :

> It is weird.
>
> NetBeans is at 10.9% for Mobile Developers and 8.4% for System
> Admins/DevOps.
>

Admins! DevOps! Amazing.

For a long time I wanted to share my thoughts about this and seeing your
email motivated me to write an essay down:
http://wiki.apidesign.org/wiki/DevOps

Enjoy editing your build scripts!
-jt



> On 14 Mar 2018, at 9:33, Emilian Bold wrote:
>
> https://insights.stackoverflow.com/survey/2018/
>> #development-environments-and-tools
>>
>> --emi
>>
>> -
>
>

Re: List of options of "cluster.config"

[Jaroslav Tulach]

See nbbuild/cluster.properties file.
-jt

Odesláno z iPadu

13. 3. 2018 v 8:06, Peter Cheung :

> Hi All
>   How to know/get the list of options of parameter “cluster.config”?
> 
> $ ant -Dcluster.config=platform
> 
> Thanks
> From Peter

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Think Java, not Electron! was: Apache HTML/Java UI

[Jaroslav Tulach]

Hello Zoran,
your question is easy to answer (so I start with it, but I thank everyone for 
comments, I react later)...

14. 3. 2018 v 2:48, Zoran Sevarac :

> Can I do the following using HTML4J:
> 1. Build a frontend that will work in NetBeans Platform App and web app
> without modifications?

Yes, you can. 
> 2. Reuse stuff (wizards) based on Wizard API in web app?

Yes, you can. Just like I did with the [Fair 
MineSweeper](http://xelfi.cz/minesweeper/bck2brwsr/) game.



> If I can do that techicaly my next question is how. Thats when I'll need
> some sample/tutorial.

Please read the prose sections of the [MineSweeper 
game](http://xelfi.cz/minesweeper/bck2brwsr/) they explain it all: write once 
and deploy everywhere.

> I'm building a NB Platform based app at the moment, and it would be great
> for me to have web version of it too, without much work.

Depends on how you measure your work, but Fair MineSweeper is an example it is 
possible.
-jt

> Comunicate specific use cases and high level problems that you're solving,
> that will get you the followers.
>> 

PS: Shame on me for not being able to do it. The MineSweeper game is around for 
four years, including the IDE support. And then you ask "frontend that will 
work in NetBeans Platform App and web app"! Well, that is the whole point of 
HTML/Java API (from NetBeans perspective) - what have I been doing that I am 
not able to get this message thru?

Re: Problem with Java Help

[Jaroslav Tulach]

Hello Zoran,
JavaHelp is currently missing from standard NetBeans distribution as it is
GPLv2withCPex licensed and Apache and GPL doesn't go well along. You need
to put it into (boot)classpath somehow for now.
-jt

PS: There is a guy in Oracle working on relicensing JavaHelp to something
easier to use from Apache code. Hard to estimate the delivery time,
however...

2018-03-13 12:35 GMT+01:00 Zoran Sevarac :

> Hi,
>
> Did anybody experienced/solved problem with module with Java help?
> I'm getting the following Class not found exception for Java help when
> building my NB platform app:
>
> An annotation processor threw an uncaught exception.
> Consult the following stack trace for details.
> java.lang.NoClassDefFoundError: com/sun/java/help/search/Indexer
> at
> org.netbeans.modules.javahelp.HelpSetRegistrationProcessor.handleProcess(
> HelpSetRegistrationProcessor.java:145)
> at
> org.openide.filesystems.annotations.LayerGeneratingProcessor.process(
> LayerGeneratingProcessor.java:99)
> at com.sun.tools.javac
>
> Cheers
> Zoran
>

Re: NetBeans external binaries and sha1 hash values from Maven Central

[Jaroslav Tulach]

Hard to say without debugging. You can find the code here:
https://github.com/apache/incubator-netbeans/blob/master/nbbuild/antsrc/org/netbeans/nbbuild/extlibs/DownloadBinaries.java#L368
-jt


2018-03-13 14:44 GMT+01:00 Christian Bourque <christian.bour...@gmail.com>:

> Hey guys,
>
> Thanks for your replies!
>
> But I think I wasn't clear enough in my original post: basically my
> question is why is NetBeans expecting a different hash value than the one
> found on Maven Central?
>
> C.
>
>
> On Tue, Mar 13, 2018 at 4:29 AM, Jaroslav Tulach <
> jaroslav.tul...@gmail.com>
> wrote:
>
> > Did you built JGit from source and installed it into local Maven
> > repository? Then the locally built version takes precedence over the one
> in
> > the Maven central and has, of course, different SHA. Adjust the SHA or
> > delete the local copy from .m2/repository and let the build download the
> > real version from Maven central.
> >
> > -jt
> >
> > PS: My experience tells me this is painful, sorry for the hassle.
> >
> >
> > 2018-03-13 1:48 GMT+01:00 Christian Bourque <christian.bour...@gmail.com
> >:
> >
> > > Hi all,
> > >
> > > I'm currently trying to compile NetBeans 9.0 with a more recent Eclipse
> > > JGit library (the one currently bundled with
> > > NetBeans is 3 years old!) but I'm having a hard time with the hash
> (sha1)
> > > value that is used by the build system that's
> > > downloading the artefact from the Maven Central repository! When I
> build
> > > NetBeans it says that the hash value
> > > that I put in the binaries-list file doesn't match the hash of the
> > artefact
> > > found on Maven Central, but I took the hash
> > > value directly from the Maven Central repository so I expected it to be
> > > correct:
> > > http://central.maven.org/maven2/org/eclipse/jgit/org.
> eclipse.jgit/4.11.0
> > .
> > > 201803080745-r/
> > >
> > > So then I decided to download the Eclipse JGit source code from GitHub:
> > > https://github.com/eclipse/jgit/releases/tag/v4.11.0.201803080745-r
> > > compile it and generate the sha1sum myself. To my surprise the computed
> > > checksum was equal to the one expected by NetBeans during the build
> > > process.
> > >
> > > So I'm a bit puzzled! If the build script is downloading an external
> > > dependency from Maven Central then the hash should
> > > match the one found in this file:
> > > http://central.maven.org/maven2/org/eclipse/jgit/org.
> eclipse.jgit/4.11.0
> > .
> > > 201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1
> > >
> > > Anyway, if anyone could shed some light on this situation I would
> really
> > > appreciate it!
> > >
> > > Thanks,
> > >
> > > Christian
> > >
> >
>

Re: NetBeans external binaries and sha1 hash values from Maven Central

[Jaroslav Tulach]

Did you built JGit from source and installed it into local Maven
repository? Then the locally built version takes precedence over the one in
the Maven central and has, of course, different SHA. Adjust the SHA or
delete the local copy from .m2/repository and let the build download the
real version from Maven central.

-jt

PS: My experience tells me this is painful, sorry for the hassle.


2018-03-13 1:48 GMT+01:00 Christian Bourque :

> Hi all,
>
> I'm currently trying to compile NetBeans 9.0 with a more recent Eclipse
> JGit library (the one currently bundled with
> NetBeans is 3 years old!) but I'm having a hard time with the hash (sha1)
> value that is used by the build system that's
> downloading the artefact from the Maven Central repository! When I build
> NetBeans it says that the hash value
> that I put in the binaries-list file doesn't match the hash of the artefact
> found on Maven Central, but I took the hash
> value directly from the Maven Central repository so I expected it to be
> correct:
> http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0.
> 201803080745-r/
>
> So then I decided to download the Eclipse JGit source code from GitHub:
> https://github.com/eclipse/jgit/releases/tag/v4.11.0.201803080745-r
> compile it and generate the sha1sum myself. To my surprise the computed
> checksum was equal to the one expected by NetBeans during the build
> process.
>
> So I'm a bit puzzled! If the build script is downloading an external
> dependency from Maven Central then the hash should
> match the one found in this file:
> http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0.
> 201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1
>
> Anyway, if anyone could shed some light on this situation I would really
> appreciate it!
>
> Thanks,
>
> Christian
>

Think Java, not Electron! was: Apache HTML/Java UI instead of

[Jaroslav Tulach]

Thanks a lot for your opinions! I am going to react to one recurring theme
in this email...

2018-03-12 16:59 GMT+01:00 Jaroslav Tulach <jaroslav.tul...@gmail.com>:

>
> Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
> care about Java, then your future should be Apache HTML/Java API!
>
>
First of all I have to admit it drives me mad, how incapable I am in
communicating these ideas. How could I be the initial architect of
NetBeans, when I am not able to explain what HTML/Java API is beneficial
for? Or was I just the architect and there had to be others to handle the
public relations? Or was the success of NetBeans (Platform) just an
unrepeatable luck?

Anyway, there have been few references to Electron framework in your
reactions to my email:

> There is nothing better than creating UIs with HTML and use them
everywhere, like in the Electron Framework.
> ... look into electron apps ... like VS Code and I think this is a big
Player and you can see, that it performs very well and it is performant as
hell.

OK, I can see people are looking (or at least googling) for alternatives to
current UIs. Yes, I agree HTML is one of (the best) options there -
especially if you want real WORA - e.g. also target plain browser. However
I have to say the following sentence is just increasing my internal
suffering...

> heavyweight, ...(but)... the open source nature ... of Electron make it
potentially an attractive option for mixed Java/HTML applications

We - the NetBeans (incubating) project - have such technology, it is
HTML/Java API. It has been intentionally designed to support mixed
Java/HTML applications. We are the community of the project! But instead of
improving what we have and making it work for our NetBeans IDE purposes
(which is certainly simpler than trying to use Electron designed for
something different; more on that later), we are looking at other project
and admiring their "open source nature"!

Am I really doing so poor job that people aren't willing to dedicate 10
minutes of their personal time to try HTML/Java API in action? Rather they
are looking...

> I was looking at an example project using Vaadin running inside Electron
recently.  Have you tried this approach with HTML/Java?

...and trying Electron samples! C'mon do you have recent version of
NetBeans 9.0? Then just select "New Project", "JavaFX", "Java HTML5
Application" click through the wizard and choose Run/Debug on the generated
project! How much did it take? 30s of activity[1]?

> I keep trying to find some time to experiment with Apache HTML/Java and
wondered at the feasibility of reworking that Electron example with it?

If you give the NetBeans 9.0 support for HTML/Java UI a try, you see (when
using for example the Visual archetype) that rewriting visually rich
Electron application like
https://github.com/electron/simple-samples/tree/master/activity-monitor
should be a piece of cake.

I consider it patriotic to try NetBeans own solution first. Am I completely
off?

> Demo app showing all kind of features a given system allows me to use.
Like a toolbox, which I run and say - hey that's the component I need. Is
there something like this for the HTML+JAVA api?

The visual archetype offers canvas sample, line charts and pie charts
sample and interactive GeoBase application. Isn't that enough? Then there
is another CRUD like archetype, as well as simple MVVM sample. All of them
are just few clicks from your reach ("New Project", "JavaFX", "Java HTML5
Application"), is that enough to get started?

I hope it is. Guys, please, instead of drinking your morning coffee, click
though the wizard and see Apache HTML/Java API in action yourself. I'll be
thankful for comments. As confessed, I am depressed by my inability to
communicate what our HTML/Java project can do for you. It may not be 100%
perfect fit, but it is so close to what you guys need Shame on me for
not being able to explain that!

Thanks.
-js

PS: Now let's look at what Electron isn't and why HTML/Java shall be a
better choice:

> I am sure electron is good, but my personal preference is to not use a
web ide.

I share your feelings. However we are not talking about Web IDE. We are
talking about reusing rendering pipeline that is behind HTML. Sure, this
pipeline is used in browsers, but that doesn't mean browser == the
rendering pipeline. Browser is much more and we don't need all of that.

> Think about ... what Electron actually *is* ...

Electron is the rendering pipeline, plus a bunch of libraries for dealing
with the surrounding operating system, plus JavaScript specific build
system. But, when writing Java application, why would you need those
libraries? Java has pretty rich operating system API (think of java.nio,
missing in JavaScript) and there are plenty of libraries to deal with other
aspects of OS integration. Why would you need n

Re: Support of Java 10

[Jaroslav Tulach]

> > do we have an agreement to merge the branch from Jan to have at least

> > basic
> > > support for Java 10?
> > >
> >
> > I hope so, my plan is to send a pull request "sometime soon".
> >
>
> +1
>

+1


> And still +1 for keeping version sync and calling this NB 10! ;-)
>

-1

-jt

Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Jaroslav Tulach]

> "Oracle has begun conversations with interested parties in the Java

> ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
 referenced timeframes."

>>>
>>
The official announcement is here and people are finally starting to
realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
will sponsor development of anything new for these technologies. Even if
they get transfered to their new owners, they will be in maintenance mode:
Bugfixes and little features. No bigger changes - no new rendering
pipelines using new nifty features of graphics cards. Just sustaining. I've
been explaining this would happen since 2012.

To help us out of this situation and save Java as a programming language I
dedicated my days to smoothing out interoperability between Java and
JavaScript with the goal to reuse the most flexible and portable rendering
system of these days: the browser. My work has already been donated to
Apache, see: https://github.com/apache/incubator-netbeans-html4j - let's
use it to build new features of NetBeans and other future Java desktop
applications. Get started by reading Javadoc at
http://bits.netbeans.org/html+java/

Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
care about Java, then your future should be Apache HTML/Java API!
-jt

Re: NetBeans translation to other languages

[Jaroslav Tulach]

As far as I can tell the translations are at
http://hg.netbeans.org/releases/l10n/ Geertjan, when do you plan to
organize donation of these files to Apache? Looks like the community is
eager to jump on them...
-jt


2018-03-03 13:51 GMT+01:00 Emilian Bold :

> At the most basic level, you could just create GitHub Pull Requests for
> the resource (.properties files and images). See
> http://bits.netbeans.org/dev/javadoc/org-openide-modules/
> org/openide/modules/doc-files/i18n-branding.html
>
> Of course, this is a bit more complex as you have to clone the repo and
> find the .properties files...
>
> --emi
>
> ‐‐‐ Original Message ‐‐‐
>
> On 27 February 2018 10:04 PM, Milan Keršláger 
> wrote:
>
> > There is no such project netbeans or so at https://translate.apache.org
> >
> > I don't know how translation in Netbeans project works now.
> >
> > But there is some translations already at
> >
> > http://bits.netbeans.org/download/trunk/nightly/latest/ (Russian,
> Portugal
> >
> > /Brazilian/ and some Asia languages).
> >
> > This could be better if somebody knows how those languages were
> >
> > created/submited.
> >
> > Milan
> >
> > 2018-02-24 22:59 GMT+01:00 Emilian Bold emilian.b...@protonmail.ch:
> >
> > > It's very good you brought this up! I also was involved in translations
> > >
> > > long ago.
> > >
> > > Apache uses https://translate.apache.org which runs Pootle.
> > >
> > > We have to learn how to import our data and start using it! Want to
> help?
> > >
> > > --emi
> > >
> > > ‐‐‐ Original Message ‐‐‐
> > >
> > > On 22 February 2018 10:06 PM, Milan Keršláger
> milan.kersla...@gmail.com
> > >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I made some translation work in the past to the Czech language and I
> > > >
> > > > tried
> > > >
> > > > to translate NetBeans few years ago too. Now I'm unable to find how
> to
> > > >
> > > > start. There is a lot of obsolete information around... Is it
> possible
> > > >
> > > > now
> > > >
> > > > after the transition NB under the Apache umbrella?
> > > >
> > > > Milan
> > >
> > > > Milan Kerslager
> > > > http://www.pslib.cz/ke/
> > > >
> > >
> > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> > >
> > > For additional commands, e-mail: dev-help@netbeans.incubator.
> apache.org
> > >
> > > For further information about the NetBeans mailing lists, visit:
> > >
> > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> > --
> >
> > Milan Keršláger
> > http://www.pslib.cz/ke/
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Propose for a patch to avoid duplicate native libs integration for supporting different windows os

[Jaroslav Tulach]

Yeah, using searching also for "windows" or similar, when "windows X"
search yields nothing is fine idea. At least I think.
-jt


2018-03-04 22:55 GMT+01:00 Oliver Rettig :

> Hi Matthias,
>
> thanks for your help.
>
> > So if you place your .dll in the modules/lib/amd64 directory, it should
> > be loaded on all 64 bit JVMs on windows.
> Yes, you are right. It is possible to put all files in the
> modules/lib/amd64 folder to be loaded
> on all 64 bit jvms on windows, but than in the same directory I have also
> the .so-files for the
> linux os.
>
> I think it is more clearly arranged, if the linux and windows files are
> not mixed in the same
> folder.
>
> I have also tryed some linux os and I got always
>
> os.name=linux
>
> I am not sure, if the property is for all linux systems "linux".  If it is
> it is different to the
> windows os, where I get "windows 10" ...
>
> best regards
> Oliver
>
>
>
>

Re: Platform API: Context-sensitive keyboard accelerators

[Jaroslav Tulach]

Out of curiosity (as I may still be living in the past), here is one of the
documents I have written when attempting to (re)design the NetBeans action
system:

https://openide.netbeans.org/proposals/actions/index.html

In general my intention was to use [Action.callback](
http://bits.netbeans.org/8.2/javadoc/org-openide-awt/org/openide/awt/Actions.html#callback-java.lang.String-javax.swing.Action-boolean-java.lang.String-java.lang.String-boolean-)
actions to register a generic placeholder with a shortcut that can then do
whatever each component wants.

-jt


2018-02-27 20:44 GMT+01:00 cowwoc :

> Unfortunately, I'm not too familiar with the internals. I filed
> https://issues.apache.org/jira/browse/NETBEANS-432 with a high-level
> overview of what a user expects. Hopefully someone who is familiar with
> this codebase can flesh out what this entails.
>
> Thank you,
> Gili
>
>
> On 2018-02-27 12:49 PM, Tim Boudreau wrote:
>
>> I'd say file an RFE, but best to get as specific as possible about what
>> mechanism needs to be changed and how.  I.e. Exactly the desired behavior,
>> what blocks it, and where the change would need to be.
>>
>> -Tim
>>
>> On Tue, Feb 27, 2018 at 11:00 AM cowwoc  wrote:
>>
>> Is it okay if I file a RFE for this, or do you feel it should stew a bit
>>> longer in the mailing list?
>>>
>>> Gili
>>>
>>> On 2018-02-26 3:47 PM, Christian Lenz wrote:
>>>
 I figured out that problem too, but I don’t know whether this is window

>>> specific or not.
>>>
 Sure I think you can add a shortcut to your Code, which is already

>>> taken. You got a warning after NetBeans started that says: „there is a
>>> duplicate“.
>>>
 Maybe it overrides it or not, I don’t know atm. But if not and you

>>> created an Action, where you can Change the shortcut via KeyMap Options,
>>> you sometimes overrides existing ones (Which Shows you a warning or error
>>> that another one has the same etc.), but yes they should work context
>>> sensitve, and some are still working context sensitive, afaik.
>>>
 I set ctrl + b to Show the git browser for branches etc. This shortcut

>>> only Woks, when I select a Project. If I’m in the Editor, it will set a
>>> bookmark or open the bookmark window. So there is smth like a context
>>> sensitive way to implement shortcuts but I don’t know the logic at all.
>>>
 My 2 cents


 Cheers

 Chris

 Von: Tim Boudreau
 Gesendet: Montag, 26. Februar 2018 19:59
 An: dev@netbeans.incubator.apache.org
 Betreff: Re: Platform API: Context-sensitive keyboard accelerators

 It's been a long time since I worked on the code involved, so my
 recollection may be a little fuzzy, but this may help point you in a
 direction or two:

 There is a general problem that NetBeans supports, or at least used to
 support, both single window pseudo-SDI mode and a multiple windows mode.
 And keyboard shortcuts propagate down to the InputMap/KeyMap of the

>>> window
>>>
 in question.  My recollection is that this was originally handled with
 an
 AWTEventListener, because that was the one way to guarantee shortcuts
 worked globally, no matter the windowing layout.  I *think* we migrated
 that to something using InputMap/KeyMap around 2003 or so, but there may
 still be workarounds to ensure things work globally.

 What I'd suggest to try is an experiment - create a dialog with the

>>> dialogs
>>>
 API and try binding a key you know is bound as a global shortcut.  Use
 InputMap/KeyMap and attach it to, most likely, the root pane of the

>>> dialog.
>>>
 If it works, then it's just a matter of implementing shortcuts in the

>>> right
>>>
 places (make sure to call consume() on the event to stop it propagating
 further).  If it doesn't, then some more fundamental work that's likely

>>> to
>>>
 touch how key bindings work globally may be needed.

 Also bear in mind that key bindings are different for different

>>> platforms -
>>>
 on Mac OS, the alt key is a compose key for international characters and
 cannot have shortcuts bound to it (ctrl is used instead), and some
 keybindings are mapped to different keys for consistency with other Mac

>>> OS
>>>
 apps (there's a syntax for defining keybindings in OS-neutral ways, for
 declarative bindings).

 HTH,

 Tim


 On Mon, Feb 26, 2018 at 9:11 AM, cowwoc 
 wrote:

 Hi,
>
> Netbeans has an extremely long (and getting longer) list of keyboard
> shortcuts. Part of the problem is that (for the most part) keyboard
> shortcuts are not context-sensitive nor are they able to be
> context-sensitive. I'll give you a simple example I raised a few years
>
 back:
>>>
 When the editor Find & Replace dialog is focused, we 

Re: [Mentors] 9.0 beta rc3 vote thread

[Jaroslav Tulach]

2018-02-12 22:59 GMT+01:00 Mark Struberg :

> Hi!
>
> been busy as well lately. The IPMC mail is flagged in my calendar since
> days :/
>
> As far as I understood the only open Q is about the modded eclipse equinox
> jar, isn't?
>

I see. Then it is something I should solve.
https://github.com/apache/incubator-netbeans/pull/257 - I'll work on the
option #1.


> For my understanding: is this a mandatory library or something which is
> optional?
>

The answer depends on whether we talk about the NetBeans Platform or the
whole IDE. From the point of view of NetBeans Platform this library is
optional.
-jt

> Am 12.02.2018 um 11:00 schrieb Geertjan Wielenga <
geertjan.wiele...@googlemail.com>:
>
> OK, the IPMC vote has been up since Friday, i.e., on the incubator@general
> mailing list.
>
> There’s a question there re a legal issue that we need to answer.
>
> Aside from that, what can we do to get the missing binding +1 (since we
> have two of those from our mentors and need at least three in total)?
>
> Anyone someone can ping re this — also note we have 5 mentors of which 2
> are actually active (and wonderfully helpful thank you Bertrand and Ate).
> Should something be done about this?
>
> Many thanks and a good week to everyone,
>
> Gj
>
> On Friday, February 9, 2018, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com> wrote:
>
>> It looks to me like we should go ahead with the IPMC vote, though ideally
>> I think we’d add/correct the page referenced above with info to avoid
these
>> tagging problems before we do that.
>>
>> Any insights/ideas re this?
>>
>> Gj
>>
>> On Friday, February 9, 2018, Geertjan Wielenga <
>> geertjan.wiele...@googlemail.com> wrote:
>>
>>> Here's our release management page with instructions I followed in
>>> putting the rc3 together:
>>>
>>> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+
>>> NetBeans+Release+README
>>>
>>> What could be added/changed/corrected in the above to avoid the
>>> specific issues that have arisen with the tag -- and anything else to
>>> make the above as complete as possible?
>>>
>>> Thanks,
>>>
>>> Gj
>>>
>>> On Fri, Feb 9, 2018 at 11:59 AM, John Muczynski 
>>> wrote:
 Hi guys,

 re: LICENSE being slightly different in the source tarball
 Here at SimuQuest, we've had similar confusions between files which are
 templates in version control but fleshed out in the release.
 Our solution has been to
   * keep the templates in a separate folder
   * use a templating language like the one in maven or Velocity
   * try to keep comments in each file saying what it is and where it
>>> came
 from
   * not include the template folder in the binary release

 For us, this has been motivated less by tarball comparisons and more by
 wanting developers to modify and commit the "right" copy of the file.

 Hope the info helps.

 Kind Regards,
 Johnny


 --
 Johnny Muczynski
 734-262-2045

 On Fri, Feb 9, 2018 at 5:39 AM, Neil C Smith 
>>> wrote:

> On Fri, 9 Feb 2018 at 10:30 Bertrand Delacretaz <
>>> bdelacre...@apache.org>
> wrote:
>
>> I think LICENSE being slightly different (better actually, right?) in
>> the source tarball is perfectly fine if there's a rational reason for
>> it - you just need to reassure people that it's not a mistake.
>>
>
> Thanks.  Yes it's better - to clarify I meant aiming towards checking
>>> in
> and tracking history in git of the version in the full source bundle.
> Something for a later discussion anyway.
>
>
>>
>> For that you just need to be able to answer such questions with "have
>> a look at http://netbeans.apache.org/release-management.html;
>>> instead
>> of re-explaining every time.
>>
>>
> Definitely one to add to the list of initial pages we were discussing
>>> the
> other day then! ;-)
>
> Thanks and best wishes,
>
> Neil
> --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding -
>>> www.praxislive.org
>
>>>
>>


-
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Disable "Checking for external changes" in an RCP application

[Jaroslav Tulach]

Hello Humphrey,
please take a look at
https://github.com/apache/incubator-netbeans/blob/master/core.ui/src/org/netbeans/core/ui/warmup/MenuWarmUpTask.java#L165
the property and preference there shall give you control over refresh being
on or off.
-jt



2018-02-09 7:12 GMT+01:00 Humphrey Clerx :

>  Hello,
>
> Yes, I know this works in NetBeans itself. But it appears in my RCP
> application that we develop using the NetBeans platform. How can I disable
> it there?
>
> Greets,
> Humphrey.
>
> On Thu, Feb 8, 2018 at 11:53 AM, Delfi Ramirez 
> wrote:
>
> > Hello Humphrey
> >
> > try
> >
> > Tools/Options/Miscellaneous/Files => ❑ Enable auto-scanning of sources
> >
> > cheers
> >
> >
> > On 08/02/2018 11:46, Humphrey Clerx wrote:
> >
> >> Hello,
> >>
> >> Recently we switched from NetBeans 7.4 to NetBeans 8.2 and all of a
> sudden
> >> our RCP application occasionally hangs while displaying the "Checking
> for
> >> external changes" progress bar. How can I disable this functionality in
> my
> >> RCP application?
> >>
> >> Thanks in advance,
> >>  Humphrey.
> >>
> >>
> >
> >
>
>
> --
> In the mountains of truth, you never climb in vain - Nietzsche
> #-
>  \_O
> ,__/>
>   <"
>'
>

Re: Apache NetBeans Update Center through mirrors?

[Jaroslav Tulach]

2018-01-28 12:31 GMT+01:00 Antonio :

> Hi all,
>
> So we uploaded the platform 9.0-alpha binaries to https://dist.apache.org
> [1]
>
> As a consequence the artifacts are now available through the Apache mirror
> network.
>
> The URL to download these artifacts can be constructed using the
> https://www.apache.org/dyn/mirrors/mirrors.cgi script, setting the
> parameters "action=download" and "filename=..." as in [2].
>
> This "mirrors.cgi" script automatically selects the user's closest Apache
> mirror to download from. That's handy.
>
> Would it be possible to generate our update center xml & nbms and upload
> that to https://dist.apache.org along with the binary and source
> artifacts?
>
> That way we could use the same "mirrors.cgi" script as an Update Center
> url, and users would benefit from the Apache mirror network to download
> stuff more easily.
>
> Would that be a viable solution for NetBeans-330 "NetBeans 9.0 UC hosted
> on Apache infra" [3]?
>

Yes, NBMs shall be hosted on Apache infra. Rather than having them on
dist.apache.org, my preferred solution would be to upload each NetBeans
module (together with its JAR and NBM) to Maven repository. There already
is a script that can do it (see http://bits.netbeans.org/nexus/), so it may
be just a matter of setting things up...

-jt