Re: AW: Case sensitive in directory name it is a issue

2018-08-10 Thread William Beebe
And if that is the case it will also effect any Linux distribution.

On Fri, Aug 10, 2018 at 3:21 AM Piotr Hoppe  wrote:

> This issue occurs for:
>
> - NetBeans 9.0
>
> - PHP projects
>
> - Mac OS high Sierra 10.13.6 with case sensitive APFS partition.
>
>
> W dniu 10.08.2018 o 09:18, Christian Lenz pisze:
> > Which operating System do you have? For Windows, it is one Directory. If
> you have MyProjectFolder and myprojectfolder, it is the same.
> >
> >
> > Cheers
> >
> > Chris
> >
> > Von: Piotr Hoppe
> > Gesendet: Donnerstag, 9. August 2018 21:30
> > An: dev@netbeans.incubator.apache.org
> > Betreff: Case sensitive in directory name it is a issue
> >
> > When you have in the project two directories with the same name but one
> > of them uses lowercase letters and the second uses the uppercase letter,
> > for example backend and Backend, so these name are differ only size of
> > letters.
> > Then in the project tree you can see only one of this directories with
> > them content.
> >
> > In the project tree It should be visible both directories.
> >
> > Earlier, I have already reported a similar problem
> > https://netbeans.org/bugzilla/show_bug.cgi?id=268044
> >
> > This issue occurs in the NetBeans 9.0 when I works on the PHP projects.
> >
>
> --
> Piotr Hoppe
>
> Ta wiadomosc jest poufna i przeznaczona wylacznie dla adresata. Jesli
> jestes niezamierzonym odbiorca, to pilnie powiadom o tym nadawce. Nikomu
> nie ujawiaj tresci tej wiadomosci oraz nie uzywaj, nie kopiuj, nie
> drukuj, nie przechowuj, ani nie przekazuj dalej. Upewnij sie, ze zostala
> trwale usunieta. G-Forces Web Management Polska sp. z o.o.,
> 
> Ul. Trzy
> Lipy 3, 80-172 Gdańsk NIP: 583-292-04-23 REGON: 220105616 KRS: 246596
>


Re: Apache NetBeans Release Cycle

2018-08-08 Thread William Beebe
Release Cycle -
A reasonable release cadence is a Good Thing. To keep the in-between
release period short and sweet, it would be helpful to release only a new
new features to actually meet the release date. Same with bug fixes. In
fact, bug fixes should always be released even if there are no new
features. A 90 day release cadence is probably too much for a volunteer
group, so perhaps every six months.

Version Number -
I personally like using the date as the main release version discriminator.
So, for example, if NetBeans is released in October of this year, then it’s
version number might be 18.10. If this looks familiar it is; I’m stealing
that idea from Ubuntu  and every other project that does the same thing. An
alternative might be to expose an internal release number. Microsoft is
using both a date-based release with a build number for Windows 10.

On Wed, Aug 8, 2018 at 8:02 AM Josh Juneau  wrote:

> I believe that people do like more frequent releases.  Once per quarter,
> let's say, seems to be a good fit.  I do not believe that NetBeans release
> number should be bound to the supported Java release because Apache
> NetBeans 9.0 was just released with JDK 10 support...so that would be a
> cause for confusion.
>
> I think that the major release number should change once per year, say in
> August.  If we were to have a quarterly release, then Apache NetBeans 9.1
> would be next release that would occur near the end of this calendar year,
> followed by 9.2 and 9.3 in the subsequent quarters.  That would mean that
> Apache NetBeans 10 would be released next August.  I personally think it
> may become too convoluted to try and rate major releases vs minor releases
> in an effort to increment the release number.  Of course, using this logic
> it is possible to have Apache NetBeans 9.0.1, Apache NetBeans 9.1.1, etc,
> if a critical update needed to be released for some reason.
>
> Thanks for reading, I appreciate your time.
>
> On Tue, Aug 7, 2018 at 10:34 AM Oliver Rettig 
> wrote:
>
> > Thanks Peter for clarification.
> >
> > Isnt it possible to have an apache update center, which includes only
> > apache-netbeans-ide
> > updates? Or is this incompatible with the apache release procedure?
> >
> > > Badly worded by me, module update issue is where the update center will
> > be
> > > located
> > >
> > > On Tue, 7 Aug 2018 15:54 Oliver Rettig,  wrote:
> > > > > Phycologically people feel they have a more modern system if it
> > updates
> > > > > more frequently. There should be no reason why minor items can't be
> > > > > released quickly in a more agile way. I suspect though we need to
> > move
> > > >
> > > > out
> > > >
> > > > > of incubator status for that because there are a lot of rounds of
> > > >
> > > > approval
> > > >
> > > > > before code gets released.
> > > > > You could have large core releases once or twice a year and many
> > minor
> > > > > updates imbetween.
> > > >
> > > > +1
> > > >
> > > > > This is a personal thing but I would like to get the updates
> without
> > > > > downloading a new version of the ide every time. Letting the ide
> auto
> > > > > update would be nice. I guess that could only happen when the
> module
> > > >
> > > > update
> > > >
> > > > > issue is resolved
> > > >
> > > > Please point me to that module update issue?
> > > >
> > > > > On Tue, 7 Aug 2018 15:24 Geertjan Wielenga,
> > > > >
> > > > >  wrote:
> > > > > > Also, Apache NetBeans is more than Java-focused, and the question
> > is
> > > >
> > > > also
> > > >
> > > > > > whether such prominence for Java should be given to the extent
> that
> > > > > > the
> > > > > > JDK
> > > > > > releases should be followed at all, i.e., whether this should be
> an
> > > >
> > > > aim of
> > > >
> > > > > > the project. It's certainly open to discussion but definitely
> not a
> > > >
> > > > given.
> > > >
> > > > > > Gj
> > > > > >
> > > > > > On Tue, Aug 7, 2018 at 4:22 PM, Geertjan Wielenga <
> > > > > >
> > > > > > geertjan.wiele...@googlemail.com> wrote:
> > > > > > > Just as a quick FYI: Both JDK 9 and JDK 10 are supported in
> > Apache
> > > > > > > NetBeans 9, i.e., no, we've not skipped JDK 10.
> > > > > > >
> > > > > > > Gj
> > > > > > >
> > > > > > > On Tue, Aug 7, 2018 at 4:11 PM, Chuck Davis <
> cjgun...@gmail.com>
> > > >
> > > > wrote:
> > > > > > >> To me it makes sense to have NB reflect the level of Java
> > > >
> > > > implemented.
> > > >
> > > > > > >> For
> > > > > > >> example, features of JDK 11 can be added incrementally to NB
> > 9.1,
> > > >
> > > > 9.2,
> > > >
>
> --
> Josh Juneau
> juneau...@gmail.com
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866
>


Re: [VOTE] Release Apache NetBeans HTML/Java API version 1.5

2017-10-08 Thread William Beebe
Downloaded and attempted to execute mvn...

Failed with...

Running TestSuite
Configuring TestNG with: TestNG652Configurator
java.lang.Exception: Error
at
org.netbeans.html.json.impl.OnReceiveTest.performErrorJSONCallNoHandling(OnReceiveTest.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
at
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:51)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:85)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1197)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1122)
at org.testng.TestNG.run(TestNG.java:1030)
at
org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
at
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:189)
at
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:105)
at
org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:158)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95)

This is on macOS 10.13

On Sun, Oct 8, 2017 at 7:41 AM, Jaroslav Tulach 
wrote:

> Hi guys,
> I've set a Jenkins job up which can prepare a release bits of HTML/Java API
> and gives instructions how to build the ZIP file and test it:
>
> https://builds.apache.org/view/Incubator%20Projects/job/
> incubator-netbeans-html4j-release/
>
> after a bit of configuration struggling the [build #16](https://
> builds.apache.org/view/Incubator%20Projects/job/incubator-netbeans-html4j-
> release/16/) seems to deliver releasable ZIP file:
>
> https://builds.apache.org/view/Incubator%20Projects/job/
> incubator-netbeans-html4j-release/16/artifact/
> incubating-netbeans-html4j-1.5.zip
>
> It's md5sum is a45bda33200c208d0d837b0746a7dcce.
>
> I've done the basic testing on Linux, as well as I tried to use the version
> 1.5 in Bck2Brwsr VM (works fine) and TeaVM which needed a [bit of patching]
> (https://github.com/konsoletyper/teavm/pull/304). In any case the
> HTML/Java
> API seems releasable from my point of view.
>
> This is the first attempt to perform Apache release of NetBeans HTML/Java
> API.
> As such there are almost no new features. Mostly just licensing changes,
> bugfixes and other little tweaks. See Javadoc section about post 1.4
> release
> improvements:
>
> https://builds.apache.org/job/incubator-netbeans-html4j-linux/javadoc/
>
> Please take the ZIP file for a spin and vote to approve the release
> and to request the approval of the Incubator PMC to publish it on
> our site.
>
> Everyone is encouraged to vote, including non-committers.
>
> This vote shall close in the usual 72 hours.
> -jt
>
> PS: I am keeping my fingers crossed, hoping things go well.
>
>


Hello

2017-09-30 Thread William Beebe
I'm interested in following this mailing list.